[fpc-pascal] Defining sonames?

wkitty42 at windstream.net wkitty42 at windstream.net
Tue Aug 15 19:44:51 CEST 2017


On 08/14/2017 09:19 AM, Fred van Stappen wrote:
> A concrete example.
> 
> A Linux/FreeBSD fpc release was compiled using the pascal headers for 
> libX11.so.6 and using symlink libX11.so >> libX11.so.6.0.8.
> 
> This release was installed on a system (with libX11-dev too to make it
> work).

ok, that's fine...


> If, some time later, a system-update was done to the brand new version 
> libX11.so.7.0.1, this will update also libX11-dev >> libX11.so >>
> libX11.so.7.0.1.

yes... fpc could be using the libX11.so link... but it depends if a specific 
version is required... some do, some don't... it depends, too, on backward 
compatibility...


> And using fpc, there will be a error because libX11.so does not point to a 
> libX11.so.6 version.


nope... because fpc doesn't care since it uses libX11.so which can point to 
whatever it needs to point to... the only way an error can happen with this is 
if the fpc program is performing some sort of version query on the .so that gets 
loaded... there's no problem with that, either, if that program requires a 
specific version of libX11... if there is a problem, then remove the update to 
7.0.1 and go back to 6.0.8 until the fpc program is updated for a higher version 
of libX11...


> But if the same Linux/FreeBSD fpc release was compiled using symlink 
> libX11.so.6, there, no problem, it will use the still installed symlink
> libX11.so.6.

libX11.so should be a symlink, too!

libX11.sp     links to libX11.so.6
libX11.so.6   links to libX11.so.6.0
libX11.so.6.0 links to libXll.so.6.0.8 which is the real .so binary being used...

when the fpc program uses libX11.so, the links could be like this...

libX11.sp     links to libX11.so.7
libX11.so.7   links to libX11.so.7.0
libX11.so.7.0 links to libXll.so.7.0.1 which should still work unless, as noted 
above, the fpc program requires an older version and does a version check or 
something...

ideally, the fpc program can check which .so names are available and choose the 
one closest to the beginning of the link chain that fits its needs... in other 
words, it can

1. check if libX11.so.6.0.8 exists if it requires v6.0.8. this is too strict!
2. check if libX11.so.6.0 exists if 6.0.8 does not exist.
3. check if libX11.so.6 exists if 6.0 does not exist.
4. check if libX11.so exists if 6 does not exist.

this is common and normal... if a specific version is still needed on the 
machine, it should still exist instead of being removed... that allows older 
programs requiring it to continue to work...


> Or, if libX11.so.6 is no more installed, fpc could say "libX11.so.6 not found" 
> (because fpc knows now what version of libX11 he needs).
> 
> Other thing.
> 
> If your way *is* the way to do, why fpc does not use libc6-dev (that will
> create symlink libc.so) but uses LIBC_SO = 'libc.so.6' instead of LIBC_SO =
> 'libc.so' ?

either one is fine... the latter being the last resort unless the former is 
required...


> PS: Do not worry Marcov, it is my last post on fpc forum.


just my 2coins... i'm out, too ;)


-- 
  NOTE: No off-list assistance is given without prior approval.
        *Please keep mailing list traffic on the list unless*
        *a signed and pre-paid contract is in effect with us.*



More information about the fpc-pascal mailing list