[CLOSED] External limitation

[Fred vS]

Hello.

New spring so I try it again.
Some hope for this?:
https://gitlab.com/freepascal.org/fpc/source/-/issues/32367

Thanks.

Fre;D

[Thaddy]

Versioning on libraries is almost never a good idea, unless you need to link against a specific older version.
Almost always just a breaking API change.
If not, remove the versioning.

[Fred vS]

Versioning on libraries is almost never a good idea, unless you need to link against a specific older version.
Almost always just a breaking API change.
If not, remove the versioning.

I know it is not the best argument but gcc, clang even Kylix allow it.
And sometime it is needed, even if it is a bad idea for you.

[MarkMLl]

I think that this can usefully be xrefed to https://forum.lazarus.freepascal.org/index.php/topic,58888.msg478808.html#msg478808 where somebody points out that

Maybe not related but, fpc using "external", does not allow "extended" so extension ( libc.so.6 vs libc.so ).

Forty years ago, I wouldn't have given a damn about the behaviour of an inferior language such as gcc or compilers implemented by clang. But these days anybody who says that we can blithely disregard industry expectations is, quite frankly, off his rocker.

MarkMLl

[Fred vS]

I think that this can usefully be xrefed to https://forum.lazarus.freepascal.org/index.php/topic,58888.msg478808.html#msg478808 where somebody points out that

Maybe not related but, fpc using "external", does not allow "extended" so extension ( libc.so.6 vs libc.so ).

Forty years ago, I wouldn't have given a damn about the behaviour of an inferior language such as gcc or compilers implemented by clang. But these days anybody who says that we can blithely disregard industry expectations is, quite frankly, off his rocker.

MarkMLl

Yes, I agree, I should not give gcc or clang as example.
But Xylix, who was part of Delphi project ( and Delphi is the God of fpc ) can be (maybe)  a valid argument. 

[Leledumbo]

The .so[.x[.y[.z]]] are usually just symlinks, the real file is the unversioned one. I suggest using dynamic loading if a specific version is required. As it's dynamic, the linker won't know anything about it and thus, will not remove anything.

[MarkMLl]

The .so[.x[.y[.z]]] are usually just symlinks, the real file is the unversioned one. I suggest using dynamic loading if a specific version is required. As it's dynamic, the linker won't know anything about it and thus, will not remove anything.

Debian disagrees

Code: Text  [Select][+][-]

1. lrwxrwxrwx 1 root root       21 Dec  9 19:43 libcairo.so -> libcairo.so.2.11600.0
2. lrwxrwxrwx 1 root root       21 Dec  9 19:43 libcairo.so.2 -> libcairo.so.2.11600.0
3. -rw-r--r-- 1 root root  1187432 Dec  9 19:43 libcairo.so.2.11600.0
4.  

That's the standard pattern, and it's always been like that.

MarkMLl

[Fred vS]

The .so[.x[.y[.z]]] are usually just symlinks, the real file is the unversioned one. I suggest using dynamic loading if a specific version is required. As it's dynamic, the linker won't know anything about it and thus, will not remove anything.

Hello.

Of course loadlibrary() can be used but the thing here is about "external".
I really do not understand that opposition to enable something that is needed  (read all the answers of the issue of first post ).

But ok, I have my own patched fpc-ootb, I use it for years, it works perfectly and solve all my problems.
So, no problem for me, stay blind.

Fre;D

[MarkMLl]

Of course loadlibrary() can be used

It can't if the file you're trying to load is a linker script, see my other posting.

MarkMLl

[Fred vS]

Of course loadlibrary() can be used

It can't if the file you're trying to load is a linker script, see my other posting.

MarkMLl

