Hi,

MSEgui uses xlib by the units in packages/x11. The linker searches for libX11.so which is not installed on most systems by default so one has to install the libx11 devel package or manually create a symlink libX11.so -> libX11.so.6 in order to compile MSEgui applications. Some users are unable to cope with this or give up with the comment "MSEide+MSEgui does not work on my system".

Is it possible to add libX11.so.6 to the list of searched files for "X11" externals without using dlopen/dlsym?

Thanks, Martin

The only way to do this is to change the lib name to libX11.so.6, as far as I know. There may be some version script trickery, but that would probably require additional compiler directives.

Michael.

Martin Schreiber wrote

MSEgui uses xlib by the units in packages/x11. The linker searches for libX11.so which is not installed on most systems by default so one has to install the libx11 devel package or manually create a symlink libX11.so -> libX11.so.6 in order to compile MSEgui applications.

That is why it is called a devel package: you need it if you develop programs that use this library. That is how development works on Unix systems. We nor you can change that.

Some users are unable to cope with this or give up with the comment "MSEide+MSEgui does not work on my system".

You can ask Linux distributions to make the MSEide+MSEgui package dependent on the x11 devel package. And maybe add some check in your own installation script as well, if you have one (or in the startup of the IDE).

Is it possible to add libX11.so.6 to the list of searched files for "X11" externals without using dlopen/dlsym?

That would be wrong.

Jonas

Hello Martin.

Description of libx11-dev package (in /DEBIAN/control).

Package: libx11-dev
...
Description:

This package contains the development headers for the library found in libx11-6. Non-developers likely have little use for this package. ...

Afaik, fpc does not use the C headers (I did not find it) nor fpc does not develop/change anything inside the libX11 code. Maybe, but I have lot of doubt, fpc could need the C headers to compile himself. But the compiled fpc should not need it.

So, imho, in the case of fpc, they should not use libX11.so but libX11.so.6 when linking things with the binary fpc.

My 0,001 cent.

Fre;D

Hi,

that reminds me of Synapse.

It is always very confusing to people that they need to install libssl-dev to use https, and libssl does not work. Because libssl-dev contains libssl.so or so, while libssl only has libssl.so.1.0.0, which is not found...

And then you tell people to install libssl-dev, and they are even more confused, because they cannot find it, because they are on a distribution where they call it devel-openssl instead.

Cheers,
Benito

libx11-6.

Non-developers likely have little use for this package. ... Afaik, fpc does not use the C headers (I did not find it) nor fpc does

not develop/change anything inside the libX11 code.

Maybe, but I have lot of doubt, fpc could need the C headers to compile

himself.

But the compiled fpc should not need it. So, imho, in the case of fpc, they should not use libX11.so but

libX11.so.6 when linking things with the binary fpc.

The *-dev packages also contain the symbolic link from the library without version to the versioned one. This *is* the way to do this as the names of the library will change with every version.

Regards,
Sven

Please Sven, keep cool.

You have a opinion that every respect, me first.

But maybe it could be interesting to listen to other, even if you think that those people are stupid.

The *-dev packages also contain the symbolic link from the library without version to the versioned one.

IMHO, like explained in package, the package contain symbolic link to the "developer" library.

This library could not be the actual installed on the system (that is a link from libX11.so.6).

FPC acts like a "normal" user of libX11.so library, not as a developer (this is for C programmers who needs the C headers and work on the developer ibX11.so library.)

as the names of the library will change with every version.

Exactly, and it is why, for each fpc version, the appropriate symlink should be assigned ( at the moment libX11.so.6 )

This *is* the way to do this

This *is* your way to see this.

Fre;D

Exactly, and it is why, for each fpc version, the appropriate symlink should be assigned ( at the moment libX11.so.6 )

And this is the OS, with his updates, that will assign symlink libX11.so.6 to the last installed libX11.6.1.2.3.4.so

Fre;D

Fred van Stappen wrote

You have a opinion that every respect, me first.

He gave a description of how linking against libraries from any language (C, Pascal, Go, Ada, ...) works on Unix-like systems. It is not related to opinions. It's simply how it is and has been for the past 60 years or so.

IMHO, like explained in package, the package contain symbolic link to the "developer" library.

A developer in this context is anyone to compiles/links programs that use this library (i.e., program developers). It's not about people who work on the library itself. They don't use the devel package, but the source.

Jonas

> You have a opinion that every respect, me first. It's simply how it is and has been for the past 60 years or so.

