[aldacron]

I recall Clayasaurus posted some time ago about different names for the OpenGL shared libraries on Mepis. Today, as I was getting DerelictSDL compiling and running on my new Mepis install, the sdlbitmap test program kept crashing because it couldn't load libSDL.so (which also pointed out a nasty bug in Derelict). A bit of snooping showed me that the SDL shared lib on my system is names libSDL-1.2.so.0.7.0, with a symbolic link called libSDL-1.2.so.0.

Aside from the fact that I think this is a ridiculous naming convention, the question of how to handle this situation in the general case now becomes a major issue for the Linux port. There's no telling what kooky sort of names are on the path of an end-user's system (presinstalled or otherwise). Obviously, requiring Derelict apps to ship with custom .so files is out - I know that doesn't fly in the Linux world (and could be quite complex with dependencies).

The first thing that pops into my head is that the Load functions for each package require a file name as a parameter. This puts the onus on the app. It also eliminates the possiblilty of automatically loading stuff in the module constructors if exceptions ever get fixed.

The next thing I think of is a configuration file. Each Derelict package can ship with sensible default lib names in the config file, and the end-user will be responsible for configuring the appropriate shared lib names if they are non-standard. Since most Linux users are used to fiddling with config files, this is not as bad of an option as it would be on Windows. It also opens the door to add other configurable features to the Derelict packages (which would then start taking Derelict out of the scope of 'direct binding'). Alternatively, the end-user could be required to create a libSDL.so symlink if they have a nonstandard name. Not too keen on that, though.

The third and final option I came up with is for Derelict to automatically scan the system for the appropriate file name if the default fails to load. If a lib is found, it's name is cached and used from thence forward until it fails to load again. This would eliminate the need for the end-user to configure anything, and would allow Derelict to automatically catch something like libSDL.1.2.so.0 when it is upgraded to libSDL.1.3.so.0, for example. The drawback is that we must assume that all SDL libraries will contain SDL and .so, and all OpenGL libraries will contain GL and .so. And what happens if Joe Blow releases joesGL.so one day? Or Steve Davis releases libSDLib.so? Too many was this approach could break.

So for now, I'm favoring the config file approach. Before I implement it, however, I'd like some feedback. Does anyone have any other options they can think of? Is the config file a bad idea?

At any rate, I've got the fixes in my local copy for SDL to compile and run on Linux when libSDL.so is present. I also need to go back and fix up each package to handle the case of a missing shared lib (I thought I had done that already!). I've converted the DerelictSDL Makefile to Makefile.linux, but I'm reconsidering this before I commit it. First of all, I'm thinking about zapping the makefiles altogether and going with SCons. I realize that this will require the developer to install both Python and Scons, but I think it's a small price to pay. And no, I won't use both approaches. If I continue to maintain two makefiles for each package, then there's no reason to use SCons in the first place. So, no linux commits until I get this sorted.

[JJR]

[JJR]

After reviewing the link I submitted above, I realize that my explanation wasn't quite accurate in spots. For a clearer explanation, stick to the link!

[aldacron]

After reading the article you posted it would appear that symlinks to lib*.so are the non-standard. The dynamic linker ignores the version number in lib*.so.x, so there's no need to include it when linking, for example, -lSDL. This explains why there's no libSDL.so symlink on Mepis.

So the problem still remains, though the focus is different from what I initially believed. Derelict needs a standard way to load the shared lib manually. Unlike the linker, dlopen will not load libSDL-1.2..so.0 for libSDL.so. And if libSDL.so is not standard, what then should Derelict do?

[JJR]

Just to make sure the definitions are laid out:

[Linker name]
> lib*.so == symlink to a shared library so name; no file size; merely an fs alias; setup up by linux distribution or installation program; used by linker to link

[so name]
> lib*.so.x == symlink to a shared library real name; no file size; merely an fs alias; setup by ldconfig automatically

[real name]
> lib*so.x.x == actual library containing dynamically loadable object code

Also the link option -llibrary in gcc will load exactly what you specify as library. It merely surrounds it with the necessary "lib" and postfix '.a' or '.so' as described from the gcc manual:

[JJR]

Actually, perhaps I should modify one of my steps above. Trying to load the "so name" may be quite hard because the variances in interface revision numbers as indicated by the number appended at the end "libSDL-1.2.so.0". That's why the existance of linker names are probably so critical. If just a libSDL-1.2.so is present then we know we are loading the basic functionality we need. Multiple semi-specific linker names are often present. I imagine it's designed to be that way. It would be nice if a seasoned linux developer could comment on this more.

Later,

John

[aldacron]

[JJR]

[aldacron]

[JJR]

[clayasaurus]

[aldacron]