Recent

Author Topic: Call to libc.so methods.  (Read 2214 times)

Fred vS

  • Hero Member
  • *****
  • Posts: 3158
    • StrumPract is the musicians best friend
Call to libc.so methods.
« on: August 11, 2022, 04:06:57 pm »
Hello.

In /fpc/rtl, for Unix OS, some units use methods from libc.so.
For this, the methods are declared with "external" and link to libc.so.

OK, but sometime the same methods are declared in other /fpc/rtl units.

Would it not be good to have all the methods needed regrouped into updated libc.pp and add in uses-section "libc" when a libc method is used?
And remove all the "external" declarations in  /fpc/rtl units?
« Last Edit: August 11, 2022, 04:29:03 pm by Fred vS »
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Call to libc.so methods.
« Reply #1 on: August 11, 2022, 05:53:33 pm »
That is a faq: https://wiki.freepascal.org/libc_unit

IOW, the UNIT libc is dead since 2003, and only is provided as a by product for kylix compatibility for 32-bit Linux. It has no place in system interfaces whatsoever, and never had it anyway.
« Last Edit: August 11, 2022, 05:57:29 pm by marcov »

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: Call to libc.so methods.
« Reply #2 on: August 11, 2022, 06:00:40 pm »
Most important part is the first line:
"The libc unit (not to be confused with the libc library (.so)) is a header to the libc library created for Kylix compatibility."
Specialize a type, not a var.

Fred vS

  • Hero Member
  • *****
  • Posts: 3158
    • StrumPract is the musicians best friend
Re: Call to libc.so methods.
« Reply #3 on: August 11, 2022, 06:26:34 pm »
@ Marcov and Thaddy: Of course I did read this and know that is not used anymore, like explained in first post.

The question is: why not use a new updated libc.pas, with all the methods declared in the /fpc/rtl unis into one libc.pp.
( I am very happy that you answer but, please, read my post first).
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

Fred vS

  • Hero Member
  • *****
  • Posts: 3158
    • StrumPract is the musicians best friend
Re: Call to libc.so methods.
« Reply #4 on: August 11, 2022, 06:50:00 pm »
For example, MSEgui has a very complete, working mselibc.pas, and each time that a unit needs to call a libc.so method, instead to add definition with "external" , in "uses" section is added "mselibc".

And the proposition is, why not do this for fpc, using a updated (why not mselibc) fpclibc.pp and remove all the "external" declaration in /rtl unit and add fpclibc in uses section?

Of course it is lot of work but, apart this, what are the disadvantages with centralized-libc-methods unit?
« Last Edit: August 11, 2022, 07:00:56 pm by Fred vS »
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Call to libc.so methods.
« Reply #5 on: August 11, 2022, 11:07:25 pm »

Of course it is lot of work but, apart this, what are the disadvantages with centralized-libc-methods unit?

The central premise is to have libcless binaries. Only things like locale and threading pull in libc.

There is also an option to use libc for most calls, but that is under IFDEF (FPC_USE_LIBC) and not default active.

These are all things you ought to know as long time FPC *nix user.
« Last Edit: August 11, 2022, 11:09:18 pm by marcov »

Fred vS

  • Hero Member
  • *****
  • Posts: 3158
    • StrumPract is the musicians best friend
Re: Call to libc.so methods.
« Reply #6 on: August 11, 2022, 11:27:24 pm »

Of course it is lot of work but, apart this, what are the disadvantages with centralized-libc-methods unit?

The central premise is to have libcless binaries. Only things like locale and threading pull in libc.

There is also an option to use libc for most calls, but that is under IFDEF (FPC_USE_LIBC) and not default active.

These are all things you ought to know as long time FPC *nix user.

It would be very nice (but maybe not possible) that all the /rtl/ packages, in Linux, could not use libc.so nor link to libc.so (or if not possible, instead dynamic load libc.so).

I would be very happy if I can avoid this at linking:

Code: Pascal  [Select][+][-]
  1. INPUT(
  2. -l:libc.so
  3. ...
  4. )
  5. GROUP(
  6. -lc
  7. )

Is it possible using the rtl without linking to libc.so?
Because there is always this in script-link:

