TOPIC:

Hello Sternas.

Did you follow this:

free-pascal-general.1045716.n5.nabble.co...names-td5729437.html

It was the continuation of that:

mseide-msegui-talk.13964.n8.nabble.com/M...SE-and-XLib-td5.html


In short:

fpc does not understand how to deal with unix static linking of libraries.

Martin (and I) try to explain the right way but they do not want to understand.

Also, there is a problem with "external" parameter for defining soname.

IMHO Code Typhon has much more knowledge in dealing with libraries so the question is:

Now that the problem of loading libraries in /fpc/packages/ is clearly pointed, what do you think to make a revolution:

---> Fix all that packages and offer, for all packages (and in first for libC and libX11) a dynamic loader-header (not only the "common" static header but also a dynamic header).

This to profit of all advantages of dynamic loading of libraries.

Fre:D

Sir, please
give us time to find a solution

(I am not in the lab now... )

> give us time to find a solution

Huh, no worry Sternas, of course it is not for now.

But, IMHO, it could be the occasion to finally fix that old bugs ( versioned library names + not strips the ".so*" part from "external" names).

And if you are inside the pascal header code, why not create also a dynamic loading header for that library.

And at the end, create a /fpc/CT_dyn_packages/ with dynamic loading headers for all libraries.

So people could choose or to link statically their application using "official" /fpc/packages/ or link dynamically using /fpc/CT_dyn_packages/

PS: I f you need help to translate a static header into a dynamic header, I will help with pleasure.

Fre;D

The facts are:

libX11.so NOT exists on Linux/GNU
libX11.so.6 exists on Linux/GNU

libc.so NOT exists on Linux/GNU
libc.so.6 exists on Linux/GNU

libfreetype.so NOT exists on Linux/GNU
libfreetype.so.6 exists on Linux/GNU

and we have problems with these files.

I will stop any other activity,
here in our lab to solve theses problems.
We can test on any OS, anything

Sir, your suggestion

The second thing is

We update CodeTyphon fpgui_toolkit to Ver 6.3.1 Source GIT hash : a4072cacdf3b66632bc64d8ce0a31f1b0bc434a4
from now, we will use your trunk version.
A simple "Thanks" for your work Sir

Screens from:
-Windows 10 64Bits (yes...)
-Debian 9 64Bits

> Sir, your suggestion

Huh, about what ?

The fixes are not difficult at all. (it is why I do not understand why they do not want to do it)

See my last post in mseide-msegui-talk.13964.n8.nabble.com/M...and-XLib-td5i20.html

Now that everybody "finally understood", let's do a resume.

The fpc code is perfect to show all the situations possible.

In xlib.pp they assigned as soname:

const
libX11='X11';

So, like perfectly explained in Graemes's infos, the linker automaticaly add "lib" + ".so" ---> the soname will be libX11.so

So a libX11.so must exist.

The soname is assigned with "external":

Example:
procedure XrmInitialize; cdecl; external libX11;

The correct way should be:

const
libX11='libX11.so.6';

That way, the linker do not add the prefix "lib" and the suffix ".so" and the soname will be 'libX11.so.6'.

_____

In xinerama.pp there the soname is "hardcoded", no constant or variable is used:

They do:

function XineramaIsActive(dpy:PDisplay):TBoolResult;cdecl;external 'Xinerama';

And here also the linker automaticaly add "lib" + ".so"
__

In xft.pp they nearly do the right way.

libXft = 'libXft.so';

Here the linker will not add prefix and suffix.

procedure XftDrawDestroy(draw : PXftDraw); cdecl; external libXft;

But the right way would be to use : libXft = 'libXft.so.2';

___


Huh, I have check all the fpc packages ---> all are wrong. ;-(

And I was also wrong saying that libc was ok.

In fact LIBC_SO = 'libc.so.6' ---> is never used.

In lbc.pp they do:

Const

clib = 'c'; (the rigth way should be : clib = ''libc.so.6')

The only problem is that fpc strips the ".so*" part from "external" names.

I did not check in fpc code where they assisgn the soname with "external", like in:

procedure XrmInitialize; cdecl; external libX11;

But they should not strips the ".so*" part from "external" name.

About suggestion for dynamic loading of libraries all will be more easy when the correct soname are assigned..

But that is for later.

Fre;D

OK
we will test and report.

We write an OS command file
ln1_SysLibraries_Make_Links.sh
to solve these problems...

We update CodeTyphon fpgui_toolkit

Huh, Sternas, that problem does not affect only fpGUI or MSE, it affect all fpc, included LCL (and so also Code Typhon).

Fre;D

ln1_SysLibraries_Make_Links.sh

Yes, I know and it is because of your script (that include apt-get install libX11-dev.) that I understood the fpc problem.
Normally, libX11-dev should NOT be needed to run fpc + libX11.

Same for libc-dev

Fre;D

Tomorrow all day
we will be working on these problems ...

Tomorrow all day
we will be working on these problems

It is very difficult to explain that problems.
I am banned from fpc mailing-list because this.

But it will solve **many** other problems. For example for the databases packages (the major version soname change on each update).

Maybe you could check what is in libX11-dev.deb package.

There is in the package:

- in /usr/lib ---> libX11.so (the famous) that link to ----> libX11.so.6.2.1.3
- in /usr/lib ---> libX11.a ---> this is used when you link the library **inside** the executable ---> not used by fpc.
- in /usr/include/X11 ---> all the C headers of that library ---> not used by fpc.

libX11-dev is for C developers or if you want to include all the library in the exe (by the way, fpc do not understand how to do this).

Sternas, IMHO, you should read slowly, carefully all the discussions in:

free-pascal-general.1045716.n5.nabble.co...names-td5729437.html

and

mseide-msegui-talk.13964.n8.nabble.com/M...SE-and-XLib-td5.html

But I agree, it is not easy to understand.

Good luck.

Fre;D

Most important:
www.mail-archive.com/mseide-msegui-talk%...ge.net/msg11384.html
www.mail-archive.com/mseide-msegui-talk%...ge.net/msg11386.html

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.

www.mail-archive.com/fpc-pascal%40lists....al.org/msg46926.html

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