[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Rtems 18.104.22.168 - cdefs.h
- Date: Fri, 05 May 2006 00:26:51 +1100
- From: sjohnson at sakuraindustries.com (Steven Johnson)
- Subject: Rtems 22.214.171.124 - cdefs.h
So to summarize, the best approach wold be to:
1. Rename all references in rtems from sys/defs.h to rtems/cdefs.h
2. Remove sys/cdefs.h from the rtems source tree.
Is it proposed to not install "rtems/cdefs.h" in the install phase of
building rtems, because its only used internally?
The problem I have with not installing it, is there are installed
headers that would require rtems/cdefs.h, so i think installing it cant
be avoided, unless its features are not relied on by installed headers
at all. Is this right?
1 & 2 are largely mechanical, I could probably put a patch together to
do this in about an hour, and it would certainly get rid of the double
declaration i am experiencing. The question remains, should
"rtems/cdefs.h" be installed, and if not, how should headers that refer
to it, that are installed be dealt with.
Another (more work) option would be to remove all reference to
"sys/cdefs.h" and "rtems/cdefs.h" and just fix all the build errors that
introduces. It seems cdefs.h largely deals with making certain
attributes on functions/variables work with non ansi-C compatible
compilers, and also with early versions of GCC. Is this a concern of
126.96.36.199? If it was specified that it required an ansi-C compatible
compiler, then a lot of the definitions would become redundant and could
possibly be removed. Other support also seems to be for ancient
versions of GCC (< V2.5). Are these versions supported with 188.8.131.52?
Is any other compiler other than GCC really supported for building
RTEMS? If the answer to these is no, then I think it may not be a
hugely complicated task just to remove cdefs.h altogether, and just
change the code to build properly using GCC > V4 (if thats what is the
The rest of the declarations seem to come from the networking code:
rtems-184.108.40.206/cpukit/libnetworking/net/if.h: * FIXME - HACK: BSD
defines __BSD_VISIBLE in sys/cdefs.h
rtems-220.127.116.11/cpukit/libnetworking/net/if.h: * RTEMS sys/cdefs.h
doesn't, so we enforce it here.
Would changing those references to rtems/cdefs.h create a problem for
inserting newer versions of the BSD network stack into rtems. Or isnt
this a consideration?
Im happy to do the work needed to resolve this, because these 2 references:
Causes me problems, due to things being declared twice. If nothing
else, 1 of these #include's needs to be removed. If that all that is
done, which one should it be? <sys/cdefs.h> ?
Ralf Corsepius wrote:
>On Wed, 2006-05-03 at 16:53 -0500, Joel Sherrill wrote:
>>Steven Johnson wrote:
>>>Further to the following email,
>>>it turns out that the only header file installed by rtems that refers to
>>>cdefs.h is rtems_bsdnet_internal.h
>>>It #include's both 'rtems/cdefs.h' and 'sys/cdefs.h'
>>It has been a long time goal to slowly eliminate the various versions of
>>at least turn them into a .h file used only at build time.
>>>I cant see any definitions in rtems/cdefs.h that arent made in
>>>sys/cdefs.h. Shouldn't the #include to 'rtems/cdefs.h' be changed to
>>>'sys/cdefs.h' and then the second (and lower) #include of 'sys/cdefs.h'
>>>If this is done, i don't find any other references to 'rtems/cdefs.h',
>>>so couldn't it be safely removed?
>Nope. The problem is much more complicated than it looks.
>1. cdefs.h is not covered by any standard. It is a
>de-facto/implementation-defined pseudo-standard header being defined by
>the implementations to be found in various BSD-derivatives.
>For RTEMS, we use the implementation from FreeBSD as reference and try
>to minimize it.
>2. Unfortunately newlib has chosen to provide a (BSD-incompatible)
>cdefs.h of its own.
>=> There exist 2 conflicting, largely incompatible implementations of
>To resolve this issue there exist several different approaches:
>1. Eliminate all cdefs.h in RTEMS source tree and rely on an external
>libc providing sys/cdefs.h
>This approach is problematic twice:
>- BSD compatibility
>- sys/cdefs.h is not guaranteed to be provided by a libc.
>Newlib's sys/cdefs.h isn't much of a problem, because we can patch it
>for the amount of BSD compatibility required.
>2. Eliminate sys/cdefs.h from newlib.
>This is hardly possible, because
>- RTEMS hardly is in a position to introduce such a drastic measure to
>- sys/cdefs.h is used by newlib when bootstrapping it.
>3. Don't use sys/cdefs.h inside of the RTEMS source tree, but use a BSD
>compatible sys/cdefs.h replacement as private header inside of the
>>I tried to remove the sys/cdefs.h and rtems/cdefs.h from the RTEMS tree and
>>now know that the newlib sys/cdefs.h is NOT sufficient to build RTEMS.
>>It is missing at least definitions of _dead2.
>Exactly, BSD compatiblity hits.
>>I have not had a chance to see if the sys/cdefs.h in RTEMS can be eliminated
>>and keep rtems/cdefs.h. Having an RTEMS sys/cdefs.h and a newlib
>>is confusing. At least keeping rtems/cdefs.h would make it obvious it
>Right, what you currently see inside of the source tree probably is left
>overs from different and contradicting efforts to implement one of the
>Similar considerations apply other BSD headers (Definitely to
>sys/queue.h, I think there are more, but I don't recall off-head).
>>The long term goal is to eliminate RTEMS using cdefs.h as much as possible
>>until it is an internal file supporting ported BSD code.