- Posts: 170
- Thank you received: 1
Question New feature of CT compiler.
- fredvs
- Topic Author
- Offline
- Junior Member
-
I would really like that CT compiler has the possibility to deal with "so.n" part of the library on Unix systems.
At the moment, fpc does not allow to load, for example, libportaudio.so.2, only libportaudio.so can be loaded.
The same for many other libraries, with fpc you oblige people to install the thelib-dev package that can create problems.
Please, read that issue, Martin did explain perfectly how to fix that in fpc code:
bugs.freepascal.org/view.php?id=32367
It is not difficult to fix and will NOT make any problems of compatibility with previous version.
The only thing that it will do is to fix **lot of** problems.
Fre;D
PS: Take care of you.
Please Log in or Create an account to join the conversation.
- Matis A.
-
- Away
- Moderator
-
PilotLogic Core Programmer
Please Log in or Create an account to join the conversation.
- fredvs
- Topic Author
- Offline
- Junior Member
-
- Posts: 170
- Thank you received: 1
The problem is in FPC "Static linking" of Unix libraries ?
Yes, exactly, when you use in code "external" to load a library, your library name must be something like "mylibrary.so".
If you use as name "mylibrary.so.2", fpc will automatically remove the ".2" part of the name.
That has no sense for Pascal language, indeed with Java-Android it is not allowed but Pascal has not that restriction.
Because of this strange decision of fpc, I am obliged to use "Dynamic loading" of libraries (loadlib()) for libraries with so number.
Also it makes lot of problems with "Static linking" of Unix libraries, you are not allowed to load a particular version of a library.
There is the solution to install the mylibrary-dev pakage that will create a symlink mylibrary.so but it can be problems because that symlink point with the develop version of the library that maybe uses a other header.
In short, please, let the people free to choose what library version he want.
Fre;D
Please Log in or Create an account to join the conversation.
- fredvs
- Topic Author
- Offline
- Junior Member
-
- Posts: 170
- Thank you received: 1
const
mylib = 'mylib.so';
procedure myproct(); cdecl; external mylib;
=
const
mylib = 'mylib.so.2';
procedure myproct(); cdecl; external mylib;
This because at compilation fpc will remove the ".2" part of mylib.so.2 and then link to mylib.so instead.
That is very bad.
Also the dev packages should be installed only for C developers working with the trunk library.
If you take a look at info inside a dev package, it is noted.
Dev package contains the C headers for the "trunk" library that could not be the one installed on the system.
To make life simpler for those C developers, the dev package creates also a symlink without so number that point to the "trunk" library.
So, by convention, a symlink without so number point to the last trunk library.
But why to impose to people to install dev package and this only because a strange fpc restriction that can be easily be removed.
Fre;D
Please Log in or Create an account to join the conversation.
- Matis A.
-
- Away
- Moderator
-
PilotLogic Core Programmer
Please Log in or Create an account to join the conversation.
- fredvs
- Topic Author
- Offline
- Junior Member
-
- Posts: 170
- Thank you received: 1
You will see, once this fixed, no more problems for example with OpenSLL because you may assign the version you want.
Fre;D
Please Log in or Create an account to join the conversation.
- fredvs
- Topic Author
- Offline
- Junior Member
-
- Posts: 170
- Thank you received: 1
In previous post, I forget to add the first case
Example:
const
mylib = 'mylibrary'; // without ".so"
procedure myproct(); cdecl; external mylib;
=
const
mylib = 'mylibrary.so'; // here compiler will remove ".so" hmmm, very strange idea.
procedure myproct(); cdecl; external mylib;
=
const
mylib = 'mylibrary.so.2'; // here compiler will remove ".so.2" ------> That is a VERY bad idea.
procedure myproct(); cdecl; external mylib;
For example. in unit openssl.pas, they do:
DLLSSLName: string = 'libssl';
The logical, unix, good boy way should be:
DLLSSLName: string = 'libssl.so.1.1';
But if you do that, fpc will remove ".so.1.1" at compilation, without any warning and link with libssl.so, obliging people to install dev package of libssl.
Other example:
In unit xlib.pp
const
libX11='X11'; ....
Should be:
const
libX11='libX11.so.6'; // Here fpc will remove '.so.6' and 'lib'
And this only to have a symlink without so number...
I hope you did understand.
Fre;D
Please Log in or Create an account to join the conversation.
- Matis A.
-
- Away
- Moderator
-
in fpcsrc\compiler\link.pas
Do you have any CT small test project to work in to ?
PilotLogic Core Programmer
Please Log in or Create an account to join the conversation.
- fredvs
- Topic Author
- Offline
- Junior Member
-
- Posts: 170
- Thank you received: 1
I would be very happy to test it with xlib.pp (see my previous last example).
For example, when you install MSEgui or fpGUI, because of that limitation, you must install also xlib-dev.
If your fix works, people will not be obliged to install it.
But the same for OpenSSL and many others.
Fre;D
Please Log in or Create an account to join the conversation.
- fredvs
- Topic Author
- Offline
- Junior Member
-
- Posts: 170
- Thank you received: 1
At line 15, change:
libX11='X11';
with
libX11='libX11.so.6';
Re-compile CT-fpc
And try it to see if all is ok with X11 rendering.
Fre;D
Please Log in or Create an account to join the conversation.
- fredvs
- Topic Author
- Offline
- Junior Member
-
- Posts: 170
- Thank you received: 1
Fre;D
Please Log in or Create an account to join the conversation.
- Matis A.
-
- Away
- Moderator
-
CT-FPC can static link libX11.so.6 or X11.so.6888
I think the Unix linker (ld) has some "rules." or "checks"..

