Prev: sending/handling INT signal in child processes in bash
Next: Convert UTC seconds to actual time.
From: Vincenzo Mercuri on 6 Jul 2010 08:59
Hi All,

I am a bit confused about one thing:
at what degree a C compiler is indipendent from the
operating system it is running on? I mean, for example,
the time_t type is implemented in gcc or in glibc? gcc
compiler (but i may think about other compilers)
completely relies on glibc or it has its own
indipendent static libraries with different requirements
from Posix?


--
Vincenzo Mercuri

The more C dislikes me, the more I like it.
From: Ersek, Laszlo on 6 Jul 2010 09:55
On Tue, 6 Jul 2010, Vincenzo Mercuri wrote:

> I am a bit confused about one thing:
> at what degree a C compiler is indipendent from the
> operating system it is running on? I mean, for example,
> the time_t type is implemented in gcc or in glibc? gcc
> compiler (but i may think about other compilers)
> completely relies on glibc or it has its own
> indipendent static libraries with different requirements
> from Posix?

It shouldn't matter. The composition of all tools should provide you with
a standard environment. For example, you didn't decompose the "C compiler"
above into preprocessor, compiler, assembler, linker; and rightly so. If
your system claims conformance to whatever standard, it should document
how to set up a corresponding environment.

As an example, on Solaris, the standards(5) manual page documents how to
set up a SUSvX environment. It goes without saying that you have to use
the platform compiler (SUN C, ahem, Oracle C, I guess), because that is
what was certified in combination with the other parts of the system. For
example, "getconf" returns options for the platform compiler, not gcc.

On GNU/Linux, you're mostly screwed, I guess. It should be easily done on
any distro, but each has its own undocumented, different way. Of course,
GNU/Linux distros are not certified.

On Debian, I had to install GNU time and dash, and report a bug and write
a workaround for GNU getconf (-> glibc), to get what I needed.

You need the entire software stack to cooperate. See the getpid()/gettid()
example in the other thread.

lacos
From: Vincenzo Mercuri on 6 Jul 2010 13:10
Ersek, Laszlo ha scritto:
> On Tue, 6 Jul 2010, Vincenzo Mercuri wrote:
>
>> I am a bit confused about one thing:
>> at what degree a C compiler is indipendent from the
>> operating system it is running on? I mean, for example,
>> the time_t type is implemented in gcc or in glibc? gcc
>> compiler (but i may think about other compilers)
>> completely relies on glibc or it has its own
>> indipendent static libraries with different requirements
>> from Posix?
>
> It shouldn't matter. The composition of all tools should provide you
> with a standard environment. For example, you didn't decompose the "C
> compiler" above into preprocessor, compiler, assembler, linker; and
> rightly so. If your system claims conformance to whatever standard, it
> should document how to set up a corresponding environment.
>
> As an example, on Solaris, the standards(5) manual page documents how to
> set up a SUSvX environment. It goes without saying that you have to use
> the platform compiler (SUN C, ahem, Oracle C, I guess), because that is
> what was certified in combination with the other parts of the system.
> For example, "getconf" returns options for the platform compiler, not gcc.
>
> On GNU/Linux, you're mostly screwed, I guess. It should be easily done
> on any distro, but each has its own undocumented, different way. Of
> course, GNU/Linux distros are not certified.
>
> On Debian, I had to install GNU time and dash, and report a bug and
> write a workaround for GNU getconf (-> glibc), to get what I needed.
>
> You need the entire software stack to cooperate. See the
> getpid()/gettid() example in the other thread.
>

Thank you Ersek.
What you mean when you say 'GNU/Linux distros are not certified'?
In the sense that they are not required to provide you with
a complete standard environment?


--
Vincenzo Mercuri

The more C dislikes me, the more I like it.
From: Nicolas George on 6 Jul 2010 14:02
Vincenzo Mercuri wrote in message
<isJYn.207178$813.32454(a)tornado.fastwebnet.it>:
> What you mean when you say 'GNU/Linux distros are not certified'?

He means that that Linux distros did not pay big bucks to the owners of the
Unix trademark to get a piece of paper saying they abide to the standard,
although they abide to the standard often better than some commercial OS.
From: Rainer Weikusat on 6 Jul 2010 15:35
Vincenzo Mercuri <vincenzo.mercuri(a)gmail.com> writes:
> I am a bit confused about one thing:
> at what degree a C compiler is indipendent from the
> operating system it is running on? I mean, for example,
> the time_t type is implemented in gcc or in glibc? gcc
> compiler (but i may think about other compilers)
> completely relies on glibc or it has its own
> indipendent static libraries with different requirements
> from Posix?

The C-standard defines two kinds of 'conforming implementation':
'Hosted' and 'freestanding': 'Hosted' is supposed to mean 'part of a
complete operating system which is at least expected to provide full
support for standard C' and 'freestanding' something like a
compilation environment for some kind of microcontroller which doesn't
run a general purpose operating system (or maybe not even any
operating system). Details are in 4|6 of ISO/IEC 9899:1999 (E) and in
chapter 2 of the gcc manual (at least in version 4.3.2). According to
this text,

GCC aims towards being usable as a conforming freestanding
implementation, or as the compiler for a conforming hosted
implementation.

UNIX(*) is supposed to be (or to at least provide) a proper superset
of a 'conforming hosted C-implementation'. The example you gave was
'time_t': The facilities made available by including time.h are
defined in section 7.23.1 of the C-standard, but time.h is not in the
list of headers a conforming freestanding implementation shall
provide. For a usual Linux-based system, this means that time_t is
defined by glibc and not gcc.
 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: sending/handling INT signal in child processes in bash
Next: Convert UTC seconds to actual time.