[CLOSED] External limitation

[MarkMLl]

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

Rub^H^H^H I am uncomfortable with that. Every developer of the target library needs to install the -dev package, but a mere user (e.g. accessing it from FPC with or without the Lazarus IDE) doesn't.

This has been a problem for a very, very long time, and first showed its head with things like libpq (PostgreSQL client library) which is why the Lazarus IDE specifically has a library loader (TSQLDBLibraryLoader was added in around 2012) although I'm sure that plenty of other people have perforce coded their own equivalent.

MarkMLl

[Fred vS]

Every developer of the target library needs to install the -dev package, but a mere user (e.g. accessing it from FPC with or without the Lazarus IDE) doesn't.

Exactly !
The libX11-dev package is for the developers of the libX11 library, that has C source and the libX11-dev package has the C header file, some static already compiled files, documentation and some tools to do the life easier for the C developers (or explorer) of that libX11 library.

No one single file of the libX11-dev package is used by fpc (apart the "nude" symlink libX11.so that will always and forever target libX11.so.6 because X11 is dead and will never release a new libX11.so.7, all the energy of the remained X11 core developers is focused to XWayland to make applications compiled using X11 compatible with Wayland.)

And the earth is not quite flat.

[Leledumbo]

Debian disagrees

Shame on me, Manjaro also disagrees. It's the other way around, apparently. BUT, I think my argument still stands, where you can still repoint the version numberless library to whatever exact version you want.
This is how I escaped the requirement of the latest patched version of libQt5Pas on my machine:

Code: [Select]

lrwxrwxrwx 1 root root      18 Feb 27 03:58 /usr/lib/libQt5Pas.so -> libQt5Pas.so.1.2.9
lrwxrwxrwx 1 root root      19 Apr  4 19:00 /usr/lib/libQt5Pas.so.1 -> libQt5Pas.so.1.2.12
lrwxrwxrwx 1 root root      18 Feb 27 03:58 /usr/lib/libQt5Pas.so.1.2 -> libQt5Pas.so.1.2.9
-rwxr-xr-x 1 root root 2451504 Feb 27 03:58 /usr/lib/libQt5Pas.so.1.2.9
You see one is betraying the pattern.

[PascalDragon]

The libX11-dev package is for the developers of the libX11 library, that has C source and the libX11-dev package has the C header file, some static already compiled files, documentation and some tools to do the life easier for the C developers (or explorer) of that libX11 library.

Wrong. The -dev packages are intended for developers that want to compile programs that use said library. If said program is then distributed using the package system of that distribution then the -dev package isn't required anymore, cause the normal package will be enough as the compiled program will only contain a reference to that library's name.
If one wants to modify a library then the -dev package is the wrong one as that is not the intended purpose of the package.

No one single file of the libX11-dev package is used by fpc (apart the "nude" symlink libX11.so that will always and forever target libX11.so.6 because X11 is dead and will never release a new libX11.so.7, all the energy of the remained X11 core developers is focused to XWayland to make applications compiled using X11 compatible with Wayland.)

The universe does not only exist of libX11. There are other libraries that do change their version number in the name quite often.

[Fred vS]

The libX11-dev package is for the developers of the libX11 library, that has C source and the libX11-dev package has the C header file, some static already compiled files, documentation and some tools to do the life easier for the C developers (or explorer) of that libX11 library.

Wrong. The -dev packages are intended for developers that want to compile programs that use said library. If said program is then distributed using the package system of that distribution then the -dev package isn't required anymore, cause the normal package will be enough as the compiled program will only contain a reference to that library's name.
If one wants to modify a library then the -dev package is the wrong one as that is not the intended purpose of the package.

What's wrong ?
From https://packages.debian.org/sid/libx11-dev

This package provides a client interface to the X Window System, otherwise
known as 'Xlib'.  It provides a complete API for the basic functions of the
window system.
This package contains the development headers for the library found in
libx11-6.
Non-developers likely have little use for this package.

