FreeBSD provides /lib/libz.so.6 which includes a ZLIB_1.2.4.0 symbol, while Gentoo/FreeBSD provides /lib/libz.so.1.2.7 which includes ZLIB_1.2.3.5 and ZLIB_1.2.5.1 symbols. Discussion with ryao gives that the Gentoo/FreeBSD binary should be compatible with the binary in upstream FreeBSD. Reproducible: Always
As a clarification, it would be good if we could run binaries meant for FreeBSD with nothing more than a wrapper to workaround the SONAME difference. At present, this is not possible. This makes it impossible to make an ebuild for things like the openjdk 6 binary package fetched by FreeBSD's pkg_add utility without building the upstream zlib.so.6 binary.
If you run `wget ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9.0-release/Latest/openjdk6.tbz && tar -xf openjdk6.tbz && ln -s /lib/libz.so.1 libz.so.6 && env LD_LIBRARY_PATH="$PWD" /root/openjdk6/bin/java`, you will see an error like "/root/libz.so.6: version ZLIB_1.2.4.0 required by /root/openjdk6/bin/java not found" output. The solution to this issue would be to modify sys-libs/zlib to provide the right symbols to make the dynamic linker happy with both the binaries we compiled in the past and the binaries compiled on FreeBSD when executing them on Gentoo FreeBSD.
# readelf -a openjdk6/bin/java|grep ZLIB_1.2.4 52: 00000000 94 FUNC GLOBAL DEFAULT UND inflateEnd@ZLIB_1.2.4.0 (4) 71: 00000000 256 FUNC GLOBAL DEFAULT UND inflateInit2_@ZLIB_1.2.4.0 (4) 113: 00000000 7462 FUNC GLOBAL DEFAULT UND inflate@ZLIB_1.2.4.0 (4) 135: 00000000 94 FUNC GLOBAL DEFAULT UND inflateEnd@@ZLIB_1.2.4.0 154: 00000000 256 FUNC GLOBAL DEFAULT UND inflateInit2_@@ZLIB_1.2.4 196: 00000000 7462 FUNC GLOBAL DEFAULT UND inflate@@ZLIB_1.2.4.0 034: 4 (ZLIB_1.2.4.0) 2 (FBSD_1.0) 1 (*global*) 1 (*global*) 044: 3 (FBSD_1.0) 1 (*global*) 2 (FBSD_1.0) 4 (ZLIB_1.2.4.0) 070: 1 (*global*) 4 (ZLIB_1.2.4.0) 2 (FBSD_1.0) 3 (FBSD_1.0) 0x0010: Name: ZLIB_1.2.4.0 Flags: none Version: 4 These functions inflateEnd, InflateInit2_ and inflate are required to have ZLIB_1.2.4 version symboled. # readelf -a /lib/libz.so.1.2.6 |grep inflate ... 33: 000095e0 84 FUNC GLOBAL DEFAULT 12 inflateEnd ... 54: 000076a0 8000 FUNC GLOBAL DEFAULT 12 inflate ... 73: 000074d0 259 FUNC GLOBAL DEFAULT 12 inflateInit2_ As you can see with "readelf -a /lib/libz.so.1.2.6", there're some symbols with versioning. Considering about that, there should be good reason not to have ZLIB_1.2.4.0 for these inflate symbols. There should be some behavior incompatible change. (also notice that zlib-1.2.4 had serious bug) ok, it's possible for us to try adding ZLIB_1.2.4.0 and examine our machine won't crash (for all ZLIB_1.2.4.0 linking binaries in the world?) to make linker happy. But, I bet it's just waste of time.
well, no its not a bug, its a feature :) you have to consider g/fbsd and vanilla fbsd as different systems; we have different soname policies and some core libraries like zlib slightly differ too, in the sense that ours is more up to date and following upstream rather than what happens to be imported into freebsd core system. if you want to use a binary package from freebsd then you are on your own: you'll have to fetch binary libraries and use LD_LIBRARY_PATH when problems like that happen. for the openjdk case, if you need openjdk to bootstrap itself, then you can use this trick to bootstrap it and then provide a g/fbsd binary that will make everyone happy and wont need such hacks. i bet that if zlib symbols are versionned and different here, then there's a reason maybe...
