But what about dynamically load libc.so with dynlbs ( dynlibs.pas himself needs a little change to not link to libc.so, I try it and did not find any problem) ?
DynLibs (or more precisely unit dl) requires the C library, because it is very likely that the user is loading a library that requires the C library as well and thus the application needs to correctly initialize the C library from the start, not to mention that libdl does depend on libc anyway. This is also mentioned in unit dl:
{$if defined(linux)}
{ if libc is not linked explicitly, FPC might chose the wrong startup code, as
libdl depends on libc on linux, this does not hurt }
{$linklib c}
{$endif}
Hello Sven.
Of course I did see it and did try to remove {$linklib c} and in place did a intlibc dynamically ( so no more link to libc ) and it works perfectly.
If you want I can give a demo.
You know, surely, that a fpc application compiled on last Ubuntu or Debian distro does not run on last ArchLinux and Fedora distros.
This because Ubuntu or Debian distros use libc.so.6 version 2.31 and ArchLinux and Fedora use libc.so.6 version 2.34. (and vice-versa)
And if you link libc.so, the exact same sub version is needed, it is not the case with dynlibs.
You need to compile on the older system then it will also run on the newer one. This is also the case for C applications and by design.
Sorry Sven, I apologize a lot, but it is not right, you may try, compile a fpc app that link to libc.so on last Ubuntu, it will fail to run on last ArchLinux and Fedora because sub-version are not identical.
May I ask what must be done if a new unit is added in the rtl and if that unit is used by a other unit of the rtl?
I did try, only adding the unit and recompile fpc, the compiler compiles ok but when compiling the new unit needed by the other rtl unit, the compilation fail with this:
What exactly did you do? Your description can mean anything...
It is for the new
fpc-dynload-libc.so game.
I did begin with the first unit that link to libc.so = /fpcsrc/3.2.2/rtl/linux/si_c.pp
In si_c.inc, removed all use of "external"
{var // all removed
libc_environ: pchar; external name '__environ';
libc_fpu_control: word; external name '__fpu_control';
libc_init_proc: procedure; external name '_init';
libc_fini_proc: procedure; external name '_fini';
procedure libc_atexit; external name '__libc_atexit';
procedure libc_exit; external name '__libc_exit';
procedure libc_init; external name '__libc_init';
procedure libc_setfpucw; external name '__setfpucw';
procedure libc_start_main; external name '__libc_start_main';
}
var
fpc_ret,fpc_ret_rbp : pointer;
And in unit si_c added: mselibc:
unit si_c;
interface
uses
mselibc;
That
mselibc.pas has the removed procedures declared in
si_c.inc.
And dont have any unit in "uses" section.
Now what to do?
I have copy
mselibc.pas in /fpcsrc/3.2.2/rtl/linux/ because otherwise si_c does not find it.
But after this there was a error because
mselibc.pas did not find
objpas unit, so I copy that unit into /fpcsrc/3.2.2/rtl/linux/.
At the end all units where found and it compiles ok till that internal-error:
I know perfectly that the way to add units is absolutely not the right way, so, concretely, what must I do for that
mselibc.pas is accepted in rtl?