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.*
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