Ha, ok, with this argument, I stop to try to change things.

Sorry for the noise.

Fre;D

In our previous episode, Fred van Stappen said:

But maybe it could be interesting to listen to other, even if you think that those people are stupid.

You are talking to the wrong people. If you think this behaviour is incorrect, talk to the powers that be in charge of changing this (read: Linux kernel and distribution maintenance)

Venting frustrations with *nix design on this list is futile.

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).

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.

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

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.

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' ?

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

Fre;D

<http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal>

I was simply trying to clarify that Swen's description was not an opinion, but a fact of how things are. It's important in discussions to distinguish those two things.

I stop to try to change things.

As Marco said, you are complaining to the wrong people. We are not the ones that say that things should be done like this. It's the operating system packagers/maintainers that do so. Not following operating system conventions makes things harder in the long run, not easier. And it makes it harder to integrate seamlessly with other tool chains and work flows on such platforms. It also breaks expectations of long-time users of those platforms (since they know how things are supposed to work on their platform).

Jonas

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...

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 ;)

Wrong. Take an empty program that includes the X unit:

=== code begin ===

program tsoname;
uses
  X;
begin
end.

=== code end ===

The X unit simply contains a "$linklib x11" which is equivalent to importing specific functions using "external 'x11' name ...".

My system looks like this:

=== listing begin ===

lrwxrwxrwx 1 root root 15 27. Feb 17:54 /usr/lib/libX11.so -> libX11.so.6.3.0
lrwxrwxrwx 1 root root 15 27. Feb 17:54 /usr/lib/libX11.so.6 -> libX11.so.6.3.0
-rwxr-xr-x 1 root root 1306096 27. Feb 17:54 /usr/lib/libX11.so.6.3.0

=== listing end ===

And the resulting binary links this (objdump -x output)

=== listing begin ===

(...)
Dynamic Section:
NEEDED libX11.so.6
NEEDED libc.so.6
(...)

=== listing end ===

As you can see the program will work correctly as long as the libX11.so.6 file exists (even though that is a symlink itself, but the X11 project guarantees that different libX11.so.6.x.y are compatible to eachother), because the linker picks the SONAME that is set inside the binary. And the libX11.so.6 symlink is part of the non-devel package.

Neither FPC nor the linker know anything about library versions. They only know the filenames and the SONAMEs. If either can't find the filename it needs than though luck. And the SONAME is the one that's used for the real lookup, but the linker needs the file for that.

And did you even look at the code?

1. the libc unit is deprecated and only exists for Kylix compatibility
2. the LIBC_SO constant is used nowhere (the library constant is "clib" and has the value 'c')

The only other use of "libc.so.6" is in iconvenc_dyn.pas, but that is because it is loading the library dynamically and there the real file *must* be used as the development symlink might not exist after all.

Regards,
Sven

Sven Barth wrote

Wrong. Take an empty program that includes the X unit:

In private I emailed Fred the following URL - it explains in plain English what is required and what really happens in the ELF binary format and such. Fred finally understood. On a side note: I learned something new too. :)

The information in your last reply was spot.

Here is the URL I send Fred. For anybody else, read the question and the first two answers - that should give you all the information anybody needs to understand the process.

https://unix.stackexchange.com/questions/475/how-do-so-shared-object-numbers-work

Regards,
Graeme

Sven, now here is an interesting problem regarding the way FPC (or Object Pascal in general) works with C based libraries. Martin pointed this out in another mailing list, and he gave me permission to forward it here. What is your answer or recommendation to this problem?

-------- Forwarded Message --------
Subject: Re: [MSEide-MSEgui-talk] MSE and XLib.
Date: Thu, 17 Aug 2017 14:54:16 +0200
From: Martin Schreiber
To:

Graeme Geldenhuys wrote

On 2017-08-17 07:18, Martin Schreiber wrote: > I don't understand why FPC uses the version-less library > names instead of the mayor version names where the bindings are

made for.

> Maybe a misunderstanding happened at ancient times... No, they are simply following the guidelines of Unix-type systems - doing everything correctly by the book.

A hypothetical example:

- You make a pascal bindings file for the "greatlibrary" version 1.0.
- You set the library name in the bindings pascal file "great.pas" to "great" as Unix-type systems guidelines command.
- In your system great-devel package of the version 1.0.1 is installed, you have the c-header *.h files of libgreat 1.0.1 and the links libgreat.so -> libgreat.so.1 -> libgreat.so.1.0.1.
- The SONAME of libgreat.so.1.0.1 is libgreat.so.1
- You compile and run the application, libgreat.so.1 -> libgreat.so.1.0.1 is loaded, all is OK.

