[arch-general] glibc 2.16 -- just what is supposed to be in /lib now ??
Guys, I have read the recent thread about glibc problems and I am totally confused about what I am still supposed to have in /lib... Currently something is broken with glibc because after update, the tdebase package (kdebase for trinity) fails to build from source with the following: Scanning dependencies of target libkmanpart-module [ 49%] Building CXX object kioslave/man/CMakeFiles/libkmanpart-module.dir/kmanpart.cpp.o Linking CXX shared module libkmanpart.so [ 49%] Built target libkmanpart-module [ 49%] Generating nfs_prot_xdr.c cannot find any C preprocessor (cpp) rpcgen: C preprocessor failed with exit code 1 make[2]: *** [kioslave/nfs/nfs_prot_xdr.c] Error 1 make[1]: *** [kioslave/nfs/CMakeFiles/kio_nfs-module.dir/all] Error 2 make: *** [all] Error 2 This isn't a hardcoded path problem in TDE, it has something to do with the system not being able to find cpp in the archroot. I have confirmed this build failure on both Arch i686 and x86_64. The files present in my archroot /lib are: 15:08 providence:~/bld47/root/lib> l total 3268 drwxr-xr-x 3 root root 4096 Jul 9 13:44 . drwxr-xr-x 21 root root 4096 Jun 29 22:35 .. drwxr-xr-x 4 root root 4096 Jun 24 12:31 modules -rwxr-xr-x 1 root root 150998 Jul 2 10:27 ld-2.16.so lrwxrwxrwx 1 root root 10 Jul 2 10:27 ld-linux.so.2 -> ld-2.16.so -rwxr-xr-x 1 root root 14012 Jul 2 10:27 libanl-2.16.so lrwxrwxrwx 1 root root 14 Jul 2 10:27 libanl.so.1 -> libanl-2.16.so -rwxr-xr-x 1 root root 5544 Jul 2 10:27 libBrokenLocale-2.16.so lrwxrwxrwx 1 root root 23 Jul 2 10:27 libBrokenLocale.so.1 -> libBrokenLocale-2.16.so -rwxr-xr-x 1 root root 1967415 Jul 2 10:27 libc-2.16.so -rwxr-xr-x 1 root root 185924 Jul 2 10:27 libcidn-2.16.so lrwxrwxrwx 1 root root 15 Jul 2 10:27 libcidn.so.1 -> libcidn-2.16.so -rwxr-xr-x 1 root root 34324 Jul 2 10:27 libcrypt-2.16.so lrwxrwxrwx 1 root root 16 Jul 2 10:27 libcrypt.so.1 -> libcrypt-2.16.so lrwxrwxrwx 1 root root 12 Jul 2 10:27 libc.so.6 -> libc-2.16.so -rwxr-xr-x 1 root root 13836 Jul 2 10:27 libdl-2.16.so lrwxrwxrwx 1 root root 13 Jul 2 10:27 libdl.so.2 -> libdl-2.16.so -rwxr-xr-x 1 root root 255492 Jul 2 10:27 libm-2.16.so -rwxr-xr-x 1 root root 17948 Jul 2 10:27 libmemusage.so lrwxrwxrwx 1 root root 12 Jul 2 10:27 libm.so.6 -> libm-2.16.so -rwxr-xr-x 1 root root 87920 Jul 2 10:27 libnsl-2.16.so lrwxrwxrwx 1 root root 14 Jul 2 10:27 libnsl.so.1 -> libnsl-2.16.so -rwxr-xr-x 1 root root 30544 Jul 2 10:27 libnss_compat-2.16.so lrwxrwxrwx 1 root root 21 Jul 2 10:27 libnss_compat.so.2 -> libnss_compat-2.16.so -rwxr-xr-x 1 root root 26180 Jul 2 10:27 libnss_db-2.16.so lrwxrwxrwx 1 root root 17 Jul 2 10:27 libnss_db.so.2 -> libnss_db-2.16.so -rwxr-xr-x 1 root root 22076 Jul 2 10:27 libnss_dns-2.16.so lrwxrwxrwx 1 root root 18 Jul 2 10:27 libnss_dns.so.2 -> libnss_dns-2.16.so -rwxr-xr-x 1 root root 47032 Jul 2 10:27 libnss_files-2.16.so lrwxrwxrwx 1 root root 20 Jul 2 10:27 libnss_files.so.2 -> libnss_files-2.16.so -rwxr-xr-x 1 root root 17996 Jul 2 10:27 libnss_hesiod-2.16.so lrwxrwxrwx 1 root root 21 Jul 2 10:27 libnss_hesiod.so.2 -> libnss_hesiod-2.16.so -rwxr-xr-x 1 root root 42652 Jul 2 10:27 libnss_nis-2.16.so -rwxr-xr-x 1 root root 50804 Jul 2 10:27 libnss_nisplus-2.16.so lrwxrwxrwx 1 root root 22 Jul 2 10:27 libnss_nisplus.so.2 -> libnss_nisplus-2.16.so lrwxrwxrwx 1 root root 18 Jul 2 10:27 libnss_nis.so.2 -> libnss_nis-2.16.so -rwxr-xr-x 1 root root 5548 Jul 2 10:27 libpcprofile.so -rwxr-xr-x 1 root root 130395 Jul 2 10:27 libpthread-2.16.so lrwxrwxrwx 1 root root 18 Jul 2 10:27 libpthread.so.0 -> libpthread-2.16.so -rwxr-xr-x 1 root root 83772 Jul 2 10:27 libresolv-2.16.so lrwxrwxrwx 1 root root 17 Jul 2 10:27 libresolv.so.2 -> libresolv-2.16.so -rwxr-xr-x 1 root root 30684 Jul 2 10:27 librt-2.16.so lrwxrwxrwx 1 root root 13 Jul 2 10:27 librt.so.1 -> librt-2.16.so -rwxr-xr-x 1 root root 13800 Jul 2 10:27 libSegFault.so -rwxr-xr-x 1 root root 36005 Jul 2 10:27 libthread_db-1.0.so lrwxrwxrwx 1 root root 19 Jul 2 10:27 libthread_db.so.1 -> libthread_db-1.0.so -rwxr-xr-x 1 root root 9796 Jul 2 10:27 libutil-2.16.so lrwxrwxrwx 1 root root 15 Jul 2 10:27 libutil.so.1 -> libutil-2.16.so cpp is in /usr/bin: 15:10 providence:~/bld47/root/usr/bin> l cpp -rwxr-xr-x 1 root root 519596 Jul 2 08:06 cpp But, for some strange reason, the build can't find it. Has anyone else encountered similar build issues with the new glibc? Nothing in the TDE code has changed concerning the call to rpcgen or cpp. I'm left scratching my head. Is it safe for me to downgrade glibc to test? With all the "it broke my system" threads, I'm somewhat reluctant to try. What say the experts? What should I check first? -- David C. Rankin, J.D.,P.E.
On Tue, Jul 10, 2012 at 11:15 PM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
Guys,
I have read the recent thread about glibc problems and I am totally confused about what I am still supposed to have in /lib...
Nothing, but everything: Both "/lib" and "/lib64" should be symlinks to "usr/lib". If they are directories, fix that. -- Mantas Mikulėnas
On 07/10/2012 04:12 PM, Mantas Mikulėnas wrote:
Guys,
I have read the recent thread about glibc problems and I am totally confused about what I am still supposed to have in /lib... Nothing, but everything: Both "/lib" and "/lib64" should be symlinks to "usr/lib". If they are
On Tue, Jul 10, 2012 at 11:15 PM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote: directories, fix that.
OK, So then since /lib is very much still a directory and not a symlink, then I should: (1) cp -a /lib /usr (2) rm -r /lib (3) ln -s /usr/lib /lib ... and the kernel modules for the running kernel ending up in /usr/lib/modules and udev ending up in /usr/lib/udev -- are all OK with this? And what is /usr and /lib as _separate_ partitions on the main box? softlinks won't work across partition boundaries -- so what then? -- David C. Rankin, J.D.,P.E.
On Wed, Jul 11, 2012 at 5:52 AM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
So then since /lib is very much still a directory and not a symlink, then I should:
First, notice that /lib as a symlink is only in testing so far, so that might explain why you haven't seen it yet. It could be that your problem is unrelated...
(1) cp -a /lib /usr (2) rm -r /lib (3) ln -s /usr/lib /lib
You probably want to be a bit more careful in order to make sure that the pacman db is not out of sync. That is, check who owns the files in /lib, if they are owned by glibc leave them alone, if they are owned by packages, then rebuild and reinstall the packages with the files in /usr/lib instead, if they are not owned by anyone then move them over manually as you described. Once that is done, you should be able to "pacman -S glibc" and it should create the symlink for you. Also check Allan's last email to dev-public, it is probably explained better there.
... and the kernel modules for the running kernel ending up in /usr/lib/modules and udev ending up in /usr/lib/udev -- are all OK with this?
All official packages have their modules in /usr/lib/modules and their udev rules in /usr/lib/udev, in fact modules in /lib/modules will no longer work (if you are using testing).
And what is /usr and /lib as _separate_ partitions on the main box? softlinks won't work across partition boundaries -- so what then?
Softlinks work across filesystem boundaries, no problem. -t
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/10/12 20:52, David C. Rankin wrote:
And what is /usr and /lib as _separate_ partitions on the main box? softlinks won't work across partition boundaries -- so what then?
Tom is right. You're thinking of *hard* links, which I think don't work for directories anyway (though I saw some discussion about changing that). - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP/RNdAAoJELT202JKF+xpsPEP/1t3QUjOWXtHg+nv7m/z1xVj B09HtlJoseMbuz08nzr3uJybxpr2xig39IvVSLkW9VH+eU8z112y8S5mx7CDWnC9 NSN4F3eAZPFKRx7iWJ/14R42J0xHVXS79eauNTuhfzVNNQ8KnrvXOQQ1QAN3LM3g njcvVBkjoXPuAQK58EHK97ESBG7aZ4fq+nlGd+ZfD4VrwRqUi7b/SCe6rUOyOWo7 qus/UBSACwe+Cgbaji16x9kO7AmlWuLPhfhbVSDRVEXrrRR0CzBZ3+RqnZWGreA5 Vk+MWKqHG4cwugIsuK70ZsE0aEsDUjTgwzRSMBg3yRRpR2BmP2ge8lzkgTxg45u5 0atzX0yzc1j6wNvryWaPvjfgUGlKeNFT75deuPYO9SbuVlCUKTWcNxFu5igk/oaw fCOuPpLKYh3RyipqxuHuv+YyiZNsfy+4wY0iIQmlgY7yP+9qYFabzW/92Pxe0mio AAwmLZlgq+wpaYjnpp1QJgBgVN7dEZguV10HBkEXN+mU/20Q5a7TYjDtX+yAfP9h 6TCDZyvoGx3mZXYjdhaA03na1A/wUTcYNMO4sqpANVuK/XtSYAO5reN5APlSkcU1 fiwRH2a4AMZOWaPdzVuKMFtIyg8LH98GGGRtkq+SWGZiJ4YDv9UEhWpaU3gFDjzc 5E8L+OTSlv1XHLBWPs1b =bnr6 -----END PGP SIGNATURE-----
Tom is right. You're thinking of *hard* links, which I think don't work for directories anyway (though I saw some discussion about changing that).
You are correct. Hard links must link to another item within the current partition/volume and cannot cross over, however soft/symbolic links can. Last time I checked, Apple's file system is the only one that can Hard Link a directory.
On Wed, Jul 11, 2012 at 6:57 PM, Squall Lionheart <headmastersquall@gmail.com> wrote:
Tom is right. You're thinking of *hard* links, which I think don't work for directories anyway (though I saw some discussion about changing that).
You are correct. Hard links must link to another item within the current partition/volume and cannot cross over, however soft/symbolic links can. Last time I checked, Apple's file system is the only one that can Hard Link a directory.
(...but cannot hardlink files in a sane way.) ext4 supports hardlinked directories, can be done using `debugfs` – Linux just disallows that in link() currently. -- Mantas Mikulėnas
(...but cannot hardlink files in a sane way.)
ext4 supports hardlinked directories, can be done using `debugfs` – Linux just disallows that in link() currently.
Thank you Mantas for the info. I'm having a hard time finding information on how to create a hard link on a directory, if you have any resources you can provide that would be very helpful.
On 07/11/2012 12:00 PM, Squall Lionheart wrote:
(...but cannot hardlink files in a sane way.)
ext4 supports hardlinked directories, can be done using `debugfs` – Linux just disallows that in link() currently.
Thank you Mantas for the info. I'm having a hard time finding information on how to create a hard link on a directory, if you have any resources you can provide that would be very helpful.
Double thanks to Tom, David, Mantas, Squall, and all who responded. I now have a better appreciation for where my install is (no testing pkgs) and the /lib -> /usr/lib linking that I will expect in the future. As for the original rpcgen error, that is still in work and I'll keep digging. I have a much better appreciation of all the hard work you guys put in keeping Arch the most current distro in use. -- David C. Rankin, J.D.,P.E.
participants (5)
-
David Benfell
-
David C. Rankin
-
Mantas Mikulėnas
-
Squall Lionheart
-
Tom Gundersen