Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc)

This is less of an issue with math functions, *printf, and the
string library and such since they usually don't have much of an
interface with the kernel in areas where changes occur.


Exactly, and those functions should be provided by the compiler,
not the OS.

Well, if the functions are provided by the compiler *AND* the OS,
you've got potential problems, which the C standard covers by saying
that trying to redefine library routines leads to undefined behavior.
If the functions are provided by the compiler *AND NOT* the OS,
then what do the OS-supplied programs use to call the kernel? Are
they all written in Perl? Most of these problems are related to
how the *OS* libc is laid out. If it's available as one monolithic
chunk, all-or-nothing, then there's a good chance what you can
replace is everything or nothing, with no options for anything in
between.

However, it's a problem trying to replace *PART* of libc.
Things also tend to go very badly if you try to link to multiple
versions of the same library.


This is absolutely no problem if the linker links to a compiler
version of the libc that THEN calls the OS libc if necessary.

This is true if you are simply adding missing routines that the
OS libc does not supply that can be written in Standard C.
Unfortunately, things like printf conversions don't qualify, and
they are also common C99 deficiencies in an old OS libc.

There can be problems trying to replace printf(). The compiler
libc defines its own printf(), which calls some of the stdio routines,
which call malloc(), which is in the OS libc. (If you also replace
malloc(), then you have to interface to sbrk() or mmap(), or whatever
malloc() uses to get memory from the OS.) The OS libc also includes
its own (ancient) version of printf() which doesn't support a lot
of the new C99 conversions. Now you've got two printf()s in the
same program. This is not guaranteed to work. It's not guaranteed
to break, either, but it's possible to have it fail, for example,
with duplicate symbol errors on printf(). I've worked with a real
system where this was an issue. Getting around it by carefully
crafting the *compiler* libc only didn't work.


there are going to be instances where one can get away with using the
native OS libc, but clearly there are lots of other cases where it
doesn't work out so well. And I would wager it works out less and
less well as the target OS ages.

I can see problems where the OS (and its version of libc) is young
enough to be under active development.


Bogus, since the libc interfaces didn't change since C89 in most
cases.

Prove to me by quoting the C standard that the size of an fpos_t
did not change from 32 to 64 bits on a particular implementation
from one version to the next. (Yet I think all OSs over the last
30 years had to deal with a 32-bit max file size being insufficient:
Windows, Linux, UNIX of all variations, etc. Not sure about VMS.)
Prove to me by quoting the C standard that sizeof(FILE) does not
change on a particular implementation from one version to the next.
Prove to me by quoting the C standard that a time_t did not change
from 32 to 64 or 256 bits on a particular implementation from one
version to the next.

The libc interface *TO THE KERNEL* is not specified in C89, and on
a particular implementation, you don't know whether it changed or
not without close examination. (On x86, the instruction to transition
to kernel mode might be an "int" instruction, or a call to a trap
gate, or something else. If you put that instruction, whatever it
is, in the compiler libc, be prepared to have to change it. Someone
will find a code sequence that takes a few machine cycles less for
a system call. I believe over the history of FreeBSD, that instruction
and the linkage between libc and the kernel has changed. It's
nicely transparent if nobody is copying parts of that code into the
compiler libc.)

You could get away with this if the routines you are replacing use
only C-documented interfaces to libc. Or POSIX-documented interfaces,
which are also unlikely to change much. You can't: it's not
guaranteed that there isn't any unwarranted chuminess between
routines that you are replacing and routines you are NOT replacing,
such as printf and stdio, or stdio and malloc/free, or malloc and
sbrk. The layout of things like FILE also isn't guaranteed to be
unchangeable, either (and I believe over the history of FreeBSD,
it has changed in an incompatible way, incompatible if you insist
on linking with an old (compiler) libc on a system with a new kernel.
But old executables worked (the old way), and newly-linked code
worked (the new way)). The same sort of changes were used in
enlarging off_t.

There isn't a nice, clean break where you could replace one piece
and not another. You might get away with it replacing all the trig
functions, but when you need to start replacing printf(), trouble
starts.


.

Relevant Pages

  • Re: large files: when ubiquitous?
    ... >>tries to store the return value in a 32bit integer, you get warnings. ... Actually I would like the compiler to produce ... libc define an interface in the headers. ... > The interface between libc and the kernel is different. ...
    (comp.os.linux.development.system)
  • Re: How to make a completely static app
    ... SC> Perhaps this is more an example of the bloat of libc than it is an example ... SC> gritty required to interface with kernel services. ... runtime support for languages other than C, ...
    (comp.unix.programmer)
  • Re: Which compiler to create small windows exes ??
    ... Please suggest me a better compiler to do it. ... Windows and Linux there are ways to address the kernel directly, ... 100's of kB for the EXE range... ... (rather than an interface into the kernel...). ...
    (comp.compression)
  • Re: Which compiler to create small windows exes ??
    ... Please suggest me a better compiler to do it. ... use C or ASM, and avoid and C runtime calls. ... Windows and Linux there are ways to address the kernel directly, ... presumably with a similar interface ...
    (comp.compression)
  • Re: pros/cons of installing from source
    ... Biggest contenders for optimisation are the kernel and libc. ... Debian supply both optimised kernels and to a lesser degree optimised libc packages. ... Use of SIMD extensions etc is something totally different, and compiler flags aren't going to do all that much there really... ...
    (Debian-User)