I was doing on update on my amd64 box and zlib was upgraded to v1.2.1-r3 (due to a security fix). Something is wrong though because it never builds and/or installs libz.so.1.2.1. I tried using gcc 3.3 to compile. I tried to downgrade. Nothing worked for me. From the emerge: >>> Install zlib-1.2.1-r3 into /var/tmp/portage/zlib-1.2.1-r3/image/ category sys-libs cp libz.a /var/tmp/portage/zlib-1.2.1-r3/image//lib64 cd /var/tmp/portage/zlib-1.2.1-r3/image//lib64; chmod 755 libz.a cd /var/tmp/portage/zlib-1.2.1-r3/image//lib64; if test -f libz.so.1.2.1; then \ rm -f libz.so libz.so.1; \ ln -s libz.so.1.2.1 libz.so; \ ln -s libz.so.1.2.1 libz.so.1; \ (ldconfig || true) >/dev/null 2>&1; \ fi cp zlib.3 /var/tmp/portage/zlib-1.2.1-r3/image//usr/share/man/man3 chmod 644 /var/tmp/portage/zlib-1.2.1-r3/image//usr/share/man/man3/zlib.3 cp zlib.h zconf.h /var/tmp/portage/zlib-1.2.1-r3/image//usr/include chmod 644 /var/tmp/portage/zlib-1.2.1-r3/image//usr/include/zlib.h /var/tmp/portage/zlib-1.2.1-r3/image//usr/include/zconf.h /usr/lib/portage/bin/dolib: libz.so.1.2.1 does not exist chmod: cannot access `libz.so.*': No such file or directory ln: creating symbolic link `/var/tmp/portage/zlib-1.2.1-r3/image//usr/lib64/libz.so' to `/lib64/libz.so.1.2.1': No such file or directory man: prepallstrip: strip: >>> Completed installing into /var/tmp/portage/zlib-1.2.1-r3/image/ Reproducible: Always Steps to Reproduce: 1. emerge zlib Actual Results: An upgraded zlib Expected Results: Most of the services on my machine won't start because they can't find libz.so.1. For example: /usr/sbin/named: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory Portage 2.0.50-r10 (gcc34-2004.2, gcc-3.4.1, glibc-2.3.4.20040808-r0, 2.6.8-gentoo-r1) ================================================================= System uname: 2.6.8-gentoo-r1 x86_64 AMD Athlon(tm) 64 Processor 3800+ Gentoo Base System version 1.5.3 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-march=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 apache2 berkdb crypt cups encode foomaticdb gdbm gif imlib jpeg ldap libg++ mysql ncurses nptl pam png procmail python readline samba sasl slang ssl tcpd xml2 zlib"
...do you have CONF_LIBDIR set for some reason?
i think i might have fixed your bug. the fixed ebuild has the following md5sum: ayanami zlib # md5sum zlib-1.2.1-r3.ebuild d90fb61ad477289ef8b45327a8583bf3 zlib-1.2.1-r3.ebuild it'll take at least 15 minutes to make it to rsync
i'd also like to note that you need portage 2.0.51_pre20 if you want (mostly) working CONF_LIBDIR support
I don't know what CONF_LIBDIR does (is that like LD_LIBRARY_PATH?). I'm not even sure where I would set that. If it's just an environment variable, I don't have it set: # echo $CONF_LIBDIR # I just tired out the new ebuild and it doesn't seem to have worked. Here is another snip from my emerge: >>> Install zlib-1.2.1-r3 into /var/tmp/portage/zlib-1.2.1-r3/image/ category sys-libs cp libz.a /var/tmp/portage/zlib-1.2.1-r3/image//lib cd /var/tmp/portage/zlib-1.2.1-r3/image//lib; chmod 755 libz.a cd /var/tmp/portage/zlib-1.2.1-r3/image//lib; if test -f libz.so.1.2.1; then \ rm -f libz.so libz.so.1; \ ln -s libz.so.1.2.1 libz.so; \ ln -s libz.so.1.2.1 libz.so.1; \ (ldconfig || true) >/dev/null 2>&1; \ fi cp zlib.3 /var/tmp/portage/zlib-1.2.1-r3/image//usr/share/man/man3 chmod 644 /var/tmp/portage/zlib-1.2.1-r3/image//usr/share/man/man3/zlib.3 cp zlib.h zconf.h /var/tmp/portage/zlib-1.2.1-r3/image//usr/include chmod 644 /var/tmp/portage/zlib-1.2.1-r3/image//usr/include/zlib.h /var/tmp/portage/zlib-1.2.1-r3/image//usr/include/zconf.h /usr/lib/portage/bin/dolib: libz.so.1.2.1 does not exist chmod: cannot access `libz.so.*': No such file or directory man: prepallstrip: strip: >>> Completed installing into /var/tmp/portage/zlib-1.2.1-r3/image/ I had to go back to the binary I grabbed from the AMD64 2004.2 LiveCD. To try and figure out what the problem is, I manually unpacked the source code and applied the gentoo patches. I then tried to build the library myself using gcc 3.3 and 3.4. Here are my results: # tar jxvf /usr/portage/distfiles/zlib-1.2.1.tar.bz2 # cd zlib-1.2.1 # patch -p1 < /usr/portage/sys-libs/zlib/files/zlib-1.2.1-glibc.patch patching file Makefile.in death zlib-1.2.1 # patch -p1 < /usr/portage/sys-libs/zlib/files/zlib-1.2.1-build-fPIC.patch patching file Makefile.in patching file configure death zlib-1.2.1 # patch -p0 < /usr/portage/sys-libs/zlib/files/zlib-1.2.1-mapfile.patch patching file configure patching file mapfile death zlib-1.2.1 # patch -p0 < /usr/portage/sys-libs/zlib/files/zlib-1.2.1-configure.patch patching file configure # ./configure Building static library libz.a version 1.2.1 with gcc. Checking for unistd.h... Yes. Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf() Checking for vsnprintf() in stdio.h... Yes. Checking for return value of vsnprintf()... Yes. Checking for errno.h... Yes. Checking for mmap support... Yes. # make # gcc -o libz.so adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o trees.o zutil.o inflate.o infback.o inftrees.o inffast.o -lc /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.1/../../../crt1.o(.text+0x21): In function `_start': : undefined reference to `main' collect2: ld returned 1 exit status # gcc-config x86_64-pc-linux-gnu-3.3.4 # source /etc/profile # gcc -o libz.so adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o trees.o zutil.o inflate.o infback.o inftrees.o inffast.o -lc /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/../../../crt1.o(.text+0x21): In function `_start': : undefined reference to `main' collect2: ld returned 1 exit status
Forgot to include in my cut/paste, when trying to build the zlib shared object by hand, I did "make clean" and "make" after I switched from gcc 3.4 to 3.3. But they both still gave the same error.
Realized I made a mistake trying to compile zlib by hand, I didn't pass --shared to ./configure. It does work when I do it by hand: # pwd /root/zlib-1.2.1 # make clean rm -f *.o *~ example minigzip \ libz.* foo.gz so_locations \ _match.s maketree contrib/infback9/*.o # ./configure --shared Checking for shared library support... Building shared library libz.so.1.2.1 with gcc. Checking for unistd.h... Yes. Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf() Checking for vsnprintf() in stdio.h... Yes. Checking for return value of vsnprintf()... Yes. Checking for errno.h... Yes. Checking for mmap support... Yes. # make gcc -fPIC -O3 -DUSE_MMAP -c -o example.o example.c gcc -fPIC -O3 -DUSE_MMAP -c -o adler32.o adler32.c gcc -fPIC -O3 -DUSE_MMAP -c -o compress.o compress.c gcc -fPIC -O3 -DUSE_MMAP -c -o crc32.o crc32.c gcc -fPIC -O3 -DUSE_MMAP -c -o gzio.o gzio.c gcc -fPIC -O3 -DUSE_MMAP -c -o uncompr.o uncompr.c gcc -fPIC -O3 -DUSE_MMAP -c -o deflate.o deflate.c gcc -fPIC -O3 -DUSE_MMAP -c -o trees.o trees.c gcc -fPIC -O3 -DUSE_MMAP -c -o zutil.o zutil.c gcc -fPIC -O3 -DUSE_MMAP -c -o inflate.o inflate.c gcc -fPIC -O3 -DUSE_MMAP -c -o infback.o infback.c gcc -fPIC -O3 -DUSE_MMAP -c -o inftrees.o inftrees.c gcc -fPIC -O3 -DUSE_MMAP -c -o inffast.o inffast.c ar rc libz.a adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o trees.o zutil.o inflate.o infback.o inftrees.o inffast.o gcc -shared -Wl,-soname,libz.so.1 -Wl,--version-script,mapfile -o libz.so.1.2.1 adler32.lo compress.lo crc32.lo gzio.lo uncompr.lo deflate.lo trees.lo zutil.lo inflate.lo infback.lo inftrees.lo inffast.lo -lc rm -f libz.so libz.so.1 ln -s libz.so.1.2.1 libz.so ln -s libz.so.1.2.1 libz.so.1 gcc -fPIC -O3 -DUSE_MMAP -o example example.o -L. libz.so.1.2.1 gcc -fPIC -O3 -DUSE_MMAP -c -o minigzip.o minigzip.c gcc -fPIC -O3 -DUSE_MMAP -o minigzip minigzip.o -L. libz.so.1.2.1 # ls -la libz.so* lrwxrwxrwx 1 root root 13 Aug 27 08:56 libz.so -> libz.so.1.2.1 lrwxrwxrwx 1 root root 13 Aug 27 08:56 libz.so.1 -> libz.so.1.2.1 -rwxr-xr-x 1 root root 90966 Aug 27 08:56 libz.so.1.2.1 It still fails however when I try and build from the ebuild. Strange.
I think I've found the source of the problem. Trying to build using the ebuild again: # emerge -B zlib Calculating dependencies ...done! >>> emerge (1 of 1) sys-libs/zlib-1.2.1-r3 to / >>> md5 src_uri ;-) zlib-1.2.1.tar.bz2 >>> Unpacking source... >>> Unpacking zlib-1.2.1.tar.bz2 to /var/tmp/portage/zlib-1.2.1-r3/work * Applying zlib-1.2.1-glibc.patch... [ ok ] * Applying zlib-1.2.1-build-fPIC.patch... [ ok ] * Applying zlib-1.2.1-mapfile.patch... [ ok ] * Applying zlib-1.2.1-configure.patch... [ ok ] * Applying zlib-1.2.1-CAN-2004-0797.patch... [ ok ] >>> Source unpacked. Checking for shared library support... No shared library support; try without defining CC and CFLAGS Building static library libz.a version 1.2.1 with gcc. It doesn't find shared library support. As you can see in my last comment, when I do this by hand, it works fine. Getting closer to finding a solution.
*** Bug 61912 has been marked as a duplicate of this bug. ***
...can you try doing an rm -rf /var/tmp/portage? and then trying again? i know it's sounds like a strange request, but really that's just the sound of me grasping at straws. ^^; but i think we might be seeing a portage bug here...
# rm -r /var/tmp/portage # mkdir /var/tmp/portage # emerge -B zlib Calculating dependencies ...done! >>> emerge (1 of 1) sys-libs/zlib-1.2.1-r3 to / >>> md5 src_uri ;-) zlib-1.2.1.tar.bz2 >>> Unpacking source... >>> Unpacking zlib-1.2.1.tar.bz2 to /var/tmp/portage/zlib-1.2.1-r3/work * Applying zlib-1.2.1-glibc.patch... [ ok ] * Applying zlib-1.2.1-build-fPIC.patch... [ ok ] * Applying zlib-1.2.1-mapfile.patch... [ ok ] * Applying zlib-1.2.1-configure.patch... [ ok ] * Applying zlib-1.2.1-CAN-2004-0797.patch... [ ok ] >>> Source unpacked. Checking for shared library support... No shared library support; try without defining CC and CFLAGS Didn't seem to have any effect. Just for the hell of it (I'm grasping at straws too!) I tried to build zlib 1.1.4-r4. Same error: # emerge -B =sys-libs/zlib-1.1.4-r4 Calculating dependencies ...done! >>> emerge (1 of 1) sys-libs/zlib-1.1.4-r4 to / >>> md5 src_uri ;-) zlib-1.1.4.tar.bz2 >>> Unpacking source... >>> Unpacking zlib-1.1.4.tar.bz2 to /var/tmp/portage/zlib-1.1.4-r4/work * Applying zlib-1.1.4-gzprintf.patch... [ ok ] * Applying zlib-1.1.4-glibc.patch... [ ok ] * Applying zlib-1.1.4-build-fPIC.patch... [ ok ] * Applying zlib-1.1.4-mapfile.patch... [ ok ] >>> Source unpacked. Checking for shared library support... No shared library suppport; try without defining CC and CFLAGS
Just found a reason why the build won't build a shared library but running configure directly will. This is what I get when I remove some redirects to dev null from the shared library test in configure script. ./configure --shared CC=gcc CFLAGS=-march=k8 -pipe -O2 -fomit-frame-pointer -frename-registers -fweb --param max-delay-slot-insn-search=300 --param max-delay-slot-live-search=1000 --param max-pending-list-length=100 --param max-gcse-passes=4 --param max-gcse-memory=104857600 --param max-crossjump-edges=400 SFLAGS=-march=k8 -pipe -O2 -fomit-frame-pointer -frename-registers -fweb --param max-delay-slot-insn-search=300 --param max-delay-slot-live-search=1000 --param max-pending-list-length=100 --param max-gcse-passes=4 --param max-gcse-memory=104857600 --param max-crossjump-edges=400 Checking for shared library support... /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.1/../../../../x86_64-pc-linux-gnu/bin/ld: ztest1503.o: relocation R_X86_64_PC32 against `getchar@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.1/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status No shared library support; try without defining CC and CFLAGS And adding a CFLAGS="$CFLAGS -fPIC" to the build src_compile ./configure line cured the ebuild problem.
...what binutils version are you all using? and glibc
I've got: binutils-2.14.90.0.8-r1 glibc-2.3.4.20040808
Confirmed, after adding -fPIC to CFLAGS in /etc/make.conf the biuld was succesfull. gcc-3.4.1-r2 binutils-2.15.91.0.2 portage-2.0.51_pre20
pavol, your binutils version is known to be broken. stop using -U, i masked that version aug11. the latest stable binutils is binutils-2.15.90.0.1.1-r3 but since loren is using a version of binutils known to work, that cant be it. mikko - when you ran configure by hand, were you using a clean unpatched zlib, or a zlib with all the gentoo patches applied? there is one that patches configure... and it touches that test. :| can you edit the ebuild to not apply the configure patch and see if that fixes it?
Travis, when running by hand I run the zlib that had been patched with all gentoo patches. (I'm also running binutils 2.15.91.0.2, but I don't think it matters). I now tried removing the zlib-1.2.1-configure.patch from the ebuild but it still fails. Also removing the other patches didn't help. The reason why running configure by hand works and the ebuild doesn't is that if no CFLAGS are defined when the configure is run it defaults to "-O3 -fPIC". But when ebuild is run it of course has some other CFLAGS already defined and they do not include -fPIC. So I would just add the following line to the ebuild as so many other ebuilds already do: use amd64 && append-flags -fPIC
mikko - i have cflags set and it works fine for me. they dont include -fPIC either, which is why i'm confused. but after looking at the configure it seems that this test is horribly wrong anyways, as shared libs always need to be PIC on amd64 and a few other archs. i'll post a patch that i would like you to try...
Created attachment 38382 [details, diff] always use -fPIC in shared library test
I added the patch to the zlib-1.2.1-r3.ebuild and tried it. It works fine for me. I'm able to build and install zlib again.
The patch fixes the ebuild also for me. I'm just wondering what could cause the different behaviour. Is it a new bash that runs the tests differently, different version of binutils/gcc/glibc or something else?
i guess it all depends on the behavior of gcc. for example, hardened gcc builds everything either -fPIC or -fPIE unless told not to. *shrug* anyways, this bug is now fixed in cvs. give it some time to reach rsync :)
...closing bug
*** Bug 62467 has been marked as a duplicate of this bug. ***
