language, clarity
← Older revision
Revision as of 08:59, 23 July 2014
(One intermediate revision by one user not shown)
Line 1:
Line 1:
+
== libc deprecated ==
The libc unit (not to be confused with the libc library (.so)) is a header to the libc library created for Kylix.
The libc unit (not to be confused with the libc library (.so)) is a header to the libc library created for Kylix.
−
<h2>FAQ:
The libc ''unit'' is deprecated, and frozen in time for Kylix compatibility, and won't be ported to other architectures or operating systems.
</h2>
+
The libc ''unit'' is deprecated, and frozen in time for Kylix compatibility, and won't be ported to other architectures or operating systems.
−
== The problem with unit libc ==
+
=
== The problem with unit libc
=
==
−
There is a lot of confusion about why unit libc has been deprecated
. With this faq I hope to end this discussion. There is a lot of confusion
because FPC has different policies on '''library libc''' and '''unit libc'''. An often heard argument is that (library) libc use is strictly forbidden, which is
simply not related
to the problem of the libc unit.
+
There is a lot of confusion about why unit libc has been deprecated
,
because FPC has different policies on '''library libc''' and '''unit libc'''. An often heard argument is that (library) libc use is strictly forbidden, which is
totally unrelated
to the problem of the libc unit.
−
The '''libc library''' policy is way simpler and unrelated: the core bootstrap and the base RTL( system, sysutils, baseunix) are kept free from libc for bootstrapping and long term compatibility reasons. Functionality that needs the '''libc library''' is plugged in by extra units that only need to be included once
.
(using units like cthreads, clocale, cmem, cwstrings).
This policy is from a pragmatic viewpoint, and not set in stone forever. (e.g., the Mac OS X port does not to follow it, because on that platform system calls can change even between minor revisions, while backwards compatibility of libc is guaranteed as much as possible by Apple -- in essence, libc is ''the'' system interface on Mac OS X as far as user level applications are concerned)
+
The '''libc library''' policy is way simpler and unrelated: the core bootstrap and the base RTL( system, sysutils, baseunix) are kept free from libc for bootstrapping and long term compatibility reasons. Functionality that needs the '''libc library''' is plugged in by extra units that only need to be included once (using units like cthreads, clocale, cmem, cwstrings).
−
The '''''actual problem''''' with the '''UNIT libc''' is that Borland followed the same model with Kylix as they did on Windows. While
doing
Kylix, they simply stuffed anything platform dependent they could find into unit libc without any discrimination. This
resulted
the unit
being
stuffed from top to bottom with types, consts and calls from various origins, and with various portability concerns:
+
This policy is from a pragmatic viewpoint, and not set in stone forever. An example: the Mac OS X port does not follow it, because on that platform system calls can change even between minor revisions, while backwards compatibility of libc is guaranteed as much as possible by Apple. In essence, libc is ''the'' system interface on Mac OS X as far as user level applications are concerned.
+
+
The '''''actual problem''''' with the '''UNIT libc''' is that Borland followed the same model with Kylix as they did on Windows. While
writing
Kylix, they simply stuffed anything platform dependent they could find into unit libc without any discrimination. This
caused
the unit
to be
stuffed from top to bottom with types, consts and calls from various origins, and with various portability concerns:
* linuxisms ( symbols/behaviour that only exist on Linux)
* linuxisms ( symbols/behaviour that only exist on Linux)
* glibcisms ( symbols/behaviour that only exists with glibc, but not e.g. with uclibc)
* glibcisms ( symbols/behaviour that only exists with glibc, but not e.g. with uclibc)
−
*
Libraries
that are in fact external, but linked into the glibc library on stock linux (but not part of the actual glibc distribution).
Here I mean
stuff like iconv.
+
*
libraries
that are in fact external, but linked into the glibc library on stock linux (but not part of the actual glibc distribution).
This means
stuff like iconv.
* kernel version dependent symbols
* kernel version dependent symbols
* x86 specific issues
* x86 specific issues
* other system libraries like libdl.
* other system libraries like libdl.
−
*
All
records and structures are visible without any discrimination, even if they are kernel version dependent. No attempt was made to clean up, limit visibility or even just mark internal fields.
+
*
all
records and structures are visible without any discrimination, even if they are kernel version dependent. No attempt was made to clean up, limit visibility or even just mark internal fields.
−
* Linux specific temporary ( migratory ) constructs like -32 and -64 versions of calls. (There is an
arch
dependent aspect too, because such constructs are often x86 specific because that architecture has the largest legacy)
+
* Linux specific temporary (migratory) constructs like -32 and -64 versions of calls. (There is an
architecture
dependent aspect too, because such constructs are often x86 specific because that architecture has the largest legacy)
−
Note that this clearly makes this more than a "Linux vs the rest" situation. Other architectures (64-bit)
,
embedded uclibc
and
long term compatibility
(
what if libc no longer exports fstat64 because the grace period is over and off_t is always 64-bit? Migration of time_t to 64-bit
, etc) are things that a lot of Linux developers will have to face sooner or later too
.
+
Note that this clearly makes this more than a "Linux vs the rest" situation.
+
A lot of Linux developers will sooner or later have to face have to face the following, too:
+
*
Other architectures (64-bit)
+
*
embedded uclibc
+
*
long term compatibility
:
what if libc no longer exports fstat64 because the grace period is over and off_t is always 64-bit? Migration of time_t to 64-bit
..
.
−
For Borland this never was a problem, only the last version is supported and reasonably up to date, and they expected you to upgrade once in a while. At least if Kylix hadn't been
iced
.
+
For Borland this never was a problem, only the last version is supported and reasonably up to date, and they expected you to upgrade once in a while. At least if Kylix hadn't been
killed
.
−
== So what to replace it with? ==
+
=
== So what to replace it with?
=
==
That's not easily answered, since that is the exact problem with unit libc. It is a mix of stuff with a lot of different tradeoffs. Below are some options in decreasing preference.
That's not easily answered, since that is the exact problem with unit libc. It is a mix of stuff with a lot of different tradeoffs. Below are some options in decreasing preference.
Line 43:
Line 50:
A quick question on the FPC IRC channel might get you updated as to the current status.
A quick question on the FPC IRC channel might get you updated as to the current status.
−
== But I only want.... ==
+
=
== But I only want....
=
==
If we first commit raw Linux/x86 headers (and thus often Linux/x86-glibc specific ones), and only then start worrying about portability, we may as well fork the RTL for each *nix target immediately, and forget about even attempting cross-unix portability. Moreover this often introduces a bad published interface that might become a compatibility hazard to maintain when later crossplatform versions become available.
If we first commit raw Linux/x86 headers (and thus often Linux/x86-glibc specific ones), and only then start worrying about portability, we may as well fork the RTL for each *nix target immediately, and forget about even attempting cross-unix portability. Moreover this often introduces a bad published interface that might become a compatibility hazard to maintain when later crossplatform versions become available.
Line 65:
Line 72:
== Resources ==
== Resources ==
−
Nobody expects that you prepare
such
a perfect unit at once, and without help. Here are some sources that can give assistance:
+
Nobody expects that you prepare a perfect
new
unit at once, and without help. Here are some sources that can give assistance:
* the fpc-devel maillist
* the fpc-devel maillist
* the fpc-pascal maillist
* the fpc-pascal maillist
Line 74:
Line 81:
[[Category:Units]]
[[Category:Units]]
+
[[Category:FPC]]
+
[[Category:Linux]]