Unify libraries for developers

Hi all,

I am facing some problems with libraries, from a developer point of view.

In a previous thread, we discussed that I would be better and safer to have the extra SDL libs (SDL_image, SDL_mixer, ...) managed like os4sdl, with a common repository. And I think that should includes some dependencies (smpeg, tiff, ...).

I see only advantages, having a unique repository, a bug tracker, ... that will also avoid people compiling their own with more or less success, as I've experienced again. That will allow up-to-date libraries with documented status and features, for OS4 but that could handle other OS.

Here is an example of what happened to me :

1. Trying to port Pygame, I needed to have SDL_image and SDL_mixer in shared objects and also PNG and JPEG includes. These last ones were missing so I got them from my previous version of the SDK. I wanted to stick with JPEG 6.2 and on os4depot, the only archive available is version 8. In any cases, I am not sure includes and the shared object match !

2. About SDL_image, the available version is 2 year-old and doesn't support TIFF (not really a problem but not complete, though). As I have this idea of common repository, I decided to compile SDL_image myself. For the TIFF support, I installed a shared version of libtiff from os4depot but the final example (showimage) made a warning about a problem related to libz in libtiff. The JPEG loading fails ...

3. I tried to compiled libtiff because there was another archive on os4depot but with a newer version. After some hacks in libtool, I got a static library but the shared object was not built.

4. Let's have a look at SDL_mixer. In this case, the package is recent and rather complete. I see it contains all the required development stuff, including smpeg ... that is also available independently in another archive. Is the version the same ? Does it contain the library format I want ? Because in some archives libraries are sometimes only static (clib2 and newlib) and sometimes only in shared objects.

5. About libpng, an archive on os4depot exists with the version 1.4 but all that we have until now is built against version 1.2. What about compatibility ? I tried once to experiment and I rollbacked. Hopefully there is an older archive with static lib and shared object but the size of the later is different from "libpng.so" contained in "SOBJS:".

I am the only one in this kind of situation or developers, do you also share some problems like that ? To those who ported some libraries : would you contribute ?

Here are actions that could be done :
1. Provide includes and libraries for jpeg and png in the SDK that match with the OS shared objects.
2. Find a solution to know the version of shared objects.
3. Create a repository for SDL_image, SDL_mixer, SDL_ttf, ... with their associated dependencies (tiff, smpeg, mikmod, ...).

@corto

Not only from the developers point of view - also for me as a user it would be of great benefit to have a "single" source approach. For me it is often difficult to know which is which version - I often do not dare to replace already existing versions of some sobjs in my SOBJS: assign. Some of them I see as "official", 'cos they are part of the OS installation, some are "third party" - but what should I do, when the same shared objects comes from different sources (with the same external version)?

Furthermore most of this sobjs don't feature a proper internal AmigaOS version string, which drives me crazy! This could be handled by a single source as well. Just my 2 cents.

@corto

Quote:

There are a couple of things you must do to get shared objects compiled by libtool:

1. Open libtool in your favourite text editor (I use Notepad, because I'm a masochist).

2. Search for "deplibs".

3. The first occurance of deplibs needs the value set to "pass_all" rather than, I think, "guess".

4. The second occurance of deplibs needs to be set to "yes", not "no".

And, yes, at the top there are variables which specify whether to create static or shared libraries, so the shared option needs setting to "yes" there too.

HTH
Chris

@corto

About SDL_image, why not try to build a version with datatypes support for loading?
I've done this for testing on OS3.x and it worked quite well, I think I only left XBM (or what that dull plain format from Unix was) support in.
I only got problems with programs that needed the alpha channel, but I think this is now supported on OS4?!

Ciao, Alfred

@corto

do you have the sdk database enabled in amiupdate?
i have tried to collect all developer libs there.
i could use some help maintaining the database though.

@spotUP

I agree, Amiupdate SDK would be the best solution to this problem, as it's already available, mantained, and working.

Varthall

@Varthall
Hosting the projects on central repository is a bit different, because the actual development would take place there as well. Although I personally lack the time to contribute to a project like this, I strongly recommend to coordinate the development efforts.

AmiUpdate is great for the distribution of the released devs files, though.

@sba

Quote:

I fully agree. The AmiUpdate is a very good idea but that is compatible with a common repository and more, it would be better.
For the AmiUpdate archives, for example we don't know who did the build and how. And for libjpeg, I need the shared object that is missing.

I think I will create repositories on Google Code and we could use the builds to populate both the AmiUpdate database and os4depot.

@corto

Quote:

libcairo doesn't work with libpng 1.4 (or rather, anything which uses libcairo won't link if you specify -lpng14), so anything which uses libcairo cannot also be built against libpng 1.4, and the SObjs: softlinks can't be pointed towards libpng14.so either because the latest libcairo.so looks for libpng.so, not libpng12.so.

libcairo needs a slight tweak to work with libpng 1.4, IIRC there is one function not present in libpng 1.4 which it tries to use.