Give us time to test.
We open a dev-channel, with some Linux kernel programmers for this...
.
PilotLogic Core Programmer
Please Log in or Create an account to join the conversation.
- fredvs
- Topic Author
- Offline
- Junior Member
-
- Posts: 170
- Thank you received: 1
Without patch in fpcsrc\compiler\link.pas
CT-FPC can static link libX11.so.6 or X11.so.6888
Not understand.
Of course if your symlink libX11.so point to X11.so.6888 and you have libX11='X11';
Please Log in or Create an account to join the conversation.
- fredvs
- Topic Author
- Offline
- Junior Member
-
- Posts: 170
- Thank you received: 1
Give us time to test.
We open a dev-channel, with some Linux kernel programmers for this...
First try this, without patch:
1) Delete all symlink libX11.so [EDIT] and libX11.a from the system. [EDIT] (or rename it like libX11test.so)
2) In xlib.pp in package /packages/x11/src/xlib.pp
At line 15, change:
libX11='X11';
with
libX11='libX11.so.6';
[EDIT]
Re-compile CT-fpc,
Now try, with that new CT-fpc, to compile a CT application on Linux, you will have a error at linking like this:
/usr/bin/ldĀ : can not find -lX11
If your patch is ok, no error.
Please Log in or Create an account to join the conversation.
- fredvs
- Topic Author
- Offline
- Junior Member
-
- Posts: 170
- Thank you received: 1
For fixing the bug it is easy:
In /compiler/link.pas, at line 503 just remove the lines that delete the extension and the prefix:
Procedure TLinker.AddSharedLibrary(S:TCmdStr);
begin
if s='' then
exit;
{ remove prefix 'lib' }
// if Copy(s,1,length(target_info.sharedlibprefix))=target_info.sharedlibprefix then
// Delete(s,1,length(target_info.sharedlibprefix));
{ remove extension if any }
// if Copy(s,length(s)-length(target_info.sharedlibext)+1,length(target_info.sharedlibext))=target_info.sharedlibext then
// Delete(s,length(s)-length(target_info.sharedlibext)+1,length(target_info.sharedlibext)+1);
{ ready to be added }
SharedLibFiles.Concat(S);
end;
and the same at line 533:
Procedure TLinker.AddSharedCLibrary(S:TCmdStr);
begin
if s='' then
exit;
{ remove prefix 'lib' }
// if Copy(s,1,length(target_info.sharedclibprefix))=target_info.sharedclibprefix then
// Delete(s,1,length(target_info.sharedclibprefix));
{ remove extension if any }
// if Copy(s,length(s)-length(target_info.sharedclibext)+1,length(target_info.sharedclibext))=target_info.sharedclibext then
// Delete(s,length(s)-length(target_info.sharedclibext)+1,length(target_info.sharedclibext)+1);
{ ready to be added }
SharedLibFiles.Concat(S);
end;
And in /compiler/systems/t_linux.pas, at line 603 change the line with this:
if (s<>'c') or reorder then
begin
i:=Pos(target_info.sharedlibext,S);
if i>0 then
// Delete(S,i,255); // comment that
Insert(':',s,1); // change with this, ":" is needed when you use the full name with extension.
Add('-l'+s);
libraryadded:=true;
end
Now for the case of Xlib, if you want in all CT-fpc source to do like it should be, you should replace all:
{$LinkLib X11}
{$LinkLib libX11.so.6}
and
const libX11='X11';
const libX11='libX11.so.6';
Anyway, if you could already fix the bug (with link.pas and t_linux.pas) it would be already great.
And if you are courageous to replace all the call to libX11='X11' with libX11='libX11.so.6' and {$LinkLib X11} with {$LinkLib libX11.so.6} it would be perfect.
Fre;D
Included link.pas and t_linux.pas
[EDIT]
OK, I did change all code with {$LinkLib libX11.so.6} and libX11='libX11.so.6' in trunk fpc 3.3.1, that means in:
/packages/gtk1/src/gtk/gtk.pp, /packages/x11/src/xlib.pp, /packages/x11/src/x.pp, /packages/x11/src/xrender.pp,
/packages/x11/src/xresource.pp, /packages/x11/src/xshm.pp, /packages/x11/src/xutil.pp, /packages/x11/src/xkb.pp
/packages/gtk1/src/gdk/gdk.pp, /packages/gtk1/src/gtk/gtk.pp
And compiled fpc.
Perfect, now libX11.so.6 is loaded, no more libX11.so.
If you want those files, I give you with pleasure too.
[EDIT] Fixes for libX11 are added too in attachment.
Fre;D
Please Log in or Create an account to join the conversation.
- Matis A.
-
- Away
- Moderator
-
We can fix CT-FPC, but then has problem the Typhon IDE.
a) /compiler/link.pas don't need patch code.
b) All /compiler/systems/t_xxx.pas files
need to apply patch code.
c) Insert(':',s,1); Don't work for us
PilotLogic Core Programmer
Please Log in or Create an account to join the conversation.
- fredvs
- Topic Author
- Offline
- Junior Member
-
- Posts: 170
- Thank you received: 1
a) /compiler/link.pas don't need patch code.
Of course if you dont want to allow people to choose a library with so number.
b) All /compiler/systems/t_xxx.pas files
need to apply patch code.
No, the patch in /compiler/link.pas do not affect previous code, you may still use mylib = mylibrary (without any extension)
c) Insert(':',s,1); Don't work for us
Then sure you have done a error somewhere, here result of the script file to the linker if you use -sh parameter at compil:
Included link.res from the compiler.
[EDIT] Did you try with the t_linux.pas that I give you in attachment in previous post?
INPUT(
-lpthread
-l:libc.so
-l:libX11.so.6
-l:libdl.so
-l:libpthread.so
-l:librt.so
-lm
)
, we stop this Lab task.
Pffff, ok, so CT-fpc will be exactly the same than fpc in fact, nothing better.
Very, very, very sad.
I am very disappointed.
;-(
Good luck CT.
Fre;D
Please Log in or Create an account to join the conversation.
- fredvs
- Topic Author
- Offline
- Junior Member
-
- Posts: 170
- Thank you received: 1
Please Log in or Create an account to join the conversation.