Code: Pascal  [Select][+][-]
  1. INPUT(
  2. fpc/units/x86_64-linux/rtl/si_c.o

And si_c.pp use "external libc" so it links to libc.so.
« Last Edit: August 11, 2022, 11:36:17 pm by Fred vS »
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

Fred vS

  • Hero Member
  • *****
  • Posts: 3158
    • StrumPract is the musicians best friend
Re: Call to libc.so methods.
« Reply #7 on: August 12, 2022, 12:15:05 am »
Yes, it is me again  :-[

I will try to explain with code.

This empty program:
Code: Pascal  [Select][+][-]
  1. program testclib;
  2. begin
  3. end.

Compiled with > fpc -sh testlibc.pas

Gives that script:
Code: Pascal  [Select][+][-]
  1. INPUT(
  2. /usr/lib/fpc/3.2.2/units/x86_64-linux/rtl/si_prc.o
  3. /usr/lib/fpc/3.2.2/units/x86_64-linux/rtl/abitag.o
  4. testlibc.o
  5. /usr/lib/fpc/3.2.2/units/x86_64-linux/rtl/system.o
  6. )

Nice, no link to libc.so  ;)

But with this for example:
Code: Pascal  [Select][+][-]
  1. program testclib;
  2. uses
  3. dynlibs;   // from rtl
  4. begin
  5. end.

Gives that script:
Code: Pascal  [Select][+][-]
  1. INPUT(
  2. /usr/lib/x86_64-linux-gnu/crti.o
  3. /usr/lib/gcc/x86_64-linux-gnu/10/crtbegin.o
  4. /usr/lib/fpc/3.2.2/units/x86_64-linux/rtl/si_c.o
  5. /usr/lib/fpc/3.2.2/units/x86_64-linux/rtl/abitag.o
  6. ...
  7. )
  8. INPUT(
  9. -ldl
  10. )
  11. GROUP(
  12. -lc    // here link to libc.so
  13. )
  14.  

Here there is GROUP(-lc) that will link to libc.so.

Is it possible to avoid this?
« Last Edit: August 12, 2022, 12:51:49 am by Fred vS »
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Call to libc.so methods.
« Reply #8 on: August 12, 2022, 08:16:48 am »
No

Fred vS

  • Hero Member
  • *****
  • Posts: 3158
    • StrumPract is the musicians best friend
Re: Call to libc.so methods.
« Reply #9 on: August 12, 2022, 12:14:42 pm »
No

That is clear.

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:

Quote
Compiling fpmake.pp
fpmake.pp(16,3) Note: Local variable "T" is assigned but never used
Compiling ./rtl/mselibc.pas
mselibc.pas(3910,1) Fatal: Internal error 200501156
Fatal: Compilation aborted

Sure there is something to change in the Makefile of something else, but what?

Thanks.
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

Fred vS

  • Hero Member
  • *****
  • Posts: 3158
    • StrumPract is the musicians best friend
Re: Call to libc.so methods.
« Reply #10 on: August 12, 2022, 01:38:07 pm »
Last question, after this I let you in peace.

OK, I understand that, at the moment, fpc still needs libc.so for some rtl units.

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

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.
« Last Edit: August 12, 2022, 01:57:07 pm by Fred vS »
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Call to libc.so methods.
« Reply #11 on: August 12, 2022, 03:06:45 pm »
OK, I understand that, at the moment, fpc still needs libc.so for some rtl units.

dynlibs, cthreads, clocale being the main ones.

Quote
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) ?

If you can find a somewhat portable way to do so. In theory yes.

Quote
You know, surely, that a fpc application compiled on last Ubuntu or Debian distro does not run on last ArchLinux and Fedora distros.

But dynamically loading won't solve that. Linux simply doesn't try to have cross distro (and cross version) compatibility of binaries.


marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Call to libc.so methods.
« Reply #12 on: August 12, 2022, 03:07:55 pm »
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?

The system unit must be compiled with a special switch, and can't (easily) depend on other units; the rest is pretty straightforward.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Call to libc.so methods.
« Reply #13 on: August 12, 2022, 03:33:11 pm »
OK, I understand that, at the moment, fpc still needs libc.so for some rtl units.

The RTL units that require the C library, require the C library by design (namely units like cthreads, cwstrings or the whole RTL if FPC_USE_LIBC is defined).

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:

Code: Pascal  [Select][+][-]
  1. {$if defined(linux)}
  2.     { if libc is not linked explicitly, FPC might chose the wrong startup code, as
  3.       libdl depends on libc on linux, this does not hurt }
  4.     {$linklib c}
  5. {$endif}

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.

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

Fred vS

  • Hero Member
  • *****
  • Posts: 3158
    • StrumPract is the musicians best friend
Re: Call to libc.so methods.
« Reply #14 on: August 12, 2022, 03:33:42 pm »
OK, I understand that, at the moment, fpc still needs libc.so for some rtl units.
dynlibs, cthreads, clocale being the main ones.


Ha, perfect ( and I have already a version of dynlibs, cthreads, clocale full no-link-to-clib.so working  ;) )

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) ?
If you can find a somewhat portable way to do so. In theory yes.

Yep, nice new game, I will try.

You know, surely, that a fpc application compiled on last Ubuntu or Debian distro does not run on last ArchLinux and Fedora distros.
But dynamically loading won't solve that. Linux simply doesn't try to have cross distro (and cross version) compatibility of binaries.

Hum, I did try a demo app compiled using external libc and the same with loadlibrary(libc.so) and the one using "external" refuse to run in other distros and the one with loadlibrary() runs perfectly on all distros.  But of course for a personal application that you want to use on same system that you used to compile it it is not a problem.
( You know my obsession about OOTB (Out-Of-The-Box)  :-[)

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?
The system unit must be compiled with a special switch, and can't (easily) depend on other units; the rest is pretty straightforward.

Re-hum, many thanks for the info ( but more details would be welcome).

Thanks Marcov and have a perfect summer and all the rest.

Fre;D

I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

 

TinyPortal © 2005-2018