Prev: sending/handling INT signal in child processes in bash
Next: Convert UTC seconds to actual time.
From: Ersek, Laszlo on 6 Jul 2010 17:32
On Tue, 6 Jul 2010, Nicolas George wrote:

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

.... I rather meant I don't know of a well-documented (or even, directly
supported) way to set up a SUSvX environment on a GNU/Linux distro, even
though they tend to implement those standards very well.

Why the hostility towards The Open Group? The standards are open; some
freely licensed OS distributions are allowed to redistribute them; the
development process is open (you can submit bugs and participate in the
discussions).

I love GNU/Linux distros as much as the next guy, but lack of
documentation (or my failure to find it...) not only meant that I had to
"research" a sufficient setup, the setup then drew stares, even for a
fringe project like what I've released. (Not that I'd have any grounds to
complain; I didn't pay the distro developers to work on stuff I deem
important.)

Case in point: getconf and LFS support (see the mmap64() thread in
comp.os.linux.development.*). If you look up getconf and c89/c99 in
SUSv[2-4], and then experiment with a moderately recent GNU/Linux distro,
you'll find that at least SUSv[23] support is there. On Debian Lenny (=
stable), "man getconf" says nothing about those operands. "info libc" does
neither. Then you resort to autoconf, nonstandard LFS_* system_var
operands and so on, even though GNU/Linux would work perfectly with the
standard operands. (I felt the urge to parrot the SUS getconf links in the
mmap64() thread, but then I just gave up. It's futile.)

Suppose you did read the relevant pages in the SUS, found that GNU/Linux
distros do support those getconf operands, and finally utilized those
operands in your build script. Then you can explain them to others a
thousand times, because they never saw them in the distro docs.

lacos
From: Vincenzo Mercuri on 6 Jul 2010 23:48
Ersek, Laszlo ha scritto:
> On Tue, 6 Jul 2010, Nicolas George wrote:
>
>> 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.
>
> ... I rather meant I don't know of a well-documented (or even, directly
> supported) way to set up a SUSvX environment on a GNU/Linux distro, even
> though they tend to implement those standards very well.
>
> Why the hostility towards The Open Group? The standards are open; some
> freely licensed OS distributions are allowed to redistribute them; the
> development process is open (you can submit bugs and participate in the
> discussions).
>
> I love GNU/Linux distros as much as the next guy, but lack of
> documentation (or my failure to find it...) not only meant that I had to
> "research" a sufficient setup, the setup then drew stares, even for a
> fringe project like what I've released. (Not that I'd have any grounds
> to complain; I didn't pay the distro developers to work on stuff I deem
> important.)
>
> Case in point: getconf and LFS support (see the mmap64() thread in
> comp.os.linux.development.*). If you look up getconf and c89/c99 in
> SUSv[2-4], and then experiment with a moderately recent GNU/Linux
> distro, you'll find that at least SUSv[23] support is there. On Debian
> Lenny (= stable), "man getconf" says nothing about those operands. "info
> libc" does neither. Then you resort to autoconf, nonstandard LFS_*
> system_var operands and so on, even though GNU/Linux would work
> perfectly with the standard operands. (I felt the urge to parrot the SUS
> getconf links in the mmap64() thread, but then I just gave up. It's
> futile.)
>
> Suppose you did read the relevant pages in the SUS, found that GNU/Linux
> distros do support those getconf operands, and finally utilized those
> operands in your build script. Then you can explain them to others a
> thousand times, because they never saw them in the distro docs.
>
> lacos

Thank you, a final question:
if I wanted to write fully POSIX compliant code,
in a fully documented environment, which one
of the freely available OS would you advise me?
Would the BSD family suit my needs? (or Open Solaris?)



--
Vincenzo Mercuri


From: Vincenzo Mercuri on 7 Jul 2010 00:04
Rainer Weikusat ha scritto:
> 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.


Thank you.

Is there an option or some way to see what libraries
i am effectively linking my code against? (Some sort of
log of what the linker is doing 'under the wood'?)

And a way to force gcc to use its own libraries
as long as I want to use the gcc 'freestanding subset'
of the C Standard? (or it links its own 'subset' by default?)



--
Vincenzo Mercuri


From: Ian Collins on 7 Jul 2010 00:15
On 07/ 7/10 03:48 PM, Vincenzo Mercuri wrote:
>
> Thank you, a final question:
> if I wanted to write fully POSIX compliant code,
> in a fully documented environment, which one
> of the freely available OS would you advise me?
> Would the BSD family suit my needs? (or Open Solaris?)

I can't speak for the BSDs, but I have found it easier to develop
portable code on (Open)Solaris and port to Linux than vice-versa. For
starters, the documentation is very clear as to what is and what isn't
standard.

--
Ian Collins
From: Vincenzo Mercuri on 7 Jul 2010 00:46
Ian Collins ha scritto:
> On 07/ 7/10 03:48 PM, Vincenzo Mercuri wrote:
>>
>> Thank you, a final question:
>> if I wanted to write fully POSIX compliant code,
>> in a fully documented environment, which one
>> of the freely available OS would you advise me?
>> Would the BSD family suit my needs? (or Open Solaris?)
>
> I can't speak for the BSDs, but I have found it easier to develop
> portable code on (Open)Solaris and port to Linux than vice-versa. For
> starters, the documentation is very clear as to what is and what isn't
> standard.
>


Great, Thank you Ian

--
Vincenzo Mercuri


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