Opened 12 years ago
Closed 12 years ago
#9126 closed bug (fixed)
libz.so missing
Reported by: | js | Owned by: | kallisti5 |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Build System | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
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.
Change History (18)
comment:1 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 12 years ago
comment:3 by , 12 years ago
Owner: | changed from | to
---|
Good catch! Fix applied to trunk in hrev44806, will leave this open until it's merged to a4.
comment:4 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Thanks! No need to merge in a4, zlib isn't an optional package there.
comment:5 by , 12 years ago
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.
comment:6 by , 12 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:7 by , 12 years ago
js, which revision are you using? This should have been fixed in hrev44726
comment:8 by , 12 years ago
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.
follow-up: 11 comment:10 by , 12 years ago
follow-up: 14 comment:11 by , 12 years ago
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?
comment:12 by , 12 years ago
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.
follow-up: 16 comment:14 by , 12 years ago
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.
comment:15 by , 12 years ago
Generated a completely new image using jam @vmware from master, still the same.
follow-up: 17 comment:16 by , 12 years ago
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 ;
comment:17 by , 12 years ago
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.
comment:18 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Confirmed fixed in hrev44820, thanks!
There is a typo in build/jam/HaikuImage:
should be changed to