This is the mail archive of the
mailing list for the GCC project.
Re: Always create target tools in the gcc directory, take 6 (Re:[PATCH] gcc configure's determination of ld and as)
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- Cc: Alan Modra <amodra at bigpond dot net dot au>, Daniel Jacobowitz <drow at false dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 16 Jun 2005 19:52:42 -0400 (EDT)
- Subject: Re: Always create target tools in the gcc directory, take 6 (Re:[PATCH] gcc configure's determination of ld and as)
- References: <20050602112222.GE30701@bubble.grove.modra.org> <42A02240.email@example.com>
On Fri, 3 Jun 2005, Paolo Bonzini wrote:
> > * configure.ac (gcc_cv_as, gcc_cv_ld): Examine MD_EXEC_PREFIX in
> > tm files to determine compiler search path. Kill code duplication.
> I implemented this on top of the "always create gcc/as and friends"
> neverending stor^W^W patch.
> Here is the new version, tested while working on gcc in various kinds of
(Not putting the patch and ChangeLog in-text causes quoting
problems now. Perhaps I could have spotted the bug while
writing this reply!)
I have reason to believe that this patch causes the following
build error (cutandpasted):
rm -f include/limits.h
cp xlimits.h include/limits.h
chmod a+r include/limits.h
rm -f include/README
chmod a+r include/README
echo timestamp > stmp-int-hdrs
make: *** No rule to make target
`/usr/local/mmix-knuth-mmixware-as', needed by `stamp-as'.
make: Leaving directory `/home/hp/combined/mmixware-sim/gcc'
make: *** [all-gcc] Error 2
make: Leaving directory `/home/hp/combined/mmixware-sim'
make: *** [mmixware-sim/built.stamp] Error 2
make: Leaving directory `/home/hp/combined'
I presume this patch was not tested with a one-tree cross build,
without any installed target tools, and with configure earlier
checking what assembler to use... "newly built gas"
checking what linker to use... "newly built ld"
checking what nm to use... "newly built nm"
checking what objdump to use... "newly built objdump"
You should be able to produce the error for any (cross) target
given those circumstances, but why not try