[Bug 508] sys/cdefs.h conflicts again
bugzilla-daemon at rtems.org
bugzilla-daemon at rtems.org
Tue Aug 19 20:24:31 UTC 2008
http://www.rtems.org/bugzilla/show_bug.cgi?id=508
Joel Sherrill <joel.sherrill at oarcorp.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |WAITING
Status|WAITING |CLOSED
Status|CLOSED |WAITING
Status|ASSIGNED |RESOLVED
Platform| |All
Resolution| |FIXED
Target Milestone|--- |4.9
Both Newlib and RTEMS ship sys/cdefs.h.
Both seem to be derived from the same origin,
both to a large extend seem to be functionally equvivalent,
but are not identical.
This causes installation conflicts between RTEMS and gcc/newlib when using binary distributions (eg. rpms) and when merging RTEMS's cpukit into gcc's system headers (Installing into $prefix/<target>/include instead of $prefix/<target>/lib/include)
For testing, I changed RTEMS to using the cdefs.h from newlib.
Result:
Entering directory `/users/rtems/src/rtems-cvs/build/sparc/sparc-rtems4.7/soft/cpukit/libnetworking'
mkdir o-optimize
sparc-rtems4.7-gcc --pipe -msoft-float --pipe -DHAVE_CONFIG_H -isystem ../../../include -D_COMPILING_BSD_KERNEL_ -DKERNEL -DINET -DNFS -DDIAGNOSTIC -DBOOTP_COMPAT
-g -O2 -msoft-float -o o-optimize/kern_mib.o -c ../../../../../../rtems.master/cpukit/libnetworking/kern/kern_mib.c
In file included from ../../../../../../rtems.master/cpukit/libnetworking/kern/kern_mib.c:49:
../../../include/sys/systm.h:91: error: parse error before "__dead2"
../../../include/sys/systm.h:92: error: parse error before "__dead2"
../../../../../../rtems.master/cpukit/libnetworking/kern/kern_mib.c:67: error: parse error before "__unused"
../../../../../../rtems.master/cpukit/libnetworking/kern/kern_mib.c:69: error: parse error before "__unused"
../../../../../../rtems.master/cpukit/libnetworking/kern/kern_mib.c:77: error: parse error before "__unused"
../../../../../../rtems.master/cpukit/libnetworking/kern/kern_mib.c:103: error: parse error before "__unused"
Release:
RTEMS-CVS
--- Comment #1 from Ralf Corsepius <ralf.corsepius at rtems.org> 2003-10-02 11:52:00 ---
Fix:
Several approaches:
1. Rely on the toolchain shipping sys/cdefs.h and remove sys/cdefs.h from RTEMS.
2. Don't use sys/cdefs.h in general at all, because
sys/cdefs.h is a BSD-ism aiming at KnR->C89 portability and should not be necessary by modern code and toolchains.
3. Ship RTEMS sys/cdefs.h as an RTEMS private header, to be used inside of C-files only and don't install this sys/cdefs.h nor use it in public headers.
4. Use RTEMS current sys/cdefs.h as rtems/cdefs.h (as an RTEMS proprietary public header) or similar and don't use sys/cdefs.h inside of RTEMS at all.
I am leaning towards 1+2, i.e. require the target toolchain to have sys/cdefs.h and avoid using sys/cdefs.h whenever possible.
--- Comment #2 from Joel Sherrill <joel.sherrill at oarcorp.com> 2003-10-22 11:37:03 ---
State-Changed-From-To: open->feedback
State-Changed-Why: I approve your idea of transitioning to the bsd/cdefs.h. We
need something to continue moving forward.
--- Comment #3 from Joel Sherrill <joel.sherrill at oarcorp.com> 2006-03-07 16:18:20 ---
State-Changed-From-To: feedback->closed
State-Changed-Why: If this hasn't been finished by now, the nature of the
problem has changed enough to make this irrelevant.
--- Comment #4 from Ralf Corsepius <ralf.corsepius at rtems.org> 2006-03-08 03:59:27 ---
From: Ralf Corsepius <ralf.corsepius at rtems.org>
To: bugs at rtems.com
Cc: ralf_corsepius at rtems.com, mayes at oarcorp.com, vvv at oktetlabs.ru, norume at aps.anl.gov, chrisj at rtems.com, ralf_corsepius at rtems.org, jennifer at oarcorp.com, jmj at oarcorp.com, joel at oarcorp.com
Subject: Re: RTEMS Re: tools/508
Date: Wed, 08 Mar 2006 03:59:27 +0100
On Tue, 2006-03-07 at 22:18 +0000, RTEMS-gnats at rtems.com wrote:
> Synopsis: sys/cdefs.h conflicts again
>
> State-Changed-From-To: feedback->closed
> State-Changed-By: joel
> State-Changed-When: Tue, 07 Mar 2006 16:18:20 -0600
> State-Changed-Why:
> If this hasn't been finished by now, the nature of the
> problem has changed enough to make this irrelevant.
I am not sure if I can agree to that. Though this particular PR probably
is irrelevant in the sense of "probably doesn't have visible impacts
ATM", it is one of the issues I reiterate as "RTEMS/BSD" clashes and
blocker for rtems4.7 - I.e. as unresolved.
> http://www.rtems.com/cgi-bin/gnatsweb.pl?cmd=view&database=RTEMS&pr=508
--- Comment #5 from Joel Sherrill <joel.sherrill at oarcorp.com> 2006-03-08 10:03:56 ---
State-Changed-From-To: closed->feedback
State-Changed-Why: Based upon Ralf's comments, let's reopen this one.
--- Comment #6 from Joel Sherrill <joel.sherrill at oarcorp.com> 2008-08-19 15:24:30 ---
Patch committed where needed.
--
Configure bugmail: http://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the bugs
mailing list