SOBJs: 3rd party vs. OS4.1

I'm still puzzled and somewhat lost in our OS4.x- SOBJs-world. While I absolutly understand the reasons why this concept made it into OS4.x I have still problems from a users point of view how to handle any updates and refreshments to the SOBJs: drawer.

As a long time Amiga user I am used to look after my LIBS: and to update libraries every now and then. More or less an easy task, 'cos 99% of the libraries are updated from the original sources, i.e. OS updates or from the original library author. Proper versions strings, mostly downwards compatible and single source. Easy.

In the last days Michael made updates for some essential SOBJs (os4depot), Chris f. ex. does the same every now and then (thank you both for that efforts!).

But this leads to the fact that we have "multiple" sources for some important SOBJs - sometimes (partly) incompatible with predecessors, versioning is, hm, more difficult. My main concern: Should I (user) overwrite "official OS SOBJs" with more recent "3rd party" SOBJs?

In my first days of OS4.x usage I did - and sometimes got problems with apps that didn't worked anymore (incl. OS4.x components). So nowadays I do not dare easily to "update" SOBJs. Which leads to the same problem: Some apps won't run, 'cos they need the newer shared objects. Pff...we can't win, can't we?

Sorry for the rather long text here, but I hope for some advise or tips how to handle all this...

@cha05e90

All my recent (i.e very recent) updates are with proper sonames. Proper versioning in the name of the shared object (of course, no $VER: string).

Originally I compiled shared objects to overwrite and update what we already had. libvorbis, libogg, libjpeg, libfreetype (my .so not released), libpng (again my .so not released), libjpeg, etc..

Now, to overwrite those, I needed the same filename. This was easy. "libtool" used by most configure scripts and Makefiles doesn't know what AmigaOS is and therefore strips the version numbers, and you end up with libjpeg.so instead of libjpeg.so.8 etc..

This is how OS4.1 comes like. So you can blame quality control if you like Then people started using these libs... so, can you blame them?

