Forum > General

Call to methods.

(1/5) > >>

Fred vS:

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

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?

That is a faq:

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.

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

Fred vS:
@ 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).

Fred vS:
For example, MSEgui has a very complete, working mselibc.pas, and each time that a unit needs to call a 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?


[0] Message Index

[#] Next page

Go to full version