[fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?

[Jonas Maebe]

On 15 Aug 2012, at 15:14, Graeme Geldenhuys wrote:

> On 15 August 2012 12:49, Jonas Maebe <jonas.maebe at elis.ugent.be> wrote:
>> You said that you manually created the symbolic link. I simply explained that you should
>> never do that, and instead install the development packages because they will do that
>> (correctly) for you.
> 
> So my applications that I deploy to clients will now require -devel
> packages?

They always have required them until now (as have any other applications that use fcl-db).

> This just doesn't sound sane, sorry. Maybe there is just a
> fundamental flaw in all distros and how they package software.
> Initially a great idea (in theory), but in reality it is seriously
> flawed.

It's the fcl-db/Synapse units that are flawed. As explained in my first reply, the unversioned symlink is only for use by the linker (ld), and they work perfectly well for that purpose.

>> Whether or not it is desirable for the FCL/Synapse units to require an unversioned
>> symlink to be present is a separate issue.
> 
> FCL-DB uses dynamic linking by default, and looks for the unversioned
> shared library. So what specific Firebird version is the FCL-DB coded
> too?

I have no idea, which is why I also said in my first reply:

***
At least most (if not all) fcl units that dynamically load libraries have a function that you can call to explicitly specify the name of the dynamic library to use. Since the units themselves have presumably been written to work with certain versions of those libraries, it would however probably be best if that code were directly added to those units (and to remove any *default* dynamic loading of unversioned file names, since such libraries usually only exist on a developer's machine -- except maybe on non-Unix platforms).
***

> Maybe I should simply install my apps into /home/<user>/<appname>. My
> installer would then ship the required/expected *.so files, and setup
> the unversioned symlink. My app would then be launched via a script
> which sets the LD_LIBRARY_PATH to the application directory. My app
> would then be totally self-contained. This seems like the only way to
> get around these flawed package management rules and dependencies.

While shipping all libraries yourself is an option, the package management rules and dependencies are not flawed (or at least the scenario you are describing currently does not point to a flaw in them). If you start shipping libraries yourself, you'd better make sure that you also ship all libraries they in turn depend on as well, because otherwise you're more likely to make the problem worse than solve it.

>> It will point to the library of the version corresponding to the dev/devel package that has been installed.
> 
> So one minute it could point to a v1.x library, and the next it could
> point to a v2.x library. This will surely break many apps that only
> look at the unversioned symlink.

As mentioned in my previous replies, applications should never look at the unversioned link in the first place when dynamically loading a library.


Jonas