Now you give the source of the application to a colleague who has installed the newer but incompatible "greatlibrary" version 2.0.3 including the devel package.
- He has the c-header *.h files of libgreat 2.0.3 and links libgreat.so -> libgreat.so.2 -> libgreat.so.2.0.3.
- The SONAME of libgreat.so.2.0.3 is libgreat.so.2
- He compiles your program, the linker links libgreat.so -> libgreat.so.2 -> libgreat.so.2.0.3 and stores the SONAME libgreat.so.2 (remember, libgreat.so.2 and libgreat.so.1 are *not* compatible).

Now there are two possibilities, maybe the function names in libgreat.pas did not change between version 1 and 2 -> the program compiles but crashes because of changed parameters or other incompatibilities.
Or it does not compile and then he needs to install version 1 of "greatlibrary" and deinstall great-devel-2.0.3 and install great-devel-1.0.1 or change manually libgreat.so -> libgreat.so.2 to libgreat.so -> libgreat.so.1 temporarily.
This also must be done in first case in order to produce a working application.

The difference between a FPC bindings unit and a Unix C-header *.h file is that the *.h file is *included* in the devel-package and thus matches the installed version, the pascal file is not included but in a separate package or more likely taken from the FPC tar archive by the FPC install script because FPC Linux/FreeBSD-packages usually are too old or one wants to use a FPC version from SVN.
So the "guidelines for Unix-type systems" are not appropriate for Free Pascal C-library binding units IMHO.

Martin
---------------------------------------------------

Regards,
Graeme

Am 17.08.2017 15:49 schrieb "Graeme Geldenhuys" <

Pascal in general) works with C based libraries. Martin pointed this out in another mailing list, and he gave me permission to forward it here. What is your answer or recommendation to this problem?

Write in your application's readme which versions it requires. It might be true that the devel packages contain the C-headers, but there might nevertheless be failures if the applications
is programmed against the interface of the older v1 library (maybe they changed the memory management for v2 and the problem will only manifest at runtime).

Regards,
Sven

Exactly. So why not use the SONAME in the Pascal binding unit instead to use the base name as Free Pascal currently does in xlib.pp for example?

Martin

Martin Schreiber wrote

Exactly. So why not use the SONAME in the Pascal binding unit instead to use the base name as Free Pascal currently does in xlib.pp for example?

I forked the xlib, xutils and x units from FPC and tried just that. It made no difference. When I compiled the project with the -Cn command line parameter I reviewed the ppas.sh and <project>.res file. The .res file has a INPUT section near the end listing all dependent libraries. They are translated to the same as when you use GCC's -l command line parameter. Only the base name of the library is used. Also, apparently the Unix/Linux linker (FPC doesn't have it's own - only for Windows) doesn't support versioned library names as command line parameters. So I don't think there is much FPC can do - unless I'm still not understanding the whole compiling and linking process, unless FPC implements their own linker under Unix-type OSes too.

Regards,
Graeme

On 17 Aug 2017 21:21, "Graeme Geldenhuys"
wrote:

Martin Schreiber wrote

Exactly. So why not use the SONAME in the Pascal binding unit instead to use the base name as Free Pascal currently does in xlib.pp for example?

I forked the xlib, xutils and x units from FPC and tried just that. It made no difference. When I compiled the project with the -Cn command line parameter I reviewed the ppas.sh and <project>.res file. The .res file has a INPUT section near the end listing all dependent libraries. They are translated to the same as when you use GCC's -l command line parameter. Only the base name of the library is used. Also, apparently the Unix/Linux linker (FPC doesn't have it's own - only for Windows) doesn't support versioned library names as command line parameters. So I don't think there is much FPC can do - unless I'm still not understanding the whole compiling and linking process, unless FPC implements their own linker under Unix-type OSes too.

You can use -l:libgreat.so.1 with gcc to link to a specific library version (iirc).

Henry

In our previous episode, Martin Schreiber said:

Because it is is not packaged with and meant only to work with only one .so name. Changing it will only mean a lot of adminstration, and still breakage if some distribution halfway through the release cycle starts packaging a new version.

Am 17.08.2017 22:20 schrieb "Graeme Geldenhuys" <

use

> the base name as Free Pascal currently does in xlib.pp for example? I forked the xlib, xutils and x units from FPC and tried just that. It

