OS4.1.2 bug: libbz2.so missing symlink

The -soname when building should have been libbz2.so.1.0.4, but due to a typo, is libbz2.so.1.0, meaning although there is a soft-link to libbz2.so, the OS cannot find the library if a program is built with it.

Edit: Changed my mind. All that is missing is a symlink. http://www.amigans.net/modules/newbb/ ... t_id=57493#forumpost57493

@MickJT

makelink sobjs:libbz2.so.1.0 sobjs:libbz2.so.1.0.4 soft

libcairo.so is a bit dodgy as well, because it references libpng.so which is linked to libpng12.so (with the same soname), resulting in the linker creating warnings. If you try to upgrade to libpng 1.4 you can't because libcairo uses something libpng14.so doesn't have, repointing the libpng.so thus creates problems, and linking against two different libpngs is not advised.

Inter-version compatibility isn't high on the list of shared object programmers' priorities, unfortuantely.

@Chris

thx for the tip !

I have upgraded some archivers and got the following error each time I reboot : "failed to load shared object libbz2.so.1.0" which is very annoying...

with the command you wrote, everything is fine again

@Lio

The soname is actually probably correct (unlike I initially thought in my first post which was a while back), but a symlink is missing.

@Lio

Quote:

One of them being XAD 7-Zip, presumably

@Chris

Quote:

yes exactly !

(alongside rar and xfd but I did not know which one was generating this error, because even after renaming them, the error was still there)

@Chris
Quote:
Or maybe some programmers don't know what the soname is and how to use it properly on the Amiga?

It might help if you could write up a short tutorial on how to set, change and maintain the soname in Amiga shared objects. I don't believe this information is anywhere in the SDK yet. I would love to include any detailed information you might have.

There are tutorials on shared objects used on other operating systems but we need specific information for Amiga OS which can be included in the SDK.

@ssolie

Quote:

I have no detailed information. In fact, I have no information on this subject at all other than what I've deduced myself, which is:

The soname should contain the major version number only (major version numbers are bumped if the API changes).
Optionally, the shared object itself can be named with the full version number, with a filesystem link from soname to the file. (personally I don't see the point, just name the shared object same as the soname and be done with it)
Developers only, create a filesystem link from sdk:local/newlib/lib/shared object name without any version numbering to sobjs:soname

The easiest way to get the soname correct if the shared object doesn't build with the right one by default, and uses libtool, is to set:
version_type=freebsd-elf
You'll need to modify libtool anyway to set the two deplibs lines to "pass_all" and "yes" respectively, so might as well change version_type at the same time.

That's the only words of wisdom I have, and I'm not guaranteeing they are correct.

@Chris

deplibs_check_method needs to be set to pass_all, nothing else (in my experience).

If the soname isn't correct and libtool is used, I just change the ".so" suffix to be .so.version.number

Works well.

For reference, creating a shared library is done with:

gcc -shared -Wl,-soname,libSomething.so.1.4 -o libSomething.so.1.4 object.o files.o here.o

as an example.

If you're doing it manually and don't know what object files to include. Just peek inside the static library and have a look. Don't extract the .a, it won't have the right information in the object files to make it back into a library (either to static again, or shared).

This starts sounding like we will be in dependency hell with these shared objects some day ?! Also SFS and JXFS doesn't handle links like FFS does. Also Workbench doesn't show if something is a link on those filesystems. So backuping and trying to restore your backup of SObjs usually breaks something between those infinite numbers of links pointing to each other (and cross). Same goes to SDK. (When using Workbench to copy files.)

@TSK

Quote:

I don't know about SFS, but JXFS handles links fine. Make sure you use softlinks rather than hardlinks, as hardlinks are a bit dodgy from a user's perspective and tend to change back to normal files (on JXFS but not FFS) for reasons Joerg will recite but I don't understand.

@MickJT

Quote:

I think I had to set "yes" to get the dependencies to compile into the SObj. Otherwise you get something relying on libz.so but it doesn't list it on a readelf -d, and the app using that shared object then tends to crash.

@Chris
I just uploaded a new version of ListDynDep to OS4Depot. It will now print the SONAME along with the dependencies. This should make it a bit easier to figure out which files will be picked up by your executables.

Please let me know if you find it useful.

@ssolie

Quote:

I think so. There are still many questions about details about how shared objects are managed.

Quote:

I did put information here on utilitybase.com but that's not enough.

From the SDK and the dev team, I would like to see some rules about naming and the policy about the replacement of some core shared objects (png, jpeg, ...) about which we faced compatibility problems.

@ssolie

Yes, it is useful. I had the old version installed but had forgotten about it.

What would be really useful is if the ALL switch could be combined with something like UNIQUE, to create a complete list of all shared objects required by a program (but only listing each SObj once).

That way you can quickly get a list of everything you need if transferring an app to another system, or creating a complete archive.

@Chris

Quote:

You mentioned "pass_all" in this post. http://www.amigans.net/modules/newbb/ ... t_id=57507#forumpost57507

Only deplibs_check_method is checked for "pass_all". The other, link_all_deplibs is by default set to "unknown". As long as link_all_deplibs isn't "no", then it's considered yes.

I haven't had any issues doing it this way. My shared libvorbis.so looks for libogg.so. Even if it didn't, any program being linked against libvorbis.so should be linked against libogg.so anyway.

I haven't come across any programs that are linked with one .so, like libvorbis.so, and libogg.so is not linked in the main executable, but only in libvorbis.so. If you tried doing that, the program can't be linked.

I did a little "Hello World" test here.

5.RAM Disk:> gcc -use-dynld -lvorbis -o hello hello.c
ld: warning: libogg.so, needed by /SDK/local/newlib/lib/libvorbis.so, not found (try using -rpath or -rpath-link)
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_writetrunc'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_writeinit'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_look'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_bytes'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_writeclear'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_adv'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_get_buffer'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_readinit'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_read'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_reset'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_write'

If libogg.so was not a dependency of libvorbis.so, those "undefined references" would still exist.

Edit: New libtiff 3.9.4 shared object uploaded to OS4Depot. Didn't do anything special. Modified libtool with "pass_all". The .so has the dependencies in there, libz (libz.so.1) and libjpeg (libjpeg.so.8).

Edit2: According to other distros, it should be libtiff.so.3. Hmm. I can't see where in the source it would name it that. I'll look into it later.

@MickJT

Quote:

Set version_type=freebsd-elf

Your other points are noted