What can fpc do with development headers for the library ?

No one single file of the libX11-dev package is used by fpc (apart the "nude" symlink libX11.so that will always and forever target libX11.so.6 because X11 is dead and will never release a new libX11.so.7, all the energy of the remained X11 core developers is focused to XWayland to make applications compiled using X11 compatible with Wayland.)

The universe does not only exist of libX11. There are other libraries that do change their version number in the name quite often.

And?
What has this to do with disable that stupid restriction of soname?
If you want to use restricted soname, nothing will prevent you from still using it.

Ok, I stop, tired of talking in front of deaf walls.

[TRon]

What has this to do with disable that stupid restriction of soname?
If you want to use restricted soname, nothing will prevent you from still using it.

No offense but I believe you are missing a point there Fred.

Yes, /we/ do not care about the c-header files as we use our own.

And, nothing will prevent you from using version numbers in so names. But in that case you put the burden of keeping track of those version numbers to yourself instead of letting the maintainers of your used distribution take care of it for you. If using different generation releases of distributions is not disturbing enough you would then have to keep track of/for every individual updated system (not everyone updates their system, let alone doing so at the same rate).

It is tedious, boring and no fun but if you want to then you can of course use your own invented (link) system. imho pita.

You have (more or less) a point when it comes to libx11 specifically but that is rather an exception to the rules.

[Fred vS]

You have (more or less) a point when it comes to libx11 specifically but that is rather an exception to the rules.

Hum, no it is not an exception.
PortAudio library has 2 versions that are not compatible: libportaudio.so and libportaudio.so.2 ( I let you imagine what to do with fpc to link portaudio.so.2 if both libraries are installed.)

Also all the problems with SSL libraries at linking could be easier fixed.

Why always this fear of giving freedom of choice to people?

[TRon]

Also all the problems with SSL libraries at linking could be easier fixed.

Why always this fear of giving freedom of choice to people?

I'm sorry as I do believe I misunderstand what you are trying to say with your posts.

imho the SSL solution is exactly a good example of what mess you are getting yourself into when trying to solve things manually. For SSL you need to combine the correct version numbers of different shared libraries. Whatever those valid combination are is a tedious things to figure out (as far as my knowledge goes FPC does not even support /all/ valid available combinations).

And the SSL example is in comparison a simple example as that is about combining 2 different shared libraries. Imagine if you would have to take care of 10 or 20 different libraries that are part of a single package and use whatever combination of version numbers for those libraries that the package dictates to be working with each other.

So imho you are advertising your idea with the wrong examples. Therefor I can only conclude that I misunderstand that it is what you are trying to tell.

Just for the record, if you wish to do so (as is with the SSL example you referred to) then you are allowed to do exactly as you seem to suggest. Nobody is trying to prevent you from using whatever (shared) library with their explicit version number. The freedom of choice (not fear) is already there.

In an attempt to figure out what it is you are referring to:  Perhaps you'd argue that the current used unit headers in FPC for such packages/libraries do not have a provision to use explicit version numbering. To that I would say: The SSL solution is able to show how to implement such a thing by dynamically loading the version numbers of the libraries if you so wish to do so and for those packages/library headers that do not support it, it can be added. That developers do not add support for it by default is another topic (as said, tedious boring etc).

So, I strongly believe somewhere along the line something goes wrong in the communication ?

[Fred vS]

I strongly believe somewhere along the line something goes wrong in the communication ?

Yes, that is the problem.
Martin and I tried to explain that the restriction of soname is a problem for us, who dont use fpc LCL and want to have something out-of-the-box.
I showed that it is allowed to clang, gcc even Xylix, a Borland-Delphi project.
So, to the fpc team, please close the issue https://gitlab.com/freepascal.org/fpc/source/-/issues/32367

Sorry for the noise ( and this time I will be silent for a long time ).

Fre;D