Now I compile and edit version_type in libtool to "freebsd-elf" along with "pass_all" for deplibs_check_method. freebsd-elf will make sure the ".la" and soname have the right version numbers, and "pass_all" will make sure that all dependencies the .so needs are referenced in the .so (but i've almost always been doing that).

So, I started by doing it "wrong" to be consistent. So files can just be overwritten with new versions.

Now, I do it "right", and of course it gets more messy, but at least there'll be no conflicts.

The question as to whether it's OK to overwrite older files is yes (mostly), as long the major revision number of the library is the same. libpng is an exception.

I.E For libcurl, 7.16 and 7.21.2 are both in the "7" range are therefore should be compatible.

The only reason I don't have a symlink in the .lha's from .so.7 (for example) to just .so, is because .lha's don't archive symlinks, i'd have to make an install script or i'd have to duplicate the file (which sometimes I do if it's small enough) which just bloats the archive.

I see no reason to have symlinks in SObjs: at all. All programs load the relevant .so they're after directly. A symlink is only useful if you're trying to force an old program to use a new .so that has a different name, in which you need to be careful about that and the programs you use.

The symlinks, in my opinion, are only useful for use in the actual SDK. If it's not named just .so, then -lcurl for example won't find libcurl.so.7, but will find libcurl.a and link that instead. You need the symlink for the linker to use the shared version, unless you specify the full filename manually.

It's messy in Linux too in my opinion. Except programs get updated frequently and older .so's are seldom used.

Have a read of my older post about this same issue here: http://www.amigans.net/modules/newbb/ ... t_id=57858#forumpost57858

If you are unsure what to do, you can make a "SObjs" directory in the root directory of the program you want to run, then put the requires .so's in there. The program will use those first.

@MickJT

Quote:

Yep - you (and other maintainers/porters) of recent and up-to-date shared objects usually do a very fine job and help us users to know which version of an .so we look at. So far no problem here...

Quote:

I have to blame myself as well - I still think *I* (and maybe other AmigaOS users) have some kind of brain damage, 'cos we are really totally conditioned to replace *any* existing AmigaOS library with a newer/updated one. I suppose this kind of standard behaviour might not be appropiate for SOBJs...

Quote:

This is a very useful hint, thank you! This is a simple rule I can obey to... But, as you mentioned, there seem to exceptions - sadly enough rather important .so like PNG, JPEG...

Quote:

Due to the fact that had to make some backups und re-copies to all my systems, all links are gone in this process. Luckily DOpus4 generates full files out of the corresponding links...

Quote:

Ah - reminds me of the local "library" drawer we have for standard AmigaOS libraries.

@MickJT

It's useful also to make sure so-names are different when releasing shared objects which are dependant on different versions other shared objects, otherwise all sorts of nastiness occurs (although I didn't do this when I recompiled libmng against libjpeg 8, and it doesn't seem to have broken - but I await reports - libjpeg is a bit of an odd one as major versions appear to be completely interchangeable but complain about being the wrong version.)

Quote:

The only reason is if the filename and soname differ - you then need a link from the soname to the actual shared object.

Usually this is completely pointless - rename the sobj and be done with it - but some of the system provided ones (eg libz) were set up like this so it makes sense to continue.

makelink has a bug btw, if you try to replace a link (rather than creating a new one), the link gets created at the target of the link you're trying to replace. The trick is to always delete the target link before creating a new one.

This is (an abridged version of)* the little Installer procedure I use for creating links in SObjs:


It's called quite simply like this, with libvpx.so.0.9.5 being the real file and libvpx.so.0 being the link:
(p_linksobj "libvpx.so.0.9.5" "libvpx.so.0")

* The full version checks that it is not replacing a link to a newer file with one to an older one.

@Chris

I believe libvpx.so.0 is meant to be the real file.

Anyway, I hope I haven't confused people now with the new libXML2 upload.

I was going to send you a PM but i'll say it here.

On www.zlib.net

"If you are using libxml version 2.7.6 or earlier, you will need to update libxml to version 2.7.7 or later before installing zlib version 1.2.4 or later. libxml 2.7.6 and earlier made unnecessary assumptions about the undocumented internal structure of zlib that were changed in zlib 1.2.4 and result in libxml crashing. This was fixed in libxml 2.7.7."

So, i've ported 2.7.8. Good luck. The soname is libxml2.so.9. It's the standard soname. Future versions in the 2.7.x range (perhaps 2.x.x) should be .so.9 too and overwritable... or so i'm hoping.

Also, I plan on porting the latest freetype2 (2.4.3) and "gawk" to get rid of that annoying error you always get when running a configure script.

Edit (Oct '2014): That nawk/awk/gawk error you get might be a problem of abc-shell. If you replace \ with \\ in the relevant section of the configure script, that error goes away.

@MickJT

Quote:

Hmm...
/SDK/local/newlib/lib/libxml2.so: undefined reference to `gzdirect@ZLIB_1.2.2.3'


You did build it against libz 1.2.5?

I've done some research and using libz 1.2.4.1 or higher is some kind of fix.

@Chris

It's built against libz 1.2.5. I don't think I did anything wrong did I? I did a little test to make sure one of the test programs ran using the shared libs before I uploaded it.

libz 1.2.5 has symbols which i'm guessing make it backwards compatible with previous versions. That gzdirect 1.2.2.3 is in the zlib 1.2.5 shared object library.

Should work if you use the latest zlib. I don't see the harm! A previous zlib AND libxml are included with the SDK.

Edit: I found this in the libxml2 source:

#ifdef HAVE_ZLIB_H
if ((xmlInputCallbackTable[i].opencallback == xmlGzfileOpen) &&
(strcmp(URI, "-") != 0)) {
#if defined(ZLIB_VERNUM) && ZLIB_VERNUM >= 0x1230
ret->compressed = !gzdirect(context);
#else

.....

#endif

Seems like it's done on purpose.

Edit2: Tried older libz.so. Same issue as you. Fine with 1.2.5. Normal. I think I uploaded libz 1.2.5 to OS4Depot a while ago.

@MickJT

Er... I'm using 1.2.5. Not sure if it is one I built myself or one I downloaded. I'll try yours...

@Chris

libz.so(.1.2.5) 146639 bytes

If you look at zlib-1.2.5.tar.gz, there's a zlib.map file. It's very important it's used when making the .so

Anyway, try mine. Should be fine. I'm signing off for a while now.

@MickJT

Yes, works fine, thanks.