sys-libs/zlib-1.2.3 installs a .so that results in applications which use gzdirect [in particular; this might affect some other zlib functions] to fail to link. Current workaround for this issue is to remove libz.so. Portage 2.1.1 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r8 i686) ================================================================= System uname: 2.6.17-gentoo-r8 i686 AMD Athlon(tm) XP 2000+ Gentoo Base System version 1.12.5 Last Sync: Mon, 09 Oct 2006 16:30:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.2.11-r1 dev-lang/python: 2.3.5, 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.UTF-8" LINGUAS="" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext 7zip X alsa audacious berkdb bitmap-fonts bzip2 cairo cdr cjk cli colordiff crypt css cups dbus dlloader dri dvd dvdr dvdread eds elibc_glibc emboss encode fam ffmpeg firefox flac fortran gdbm gif gmp gpm gstreamer gtk gtk2 hal imagemagick input_devices_evdev input_devices_keyboard input_devices_mouse ipv6 isdnlog ithreads jabber jpeg jpeg2k kde kernel_linux ldap libg++ mad mikmod mmx mmxext mng mono mozsvg mp3 mpeg msn ncurses new-login nls nptl nptlonly nsplugin offensive ogg opengl oscar oss pam pcre perl png posix ppds pppd python qt3 qt4 quicktime readline real reflection rtc sasl sdl session spell spl sqlite sse ssl svg tcpd theora tidy tiff truetype truetype-fonts type1-fonts udev unicode userland_GNU video_cards_nvidia video_cards_vga vim-with-x vorbis wifi win32codecs x264 xcomposite xml xorg xpm xscreensaver xsl xv xvid yahoo zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Care to explain why is it broken, how is it broken, what does it break, post some test case?
Like I said, any application that calls gzdirect will fail to link. I discovered this when trying to compile latest ZSNES svn. None of the other devs experienced the same issue [they all run either Debian or use MinGW or DJGPP for test builds], for what it's worth [I asked].
Reopening as per my last comment [I forgot to do that earlier, sorry.]
that doesnt make any sense at all if you delete libz.so, then you cannot link against libz *at all* post some real errors rather than vague descriptions
See the second section of this post: http://board.zsnes.com/phpBB2/viewtopic.php?p=131033#131033 Additionally, g++ will use libz.a if it can't find libz.so.
Geez, attach some testcase and reopen then. Really don't see anything useful there.
Firstly, what Jakub probably meant by more information is: is the exact error message "failed to link"? That's the only thing you said, is that exactly what is printed on the screen? Secondly, I thought I'd point this out as extra information for anyone reading this bug: if (on gentoo) you open /usr/lib/libz.so in a text editor, you should (hopefully) see a short ld script that loads /lib/libz.so, and an explanation of why it does it ( bug 4411 ). I don't have this particular application installed, so I don't know... it might be trying to do weird stuff resulting in an assumption that a .so file can't be an ld script. Hope this helps.
my guess is you're using zlib-1.2.3 and you're experiencing a bug that's already been fixed
*** This bug has been marked as a duplicate of 149929 ***
