This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

build breakage due to r108059


Paolo,

>toplevel:
>2005-12-05  Paolo Bonzini  <bonzini@gnu.org>
>
>	* configure.in (CONFIGURED_BISON, CONFIGURED_YACC,
CONFIGURED_M4,
>	CONFIGURED_FLEX, CONFIGURED_LEX, CONFIGURED_MAKEINFO): Remove
>	"CONFIGURED_" from the AC_CHECK_PROGS invocation.  Move below.
>	Find in-tree tools if available.
>	(EXPECT, RUNTEST, LIPO, STRIP): Find them and substitute them.
>	(CONFIGURED_*_FOR_TARGET): Don't set nor substitute.
>	(*_FOR_TARGET): Set them with GCC_TARGET_TOOL.
>	(COMPILER_*_FOR_TARGET): New.
>...
>config:
>2005-12-05  Paolo Bonzini  <bonzini@gnu.org>
>
>        * acx.m4 (GCC_TARGET_TOOL): New.

the way GCC_TARGET_TOOL gets evaluated breaks builds in a tree without
binutils sources, but with (some) binaries put into a binutils
subdirectory of the output tree. Many years ago, I had been advised that
putting ar, ranlib, and nm binaries in a binutils subdirectory would
allow gcc's configure to find and use them, and in fact gcc is still
looking there. However, since AR_FOR_TARGET gets passed on the make
command line, the attempt to set AR_FOR_TARGET in gcc/Makefile is simply
ignored.

In the given case, building cross tools for i686-novell-netware on
i686-pc-linux-gnu, I don't have i686-novell-netware-ar (and similar
other tools; I entirely dislike this naming scheme), but I do have
(which doesn't seem to matter at all, and never did)
/usr/local/i686-novell-netware/bin/ar etc, which (prior to running
configure) I create links to in $(objdir)/binutils/.

I would suppose that GCC_TARGET_TOOL should not only check whether the
directory of $4 is among $(configdirs), but also if $4 itself
pre-exists.

Thanks, Jan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]