libz.so missing

[js]

It seems /boot/system/lib/libz.so is missing, but it should be a symlink to libz.so.1.

This makes WonderBrush fail to start. While it is incorrectly referencing libz.so instead of libz.so.1, we need to provide libz.so anyway in order to link against it.

[korli]

There is a typo in build/jam/HaikuImage:

AddSymlinkToHaikuHybridImage system lib : $(HAIKU_ZLIB_CURRENT_LINK)
	: libzlib.so : : true ;

should be changed to

AddSymlinkToHaikuHybridImage system lib : $(HAIKU_ZLIB_CURRENT_LINK)
	: libz.so : : true ;

[anevilyak]

Good catch! Fix applied to trunk in hrev44806, will leave this open until it's merged to a4.

[korli]

Thanks! No need to merge in a4, zlib isn't an optional package there.

[js]

Actually, there's more wrong:

/boot/develop/abi/x86/gcc4/lib> ls
_KERNEL_              libGLU.so                libroot_debug.so
crti.o                libglut.so               libroot-addon-icu.so
crtn.o                libgnu.so                libroot.so
haiku_version_glue.o  libjpeg.so.8             libscreensaver.so
init_term_dyn.o       liblocalestub.a          libstdc++.so
libbe.so              libmail.so               libsupc++.so
libbnetapi.so         libmedia.so              libtextencoding.so
libbsd.so             libmidi.so               libtiff.so
libdebug.so           libmidi2.so              libtiff.so.3.8
libdevice.so          libncurses.a             libtracker.so
libfreetype.so.6      libnetwork.so            libtranslation.so
libgame.so            libpng15.so.15           libz.so.1
libGL.so              libposix_error_mapper.a  start_dyn.o

As you can see, it's libz.so.1 here. It should be libz.so in order to be able to link it.

Actually, it might even be better to remove libz.so from /boot/system/lib, as nothing should link libz.so directly - this *has* to break eventually. All files in /boot/develop/abi should *only* be .so files (because nothing else is used for linking) and and all files in /boot/system/lib should be.so.$version files.

[korli]

js, which revision are you using? This should have been fixed in hrev44726

[js]

I'm at hrev44806. I did not do a clean install, but used update-all, so some old files might still exist. That does, however, not explain the still missing files in develop/abi.

[korli]

Please check on a current nightly or a full local build.

[kallisti5]

The bug was introduced in hrev44726 )(a6a99fce04641549d5d765199533d8651e890b74 to be exact). hrev44726 was never picked for R1A4 so this bug doesn't apply to the R1A4 branch.

[korli]

Replying to kallisti5:

The bug was introduced in hrev44726 )(a6a99fce04641549d5d765199533d8651e890b74 to be exact). hrev44726 was never picked for R1A4 so this bug doesn't apply to the R1A4 branch.

Hmm no it's actually fixed in hrev44726. For instance, you should find on r1a4 in /boot/develop/abi/x86/gcc4/lib symlinks like libjpeg.so.8 instead of libjpeg.so

Though as an afterthought an application would better link against the current abi of the lib (libjpeg.so.8 instead of libjpeg.so) because it might break when the abi is later changed. Thoughts?

[js]

If the .so file points to the .so.$version file (which does not need to be in the same directory, AFAIK), the resulting binary will link the .so.$version file. The .so file is only for the compiler so it can link the library. At runtime, no .so file should be used. And at compile time, no .so.$version file should be used directly.

That is if Haiku does not break with the usual shared library rules.

[korli]

Right, then forget my afterthought :)

[anevilyak]

Replying to korli:

Hmm no it's actually fixed in hrev44726. For instance, you should find on r1a4 in /boot/develop/abi/x86/gcc4/lib symlinks like libjpeg.so.8 instead of libjpeg.so

FYI, on latest trunk (hrev44815) I still see this issue with all the outsourced libs, in abi/x86/gcc*/lib I have links named libpng.so.15, libjpeg.so.8 and libz.so.1, but not their basic unversioned variants as needed for linking a new executable.

[js]

Generated a completely new image using jam @vmware from master, still the same.

[korli]

Replying to anevilyak:

Replying to korli:
FYI, on latest trunk (hrev44815) I still see this issue with all the outsourced libs, in abi/x86/gcc*/lib I have links named libpng.so.15, libjpeg.so.8 and libz.so.1, but not their basic unversioned variants as needed for linking a new executable.

OK it seems I did a mistake when fixing this. Could you try to replace the following at ​http://cgit.haiku-os.org/haiku/tree/build/jam/HaikuImage#n337 ?

OPTIONAL_LIBS_ALIASES =
	$(HAIKU_FREETYPE_CURRENT_LINK)
	$(HAIKU_JPEG_CURRENT_LINK)
	$(HAIKU_LIBPNG_CURRENT_LINK)
	$(HAIKU_ZLIB_CURRENT_LINK)
;

by

OPTIONAL_LIBS_ALIASES =
	libfreetype.so
	libjpeg.so
	libpng.so
	libz.so
;

[anevilyak]

Replying to korli:

OK it seems I did a mistake when fixing this. Could you try to replace the following at ​http://cgit.haiku-os.org/haiku/tree/build/jam/HaikuImage#n337 ?

[...]

Will try that tonight and let you know.

[anevilyak]

Confirmed fixed in hrev44820, thanks!