#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:
Has a Patch: no 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 Changed 18 months ago by anevilyak

  • Owner changed from bonefish to korli
  • Status changed from new to assigned

comment:2 Changed 18 months ago by 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 ;

comment:3 Changed 18 months ago by anevilyak

  • Owner changed from korli to kallisti5

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

comment:4 Changed 18 months ago by korli

  • Resolution set to fixed
  • Status changed from assigned to closed

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

comment:5 Changed 18 months ago by 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.

comment:6 Changed 18 months ago by js

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:7 Changed 18 months ago by korli

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

comment:8 Changed 18 months ago by 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.

comment:9 Changed 18 months ago by korli

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

comment:10 follow-up: Changed 18 months ago by 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.

comment:11 in reply to: ↑ 10 ; follow-up: Changed 18 months ago by 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?

comment:12 Changed 18 months ago by 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.

comment:13 Changed 18 months ago by korli

Right, then forget my afterthought :)

comment:14 in reply to: ↑ 11 ; follow-up: Changed 18 months ago by 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.

comment:15 Changed 18 months ago by js

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

comment:16 in reply to: ↑ 14 ; follow-up: Changed 18 months ago by 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
;

comment:17 in reply to: ↑ 16 Changed 18 months ago by 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.

comment:18 Changed 18 months ago by anevilyak

  • Resolution set to fixed
  • Status changed from reopened to closed

Confirmed fixed in hrev44820, thanks!

Note: See TracTickets for help on using tickets.