That .so issue ( https://gitlab.com/freepascal.org/fpc/source/-/issues/32367 ) is exactly what is wrong with fpc.
Something that even Florian agree to fix is not done because some people dont see or dont care of problems of others.

[MarkMLl]

That .so issue ( https://gitlab.com/freepascal.org/fpc/source/-/issues/32367 ) is exactly what is wrong with fpc.
Something that even Florian agree to fix is not done because some people dont see or dont care of problems of others.

No, you miss my point. libc.so is now a linker script, and LoadLibrary() /cannot/ handle it.

I came across this years ago when libusb v0.1 was deprecated and Debian replaced the original file with a linker script, but now it appears to be mainstream.

This is emphatically /not/ an FPC architectural problem, unlike .so.6 etc. which is (since as far as unix is concerned a dot has no special significance in a filename).

MarkMLl

[Fred vS]

Hello Mark.

Ok I miss your point.
My point is that with actual-no patched fpc, at linking, fpc allows to use only libX11.so.

But libX11.so is not given by default in mainly all distros, you need to install it via sudo apt-get install libx11-dev (that will install tons of absolutely no needed files for fpc) or create a symlink to libX11.so.6.

So you need to annoy the end-user to install libx11-dev or create a symlink to be able to run the application.

With the fpc patched that I use, fpc links libX11.so.6 and so no need to oblige users to do boring things to run the application from the release.

[MarkMLl]

With the fpc patched that I use, fpc links libX11.so.6 and so no need to oblige users to do boring things to run the application from the release.

Except that if some forthcoming distro version puts a link script in libX11.so rather than making it into a symlink, you'll still be screwed.

However that one is strictly a library issue, rather than affecting FPC's build architecture or its ability to parse external symbol names.

Added:

As of Debian 11 and 12, these .so files are actually linker scripts:

Code: Text  [Select][+][-]

1. ./usr/lib/x86_64-linux-gnu/libncurses.so: ASCII text
2. ./usr/lib/x86_64-linux-gnu/libc.so: ASCII text
3. ./usr/lib/x86_64-linux-gnu/libncursesw.so: ASCII text
4. ./usr/lib/x86_64-linux-gnu/libusb.so: ASCII text
5. ./usr/lib/x86_64-linux-gnu/libtermcap.so: ASCII text
6. ./usr/lib/x86_64-linux-gnu/libm.so: ASCII text
7. ./usr/lib/gcc/x86_64-linux-gnu/12/libgcc_s.so: ASCII text
8. /usr/local/altera/14.1/quartus/linux64/libtbb.so: ASCII text
9. /usr/local/altera/14.1/quartus/linux64/libtbbmalloc.so: ASCII text
10. /usr/local/altera/14.1/quartus/linux64/libtbbmalloc_proxy.so: ASCII text
11.  

There's several in that lot where LoadLibrary() could usefully be used to pull something in dynamically, so that a program can either fail with a useful error message or could continue with some option disabled (e.g. an app which talks to Arduino-scale backend devices over multiple link types, of which USB is the least significant).

The precise path of the libgcc_s.so file varies with compiler version. The fact that this technique is being used on non-Debian binaries such as the Altera FPGA stuff shown above is particularly worrying.

MarkMLl

[PascalDragon]

My point is that with actual-no patched fpc, at linking, fpc allows to use only libX11.so.

But libX11.so is not given by default in mainly all distros, you need to install it via sudo apt-get install libx11-dev (that will install tons of absolutely no needed files for fpc) or create a symlink to libX11.so.6.

That is how it's supposed to be on Linux. Every C or C++ developer has to do the same.

So you need to annoy the end-user to install libx11-dev or create a symlink to be able to run the application.

Wrong. You need to install the -dev package only for compilation, it's not required for running, because the linker will store the real name of the library in the binary.

[Fred vS]

My point is that with actual-no patched fpc, at linking, fpc allows to use only libX11.so.

But libX11.so is not given by default in mainly all distros, you need to install it via sudo apt-get install libx11-dev (that will install tons of absolutely no needed files for fpc) or create a symlink to libX11.so.6.

That is how it's supposed to be on Linux. Every C or C++ developer has to do the same.

That is exactly the point that we don't agree.

Every C or C++ developer needs (sometime) the -dev package of the library he want to link.
This because gcc or clang needs some files (not only the symlink) like header .h, .a files, ...

But fpc is not a C compiler and all those -dev packages are not for him, he only needs the name of the library to link.

It is maybe supposed to be on Linux but I never saw that law and dont really understand why to impose the limitation to soname.
What will it change for fpc, you can still use the restricted soname, like it is now.

So you need to annoy the end-user to install libx11-dev or create a symlink to be able to run the application.

Wrong. You need to install the -dev package only for compilation, it's not required for running, because the linker will store the real name of the library in the binary.

Yes, of course but I was talking about applications that use fpc (ide for example)