[openbeos] Re: getting serious about headers
- From: "Andrew Bachmann" <shatty@xxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Mon, 11 Aug 2003 02:40:13 -0700 PDT
On Sun, 10 Aug 2003 20:41:58 -0700 PDT "Andrew Bachmann" <shatty@xxxxxxxxxxxxx>
wrote:
> <snip>
> I don't quite understand how to read the spec with respect to a few
> things, namely: how to determine if a header can/should/must/can't/
> shouldn't/musn't include another header.
I think I've figured out at least one relevant piece of spec-speak. If
the spec says, (at it does), for example:
Inclusion of the <sys/resource.h> header may also make
visible all symbols from <sys/time.h>.
This means it's okay to #include <sys/time.h> in sys/resource.h
However, sometimes the spec says such things as: (for sys/time.h)
The time_t and suseconds_t types shall be defined
as described in <sys/types.h> .
And it doesn't say that all symbols from sys/types.h can be made
visible.
This could be interpreted in various ways:
(1) copy / paste the definitions from sys/types.h into sys/time.h
(2) put the definitions in another header that both sys/types.h and
sys/time.h include
(3) include sys/types.h from sys/time.h
or even
(4) include sys/time.h from sys/types.h
But I think #4 is wrong.
> Okay that sounds like less work to me. :-) (This is why I ask the list :-) )
>
> Here's a list so far. These are headers or functions that are looked for by
> the
> gcc 2.95.3 configuration procedure. I've roughly ordered them from most
> important to least, IMHO of course.
>
> sys/resource.h - getrlimit(), setrlimit(), posix, in kernel dir
Our resource.h is missing struct rusage and associated constants and
function. gcc assumes that since the header is there, those definitions
are there as well.
> string.h - ours has commented out strsignal() but gcc/Linux expects it in
> this header (not
> signal.h),
This caused a compile error in gcc. (easy fix)
Here's another annoying nuisance. When configuring against the
OBOS headers the autoconf program is sometimes not simply
satisfied to see the prototype. It attempts to compile a program
with actual usage of some of the prototypes. This fails for a few
things such as: getrlimit, setrlimit, setenv, unsetenv. This results
in gcc creating it's own definitions for some of those, sometimes
with incompatible prototypes. I suppose the solution is to also
link against openbeos libraries as well as the openbeos headers.
Although that won't help in the above cases since we haven't
defined those functions yet. :-)
What an educational exercise this has been. :-)
Andrew
Other related posts:
