| Summary: | Samba 3.0.6-r4 fails to build on AMD64 with lib32 compatibility libraries installed | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jonathan Briggs <zlynx> |
| Component: | [OLD] Server | Assignee: | AMD64 Project <amd64> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | danielsa, rich0, samba |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
updating severity since this blocks a security bug if i recall True, this stable marking was due to a security bug. I added "-L/usr/$(get_libdir)" to append-ldflags in the ebuild. This should have worked, at least it did for me. :-/ Jonathan: Would you please test this ebuild and patch: http://dev.gentoo.org/~kugelfang/samba-3.0.6-r4.ebuild http://dev.gentoo.org/~kugelfang/samba-3.0.6-libdirsymlink.patch There problem you experienced has been caused me. I forgot about all those people who have /usr/lib as a symlink but who don't have CONF_LIBDIR set to "lib64". :-/ Hey Danny, I had the same problem, tested your two files, and everything worked great. Thanks a lot! I briefly tested the new ebuilds and it compiled fine. However, samba was essentially non-functional - attempting to log in using a roaming profile from an XP Pro machine took minutes without getting anywhere (little to no network traffic). A roll-back to 3.0.5 fixed the problem. Perhaps it was just a glitch, and I'll try it again later when I have a little more time to test. However, I wanted to post a heads-up warning to anyone deploying this when they don't have time to test it out thoroughly. (That security bug was foobar.) Patch is in CVS now, ebuild has been reverted to "~amd64". * Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: * * /samba-3.0.6-libdirsymlink.patch works a lot better if you s/FILEDIR/FILESDIR/ in the ebuild Sigh... I first had ${WORKDIR} in there :-/... Satya already fixed !
no: kugelfang fixed ;-) |
The Samba configure script has this to say: ------ dnl Check lib and lib32 library variants to cater for IRIX ABI-specific dnl installation paths. This gets a little tricky since we might have iconv dnl in both libiconv and in libc. In this case the jm_ICONV test will always dnl succeed when the header is found. To counter this, make sure the dnl library directory is there and check the ABI directory first (which dnl should be harmless on other systems. for l in "lib32" "lib" ; do if test -d "$i/$l" ; then LDFLAGS="$save_LDFLAGS -L$i/$l" ------- This really messes up the build on AMD64 with compatibility libraries in lib32. Reproducible: Always Steps to Reproduce: 1. emerge app-emulation/emul-linux-x86-compat 2. emerge net-fs/samba 3. watch the Samba build fail. Actual Results: /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.1/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find /lib32/libpam.so collect2: ld returned 1 exit status Expected Results: It should have used the 64-bit libraries and completed the build. After renaming all lib32 directories on my system, I emerged Samba and it compiled and worked properly.