Bugzilla Bug 151190

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 ***