Message ID | 4D4135AB.9080901@ubuntu.com |
---|---|
State | New |
Headers | show |
patch ping On 27.01.2011 10:06, Matthias Klose wrote: > Building a native powerpc-linux-gnu compiler for --enable-targets=all, I see in > nearly every file a warning that LINK_EH_SPEC is redefined. > > gcc -c -DIN_GCC_FRONTEND -g -fkeep-inline-functions -DIN_GCC -W -Wall > -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros > -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common > -DHAVE_CONFIG_H -I. -Icp -I../../src/gcc -I../../src/gcc/cp > -I../../src/gcc/../include -I../../src/gcc/../libcpp/include > -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd > -I../libdecnumber ../../src/gcc/cp/rtti.c -o cp/rtti.o > In file included from ./tm.h:34, > from ../../src/gcc/cp/rtti.c:27: > ../../src/gcc/config/rs6000/sysv4.h:839:1: warning: "LINK_EH_SPEC" redefined > In file included from ./tm.h:33, > from ../../src/gcc/cp/rtti.c:27: > ../../src/gcc/config/freebsd-spec.h:135:1: warning: this is the location of the > previous definition > > Undefining it before the definition as done with other macros avoids the warning. > > Matthias > > complete build log > https://buildd.debian.org/fetch.cgi?pkg=gcc-snapshot&arch=powerpc&ver=20110126-1&stamp=1296088494&file=log&as=raw > > > * config/rs6000/sysv4.h (LINK_EH_SPEC): Undefine before definition. > > Index: config/rs6000/sysv4.h > =================================================================== > --- config/rs6000/sysv4.h (revision 169303) > +++ config/rs6000/sysv4.h (working copy) > @@ -835,6 +835,7 @@ > -dynamic-linker " LINUX_DYNAMIC_LINKER "}}" > > #if defined(HAVE_LD_EH_FRAME_HDR) > +# undef LINK_EH_SPEC > # define LINK_EH_SPEC "%{!static:--eh-frame-hdr} " > #endif >
On Wed, Feb 16, 2011 at 11:36:09PM +0100, Matthias Klose wrote: > >../../src/gcc/config/rs6000/sysv4.h:839:1: warning: "LINK_EH_SPEC" redefined > >In file included from ./tm.h:33, > >from ../../src/gcc/cp/rtti.c:27: > >../../src/gcc/config/freebsd-spec.h:135:1: warning: this is the location of the > >previous definition In mainline sources the two macro definitions are identical. Self- inflicted wound?
On Fri, Mar 04, 2011 at 05:30:10PM +1030, Alan Modra wrote: > On Wed, Feb 16, 2011 at 11:36:09PM +0100, Matthias Klose wrote: > > >../../src/gcc/config/rs6000/sysv4.h:839:1: warning: "LINK_EH_SPEC" redefined > > >In file included from ./tm.h:33, > > >from ../../src/gcc/cp/rtti.c:27: > > >../../src/gcc/config/freebsd-spec.h:135:1: warning: this is the location of the > > >previous definition > > In mainline sources the two macro definitions are identical. Self- > inflicted wound? We see it because we add --no-add-needed to linux LINK_EH_SPECs. Including freebsd-spec.h in a Linux configuration is certainly very questionable and undefining LINK_EH_SPEC and other macros before defining them would be certainly cleaner if the freebsd-spec.h include can't be just killed. Jakub
On Fri, Mar 04, 2011 at 08:38:18AM +0100, Jakub Jelinek wrote: > We see it because we add --no-add-needed to linux LINK_EH_SPECs. OK. Adding the #undef is then required.. > Including freebsd-spec.h in a Linux configuration is certainly very > questionable and undefining LINK_EH_SPEC and other macros before defining > them would be certainly cleaner if the freebsd-spec.h include can't be just > killed. It's there for -mcall-freebsd. Take that away and you won't need freebsd-spec.h in powerpc-linux configs.
On Fri, Mar 04, 2011 at 10:13:02PM +1030, Alan Modra wrote: > > Including freebsd-spec.h in a Linux configuration is certainly very > > questionable and undefining LINK_EH_SPEC and other macros before defining > > them would be certainly cleaner if the freebsd-spec.h include can't be just > > killed. > > It's there for -mcall-freebsd. Take that away and you won't need > freebsd-spec.h in powerpc-linux configs. If it is needed on non-FreeBSD targets (why would anyone want to use -mcall-freebsd on Linux instead of building a Linux->FreeBSD cross?), then freebsd-spec.h should presumably only define FBSD_*/USING_CONFIG_FREEBSD_SPEC macros and nothing else, the rest should go into config/freebsd.h or something that is not included by all other targets. Jakub
On Fri, 4 Mar 2011, Alan Modra wrote: > On Fri, Mar 04, 2011 at 08:38:18AM +0100, Jakub Jelinek wrote: > > We see it because we add --no-add-needed to linux LINK_EH_SPECs. > > OK. Adding the #undef is then required.. > > > Including freebsd-spec.h in a Linux configuration is certainly very > > questionable and undefining LINK_EH_SPEC and other macros before defining > > them would be certainly cleaner if the freebsd-spec.h include can't be just > > killed. > > It's there for -mcall-freebsd. Take that away and you won't need > freebsd-spec.h in powerpc-linux configs. I'd certainly like to see the -mcall-* code that pretends to support linking for one target using another target's compiler removed. That way non-FreeBSD targets wouldn't need freebsd-spec.h, rs6000/sysv4.h wouldn't need loads of specs that are really irrelevant to all but one target, and you could probably make powerpc*-linux* use the toplevel gnu-user.h and linux.h like almost all other Linux kernel targets. That these powerpc* targets are doing things differently from all other architectures is a nuisance when making changes across all targets (and I don't think what they are doing is a useful intermediate step towards a multi-target compiler).
On Fri, Mar 04, 2011 at 03:50:48PM +0000, Joseph S. Myers wrote: > I'd certainly like to see the -mcall-* code that pretends to support > linking for one target using another target's compiler removed. That way > non-FreeBSD targets wouldn't need freebsd-spec.h, rs6000/sysv4.h wouldn't > need loads of specs that are really irrelevant to all but one target, and > you could probably make powerpc*-linux* use the toplevel gnu-user.h and > linux.h like almost all other Linux kernel targets. That these powerpc* > targets are doing things differently from all other architectures is a > nuisance when making changes across all targets (and I don't think what > they are doing is a useful intermediate step towards a multi-target > compiler). I agree. The only -mcall option I've ever used is -mcall-aixdesc to generate the old dot-symbol function descriptors on powerpc64-linux. The eabi/noeabi options might also be useful, but I don't see the point of the ones that pretend to generate code for another OS.
Index: config/rs6000/sysv4.h =================================================================== --- config/rs6000/sysv4.h (revision 169303) +++ config/rs6000/sysv4.h (working copy) @@ -835,6 +835,7 @@ -dynamic-linker " LINUX_DYNAMIC_LINKER "}}" #if defined(HAVE_LD_EH_FRAME_HDR) +# undef LINK_EH_SPEC # define LINK_EH_SPEC "%{!static:--eh-frame-hdr} " #endif