made no difference. When I compiled the project with the -Cn command line parameter I reviewed the ppas.sh and <project>.res file. The .res file has a INPUT section near the end listing all dependent libraries. They are translated to the same as when you use GCC's -l command line parameter. Only the base name of the library is used. Also, apparently the Unix/Linux linker (FPC doesn't have it's own - only for Windows) doesn't support versioned library names as command line parameters. So I don't think there is much FPC can do - unless I'm still not understanding the whole compiling and linking process, unless FPC implements their own linker under Unix-type OSes too.

FPC does have its own, internal ELF linker, though that is not enabled by default currently as it still has its shortcomings. But even then it would follow the conventions of the target OS.

Regards,
Sven

Henry Vermaak wrote

You can use -l:libgreat.so.1 with gcc to link to a specific library version (iirc).

I'll have to take your word for it Henry, as I don't know GCC much - only the bare minimum to compile small C projects. I normally specify things like -lpthreads -lX11 etc. I've never seen a versioned -l parameter being used. I'll try it next time.

Regards,
Graeme

Marco van de Voort wrote

if some distribution halfway through the release cycle starts packaging a new version.

But surely then the program would be broken anyway - in the case of a major version number bump. It is well known that major version changes mean two versions are NOT compatible.

What Martin is getting at is that by looking at the Object Pascal unit, one will then easily be able to see which major version of the library is supported by that header translation *.pp file. The linker will also complain and say that that specific library version is not install. That's a better error that some runtime crash or error about a API parameter that is now slightly different.

And just to be clear, by saying using the versioned library in the header translation unit, you will use the versioned library that only mentions the major version. eg: 'libgreat.so.1' and not 'libgreat.so.1.2.7'

Either way, I tried the latter as I mentioned, and it made no difference to FPC. Somewhere the version info was stripped and only the base name was passed to the linker.

Regards,
Graeme

Did you remove the various {$linklib} statements too? Did you check all units which where included by "uses" statements? BTW I tried to fork xlib.pp too but gave up because of the too many files which hat do be forked and it was too dangerous for existing projects.

Martin

Am 18.08.2017 01:17 schrieb "Graeme Geldenhuys" <

version

> (iirc). I'll have to take your word for it Henry, as I don't know GCC much - only

the bare minimum to compile small C projects. I normally specify things like -lpthreads -lX11 etc. I've never seen a versioned -l parameter being used. I'll try it next time.

Passing a name with ":" to the linker works (on Linux at least). I used that when I tested dynamic packages and wanted the linker to use "librtl.ppl" instead of "librtl.so" ;)

Regards,
Sven

I checked with a simple library file, it seems that FPC strips the ".so*" part from "external" names. So the only way to make version-safe binding units in Free Pascal seems to be to use dlopen()/dlsym().
Is this intended?

Martin

Martin Schreiber wrote

Did you remove the various {$linklib} statements too? Did you check all units which where included by "uses" statements?

Yes to both.

Regards,
Graeme

Martin Schreiber wrote

I checked with a simple library file, it seems that FPC strips the ".so*" part from "external" names.

Exactly what I discovered too. :-/

So the only way to make version-safe binding units in Free Pascal seems to be to use dlopen()/dlsym().

That was my conclusion as well.

Regards,
Graeme

If one manually changes in link.res
"
INPUT(
-lX11
)
"
to
"
INPUT(
-l:libX11.so.6
)
"
the application links without errors despite there is no libX11.so -> libX11.so.6 link.

Martin

Martin Schreiber wrote

If one manually changes in link.res

hahaha... You read my mind, I was going to try that today in my lunch time. :-)

So now all that FPC needs is a new compiler parameter to tell it how to generate the linker parameters, and when the alternative is specified, not to strip the version info from the library name. That sounds doable with no immediate harm to existing projects (after all, it will be a new command line parameter).

Regards,
Graeme

Martin Schreiber wrote

the application links without errors despite there is no libX11.so -> libX11.so.6 link.

I quickly tested under FreeBSD 10.3. Even thought FreeBSD doesn't have *-devel packages like Linux does. All ports packages (binary or build from source) include unversioned and versioned library names.

Anyway, the -l:libname.so.1 style linker parameter also works under FreeBSD. I could link a project without problems. To make doubly sure, I deleted the libX11.so symlink file and managed to link my project successfully. It also run without problems (didn't expect any issues here). So using the versioned library names definitely works.

Regards,
Graeme

Or simply treat a leading colon as start of a filename as ld does.

Martin