* cross-builds failing
@ 1998-10-06 2:10 Richard Earnshaw
1998-10-06 22:02 ` Jeffrey A Law
1998-10-07 2:50 ` Manfred Hollstein
0 siblings, 2 replies; 10+ messages in thread
From: Richard Earnshaw @ 1998-10-06 2:10 UTC (permalink / raw)
To: egcs; +Cc: richard.earnshaw
I'm not sure why this has started (or exactly when -- sometime in the last
couple of weeks I think). I have a cross-build for the ARM set up, with a
gas and newlib tree linked into my source structure. In the past this has
always built fine (modulo a few small problems with the latest gas
snapshots putting intl in a different place).
Now, trying to build the compiler dies when trying to compile libgcc2.c:
for name in _muldi3 ...; \
do \
echo ${name}; \
/home/rearnsha/gnu/egcs/arm-aout/gcc/xgcc -B/home/rearnsha/gnu/egcs/arm-a
out/gcc/ -O2 -fomit-frame-pointer -DCROSS_COMPILE -DIN_GCC -DSVR4 -g
-O2 -I./include -I. -I../../../../gnusrc/egcs/gcc
-I../../../../gnusrc/egcs/gcc/config -I../../../../gnusrc/egcs/gcc/../inclu
de -c -DL${name} \
../../../../gnusrc/egcs/gcc/libgcc2.c -o ${name}.o; \
if [ $? -eq 0 ] ; then true; else exit 1; fi; \
/home/rearnsha/gnu/egcs/arm-aout/binutils/ar rc tmplibgcc2.a ${name}.o; \
rm -f ${name}.o; \
done
_muldi3
../../../../gnusrc/egcs/gcc/libgcc2.c:41: stdlib.h: No such file or
directory
../../../../gnusrc/egcs/gcc/libgcc2.c:42: unistd.h: No such file or
directory
gnumake[3]: *** [libgcc2.a] Error 1
I see no mention of newlib in the include path there.
Thinking back, didn't gcc always used to look in <prefix>/<target>/include
?
Doing a quick test with -v shows it is no-longer doing this.
GNU CPP version egcs-2.92.11 19981002 (gcc2 ss-980609 experimental)
(ARM/semi-hosted)
#include "..." search starts here:
#include <...> search starts here:
include
.
../../../../gnusrc/egcs/gcc
../../../../gnusrc/egcs/gcc/config
../../../../gnusrc/egcs/gcc/../include
/home/rearnsha/gnu/egcs/arm-aout/gcc/include
End of search list.
Richard.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: cross-builds failing
1998-10-06 2:10 cross-builds failing Richard Earnshaw
@ 1998-10-06 22:02 ` Jeffrey A Law
1998-10-07 8:00 ` Richard Earnshaw
1998-10-07 2:50 ` Manfred Hollstein
1 sibling, 1 reply; 10+ messages in thread
From: Jeffrey A Law @ 1998-10-06 22:02 UTC (permalink / raw)
To: richard.earnshaw; +Cc: egcs
In message < 199810060909.KAA06594@sun52.NIS.cambridge >you write:
>
> I'm not sure why this has started (or exactly when -- sometime in the last
> couple of weeks I think). I have a cross-build for the ARM set up, with a
> gas and newlib tree linked into my source structure. In the past this has
> always built fine (modulo a few small problems with the latest gas
> snapshots putting intl in a different place).
Probably the libunsubdir problem.
Wait, presumably you did specify --with-headers= right?
> Thinking back, didn't gcc always used to look in <prefix>/<target>/include > ?
Yes, we are still supposed to look at <prefix>/<target_alias>/include.
jeff
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: cross-builds failing
1998-10-07 2:50 ` Manfred Hollstein
@ 1998-10-07 2:02 ` Jeffrey A Law
0 siblings, 0 replies; 10+ messages in thread
From: Jeffrey A Law @ 1998-10-07 2:02 UTC (permalink / raw)
To: manfred, Manfred.Hollstein; +Cc: richard.earnshaw, egcs
In message < 13851.9309.876684.984215@slsvhmt >you write:
> I guess, this is an unfortunate side-effect of the $(unlibsubdir)
> patch that had been applied last week. gcc and cpp are now using a
> relative path starting from $(libsubdir); since your xgcc isnt't already
> installed, $(libsubdir) of course doesn't exist, hence
> $(libsubdir)/../../../${target}/include doesn't either.
>
> Jeff, you mentionened somewhere, that the $(unlibsubdir) was mostly
> meant to aid the Windoof users; how do you think, if we'll be going to
> implement it via a new "--enable-relative-dirs" flag and retain the old
> behaviour as a default?
Something's got to be messed up somewhere -- Cygnus has been using this stuff
for about 4 years now. We've got a bug, we should go fix it, not disable
the feature via configury. :-)
I just backed out one patch that depends on code not yet in the compiler
(the final bits to allow movement of binaries). I don't think it would
effect Richard's problem though.
jeff
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: cross-builds failing
1998-10-06 2:10 cross-builds failing Richard Earnshaw
1998-10-06 22:02 ` Jeffrey A Law
@ 1998-10-07 2:50 ` Manfred Hollstein
1998-10-07 2:02 ` Jeffrey A Law
1 sibling, 1 reply; 10+ messages in thread
From: Manfred Hollstein @ 1998-10-07 2:50 UTC (permalink / raw)
To: richard.earnshaw, law; +Cc: egcs
On Tue, 6 October 1998, 10:09:22, rearnsha@arm.com wrote:
>
> I'm not sure why this has started (or exactly when -- sometime in the last
> couple of weeks I think). I have a cross-build for the ARM set up, with a
> gas and newlib tree linked into my source structure. In the past this has
> always built fine (modulo a few small problems with the latest gas
> snapshots putting intl in a different place).
>
> Now, trying to build the compiler dies when trying to compile libgcc2.c:
>
> for name in _muldi3 ...; \
> do \
> echo ${name}; \
> /home/rearnsha/gnu/egcs/arm-aout/gcc/xgcc -B/home/rearnsha/gnu/egcs/arm-a
> out/gcc/ -O2 -fomit-frame-pointer -DCROSS_COMPILE -DIN_GCC -DSVR4 -g
> -O2 -I./include -I. -I../../../../gnusrc/egcs/gcc
> -I../../../../gnusrc/egcs/gcc/config -I../../../../gnusrc/egcs/gcc/../inclu
> de -c -DL${name} \
> ../../../../gnusrc/egcs/gcc/libgcc2.c -o ${name}.o; \
> if [ $? -eq 0 ] ; then true; else exit 1; fi; \
> /home/rearnsha/gnu/egcs/arm-aout/binutils/ar rc tmplibgcc2.a ${name}.o; \
> rm -f ${name}.o; \
> done
> _muldi3
> ../../../../gnusrc/egcs/gcc/libgcc2.c:41: stdlib.h: No such file or
> directory
> ../../../../gnusrc/egcs/gcc/libgcc2.c:42: unistd.h: No such file or
> directory
> gnumake[3]: *** [libgcc2.a] Error 1
>
> I see no mention of newlib in the include path there.
>
> Thinking back, didn't gcc always used to look in <prefix>/<target>/include
> ?
>
> Doing a quick test with -v shows it is no-longer doing this.
>
> GNU CPP version egcs-2.92.11 19981002 (gcc2 ss-980609 experimental)
> (ARM/semi-hosted)
> #include "..." search starts here:
> #include <...> search starts here:
> include
> .
> ../../../../gnusrc/egcs/gcc
> ../../../../gnusrc/egcs/gcc/config
> ../../../../gnusrc/egcs/gcc/../include
> /home/rearnsha/gnu/egcs/arm-aout/gcc/include
> End of search list.
I guess, this is an unfortunate side-effect of the $(unlibsubdir)
patch that had been applied last week. gcc and cpp are now using a
relative path starting from $(libsubdir); since your xgcc isnt't already
installed, $(libsubdir) of course doesn't exist, hence
$(libsubdir)/../../../${target}/include doesn't either.
Jeff, you mentionened somewhere, that the $(unlibsubdir) was mostly
meant to aid the Windoof users; how do you think, if we'll be going to
implement it via a new "--enable-relative-dirs" flag and retain the old
behaviour as a default?
>
> Richard.
>
manfred
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: cross-builds failing
1998-10-06 22:02 ` Jeffrey A Law
@ 1998-10-07 8:00 ` Richard Earnshaw
1998-10-08 0:15 ` Jeffrey A Law
0 siblings, 1 reply; 10+ messages in thread
From: Richard Earnshaw @ 1998-10-07 8:00 UTC (permalink / raw)
To: law; +Cc: rearnsha
>
> In message < 199810060909.KAA06594@sun52.NIS.cambridge >you write:
> >
> > I'm not sure why this has started (or exactly when -- sometime in the last
> > couple of weeks I think). I have a cross-build for the ARM set up, with a
> > gas and newlib tree linked into my source structure. In the past this has
> > always built fine (modulo a few small problems with the latest gas
> > snapshots putting intl in a different place).
> Probably the libunsubdir problem.
>
> Wait, presumably you did specify --with-headers= right?
Wrong. I've got newlib as part of my source tree. Why should that be
needed? Surely it should pick up newlib in the same way gas gets found if
that is part of the source tree (for which I don't need to say
--with-as=... or whatever).
Anyway, the configure.in script has a comment in which says,
# If both --with-headers and --with-libs are specified, default to
# --without-newlib.
which is not what I want, since I want newlib.
If some special magic is required, can't configure.in fake it up if it
decides it is building a newlib in the source tree.
> > Thinking back, didn't gcc always used to look in <prefix>/<target>/include > ?
> Yes, we are still supposed to look at <prefix>/<target_alias>/include.
>
Well it doesn't seem to be...
Richard.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: cross-builds failing
1998-10-07 8:00 ` Richard Earnshaw
@ 1998-10-08 0:15 ` Jeffrey A Law
1998-10-08 2:04 ` Richard Earnshaw
0 siblings, 1 reply; 10+ messages in thread
From: Jeffrey A Law @ 1998-10-08 0:15 UTC (permalink / raw)
To: richard.earnshaw; +Cc: egcs, rearnsha
In message < 199810071427.PAA13424@sun52.NIS.cambridge >you write:
> > Probably the libunsubdir problem.
> >
> > Wait, presumably you did specify --with-headers= right?
>
> Wrong. I've got newlib as part of my source tree. Why should that be
> needed? Surely it should pick up newlib in the same way gas gets found if
> that is part of the source tree (for which I don't need to say
> --with-as=... or whatever).
Ah. OK. That makes it even more interesting, since that's how we build
at Cygnus and it works. Something hokey is going on.
I get:
#include "..." search starts here:
#include <...> search starts here:
include
/usr/cygnus/blah/lib/gcc-lib/<target>/cygnus-2.92.02/include
/usr/cygnus/blah/lib/gcc-lib/<target>/cygnus-2.92.02/../../../../<target>/include
Maybe my change to DRIVER_DEFINES does fix your problem. It was dependent on
other changes not submitted yet, so I backed it out. I don't immediately see
how it would fix your problem, but it's worth checking.
jeff
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: cross-builds failing
1998-10-08 0:15 ` Jeffrey A Law
@ 1998-10-08 2:04 ` Richard Earnshaw
1998-10-11 2:41 ` Jeffrey A Law
0 siblings, 1 reply; 10+ messages in thread
From: Richard Earnshaw @ 1998-10-08 2:04 UTC (permalink / raw)
To: law; +Cc: rearnsha
>
> In message < 199810071427.PAA13424@sun52.NIS.cambridge >you write:
> > > Probably the libunsubdir problem.
> > >
> > > Wait, presumably you did specify --with-headers= right?
> >
> > Wrong. I've got newlib as part of my source tree. Why should that be
> > needed? Surely it should pick up newlib in the same way gas gets found if
> > that is part of the source tree (for which I don't need to say
> > --with-as=... or whatever).
> Ah. OK. That makes it even more interesting, since that's how we build
> at Cygnus and it works.
That's sort of what I was hoping you would say. When trying to set up a
cross build, trying to follow the configure structure already in place
seams to be the only way I stand a prayer of a chance of getting this to
work. Any chance of newlib and gas/binutils appearing the egcs tree
anytime soon?
> Something hokey is going on.
>
> I get:
>
> #include "..." search starts here:
> #include <...> search starts here:
> include
> /usr/cygnus/blah/lib/gcc-lib/<target>/cygnus-2.92.02/include
> /usr/cygnus/blah/lib/gcc-lib/<target>/cygnus-2.92.02/../../../../<target>/include
>
>
> Maybe my change to DRIVER_DEFINES does fix your problem. It was dependent on
> other changes not submitted yet, so I backed it out. I don't immediately see
> how it would fix your problem, but it's worth checking.
>
> jeff
Nope, at least, not as of 6pm BST yesterday. I think it is the change to
the build rule for cccp.o (which puts libunsubdir in for all the include
search paths). Here is the results of running the command with -v
$ /home/rearnsha/gnu/egcs/arm-aout/gcc/xgcc -B/home/rearnsha/gnu/egcs/arm-a
out/gcc/ -O2 -fomit-frame-pointer -DCROSS_COMPILE -DIN_GCC -DSVR4 -g
-O2 -I./include -I. -I../../../../gnusrc/egcs/gcc
-I../../../../gnusrc/egcs/gcc/config -I../../../../gnusrc/egcs/gcc/../inclu
de -c -DL_muldi3 ../../../../gnusrc/egcs/gcc/libgcc2.c -o tmp/foo.o -v
Reading specs from /home/rearnsha/gnu/egcs/arm-aout/gcc/specs
gcc version egcs-2.92.13 19981007 (gcc2 ss-980609 experimental)
/home/rearnsha/gnu/egcs/arm-aout/gcc/cpp -lang-c -v -I./include -I.
-I../../../../gnusrc/egcs/gcc -I../../../../gnusrc/egcs/gcc/config
-I../../../../gnusrc/egcs/gcc/../include -isystem /home/rearnsha/gnu/egcs/a
rm-aout/gcc/include -undef -D__GNUC__=2 -D__GNUC_MINOR__=92 -Darm
-D__semi__ -D__arm__ -D__semi__ -D__arm -Acpu(arm) -Amachine(arm)
-D__CHAR_UNSIGNED__ -D__OPTIMIZE__ -g -D__ARM_ARCH_3__ -D__APCS_32__
-DCROSS_COMPILE -DIN_GCC -DSVR4 -DL_muldi3 ../../../../gnusrc/egcs/gcc/libg
cc2.c /var/tmp/ccHH05MC.i
GNU CPP version egcs-2.92.13 19981007 (gcc2 ss-980609 experimental)
(ARM/semi-hosted)
#include "..." search starts here:
#include <...> search starts here:
include
.
../../../../gnusrc/egcs/gcc
../../../../gnusrc/egcs/gcc/config
../../../../gnusrc/egcs/gcc/../include
/home/rearnsha/gnu/egcs/arm-aout/gcc/include
End of search list.
../../../../gnusrc/egcs/gcc/libgcc2.c:41: stdlib.h: No such file or
directory
../../../../gnusrc/egcs/gcc/libgcc2.c:42: unistd.h: No such file or
directory
'grep'ing for include in cccp.o shows that it contains the following
include paths, but none of these seem to be being used:
/home/rearnsha/gnu/egcs/install/SunOS5/lib/gcc-lib/arm-semi-aout/egcs-2.92.
13/../../../../arm-semi-aout/include
/home/rearnsha/gnu/egcs/install/SunOS5/lib/gcc-lib/arm-semi-aout/egcs-2.92.
13/../../../../arm-semi-aout/sys-include
/home/rearnsha/gnu/egcs/install/SunOS5/lib/gcc-lib/arm-semi-aout/egcs-2.92.
13/include
/home/rearnsha/gnu/egcs/install/SunOS5/lib/gcc-lib/arm-semi-aout/egcs-2.92.
13/../../../../include/g++
Actually, I think this is all somewhat irrelevant, since the compiler
shouldn't be looking in the install area when newlib is in the source
tree. It should really be getting the headers from
${srcdir}/...../newlib/....
Richard.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: cross-builds failing
1998-10-08 2:04 ` Richard Earnshaw
@ 1998-10-11 2:41 ` Jeffrey A Law
1998-10-13 20:57 ` Richard Earnshaw
0 siblings, 1 reply; 10+ messages in thread
From: Jeffrey A Law @ 1998-10-11 2:41 UTC (permalink / raw)
To: richard.earnshaw; +Cc: egcs, rearnsha
In message < 199810080903.KAA17244@sun52.NIS.cambridge >you write:
> Nope, at least, not as of 6pm BST yesterday. I think it is the change to
> the build rule for cccp.o (which puts libunsubdir in for all the include
> search paths). Here is the results of running the command with -v
Ah. Dumb me.
[ ... ]
> /home/rearnsha/gnu/egcs/install/SunOS5/lib/gcc-lib/arm-semi-aout/egcs-2.92.
> 13/../../../../arm-semi-aout/include
> /home/rearnsha/gnu/egcs/install/SunOS5/lib/gcc-lib/arm-semi-aout/egcs-2.92.
> 13/../../../../arm-semi-aout/sys-include
> /home/rearnsha/gnu/egcs/install/SunOS5/lib/gcc-lib/arm-semi-aout/egcs-2.92.
> 13/include
> /home/rearnsha/gnu/egcs/install/SunOS5/lib/gcc-lib/arm-semi-aout/egcs-2.92.
> 13/../../../../include/g++
>
>
> Actually, I think this is all somewhat irrelevant, since the compiler
> shouldn't be looking in the install area when newlib is in the source
> tree. It should really be getting the headers from
> ${srcdir}/...../newlib/....
No, it shouldn't be looking in the newlib sources (or more correctly, it
does not look there and never has looked there). Sorry, I should have caught
this earlier.
libgcc2.c instead is supposed to avoid including stdio.h and friends when
building with newlib.
Either something is including stdio and unistd unconditionally, or inhibit_libc
is not being defined.
The toplevel configure.in should be finding your newlib source directory and
turning on --with-newlib by default. That in turn causes gcc/Makefile to
define inhibit_libc which is supposed to prevent the problem include files
from being included.
I think this problem is separate from the unlibsubdir problems.
jeff
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: cross-builds failing
1998-10-13 20:57 ` Richard Earnshaw
@ 1998-10-13 19:22 ` Jeffrey A Law
0 siblings, 0 replies; 10+ messages in thread
From: Jeffrey A Law @ 1998-10-13 19:22 UTC (permalink / raw)
To: richard.earnshaw; +Cc: egcs, rearnsha
In message < 199810131447.PAA17838@sun52.NIS.cambridge >you write:
> Any particular reason? (Other than finding the correct include files is
> problematical).
None other than finding the right include files. Part of the problem is
newlib has include files scattered all over the newlib sources.
> > Either something is including stdio and unistd unconditionally, or inhibi
> t_libc
> > is not being defined.
>
> It isn't defined until about 10 lines later in the file.
It should have been defined on the command line. See LIBGCC2_CFLAGS or
whatever it is.
> Ah! The arm ports are overriding LIBGCC2_CFLAGS. I guess this was
> probably done before TARGET_LIBGCC2_CFLAGS was added and never fixed up.
Ah. Yes. I think TARGET_LIBGCC2_CFLAGS may have been invented for this
exact reason!
> PS. It has always struck me as somewhat odd that gcc, which is supposedly
> an ANSI/ISO C compiler needs a Posix header file (unistd.h) and associated
> functions in order to compile its support library.
Yes, it's hokey.
Much of the braindamage can be traced back to assert.h, which gcc provides
for reasons I never understood. A few other things have been added through
the years which want to use stdio.h (gcov & eh support), but at the heart
of the problem was the assert.h support code.
jeff
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: cross-builds failing
1998-10-11 2:41 ` Jeffrey A Law
@ 1998-10-13 20:57 ` Richard Earnshaw
1998-10-13 19:22 ` Jeffrey A Law
0 siblings, 1 reply; 10+ messages in thread
From: Richard Earnshaw @ 1998-10-13 20:57 UTC (permalink / raw)
To: law; +Cc: rearnsha
>
> In message < 199810080903.KAA17244@sun52.NIS.cambridge >you write:
> > Nope, at least, not as of 6pm BST yesterday. I think it is the change to
> > the build rule for cccp.o (which puts libunsubdir in for all the include
> > search paths). Here is the results of running the command with -v
> Ah. Dumb me.
>
This has been fixed now. I guess thanks need to go to Alexandre.
> > Actually, I think this is all somewhat irrelevant, since the compiler
> > shouldn't be looking in the install area when newlib is in the source
> > tree. It should really be getting the headers from
> > ${srcdir}/...../newlib/....
> No, it shouldn't be looking in the newlib sources (or more correctly, it
> does not look there and never has looked there). Sorry, I should have caught
> this earlier.
>
> libgcc2.c instead is supposed to avoid including stdio.h and friends when
> building with newlib.
Any particular reason? (Other than finding the correct include files is
problematical).
>
> Either something is including stdio and unistd unconditionally, or inhibit_libc
> is not being defined.
It isn't defined until about 10 lines later in the file.
/* ??? This is not a good solution, since prototypes may be required in
some cases for correct code. See also frame.c. */
#ifndef inhibit_libc
/* fixproto guarantees these system headers exist. */
#include <stdlib.h>
#include <unistd.h>
#endif
[...]
/* In a cross-compilation situation, default to inhibiting compilation
of routines that use libc. */
#if defined(CROSS_COMPILE) && !defined(inhibit_libc)
#define inhibit_libc
#endif
!!!
>
> The toplevel configure.in should be finding your newlib source directory and
> turning on --with-newlib by default. That in turn causes gcc/Makefile to
> define inhibit_libc which is supposed to prevent the problem include files
> from being included.
>
Ah! The arm ports are overriding LIBGCC2_CFLAGS. I guess this was
probably done before TARGET_LIBGCC2_CFLAGS was added and never fixed up.
Richard.
PS. It has always struck me as somewhat odd that gcc, which is supposedly
an ANSI/ISO C compiler needs a Posix header file (unistd.h) and associated
functions in order to compile its support library.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~1998-10-13 20:57 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-10-06 2:10 cross-builds failing Richard Earnshaw
1998-10-06 22:02 ` Jeffrey A Law
1998-10-07 8:00 ` Richard Earnshaw
1998-10-08 0:15 ` Jeffrey A Law
1998-10-08 2:04 ` Richard Earnshaw
1998-10-11 2:41 ` Jeffrey A Law
1998-10-13 20:57 ` Richard Earnshaw
1998-10-13 19:22 ` Jeffrey A Law
1998-10-07 2:50 ` Manfred Hollstein
1998-10-07 2:02 ` Jeffrey A Law
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).