xgcc (V2.95.3) build error (symlink-tree script problem)

["Wistar, Jonathan" <jwistar at pacelinesystems dot com>]

Greetings,

   I've perused Scott Howard's "CrossGCC Frequently Asked Questions"
and didn't see mine.

   I am attempting to build an "xgcc" for target platform "powerpc-eabi"
on host (and build) platform "i386-pc-interix" (which happens to be
an NT/win2k system).

The build ("make cross") appears to have blown up in the top-level
Makefile when configuring in "powerpc-eabi/libio".  The actual error
is:
    grep: Cannot open file './configure.in': No such file or directory
    *** ./configure.in has no "per-host:" line.
    grep: Cannot open file './configure.in': No such file or directory

"make cross" in the top-level Makefile expands to the following targets
(relevant to this discussion):

	cross -> all -> all.normal
where:
	all.normal depends upon $(ALL_MODULES), $(ALL_X11_MODULES)
		and $(ALL_TARGET_MODULES)

The first target of $(ALL_TARGET_MODULES) is "all-target-libio" which
depends upon configure-target-libio, all-gas, all-ld, all-gcc,
all-target-libiberty,
and all-target-newlib.  It is the first of these ("configure-target-libio")
that is
problematic.  The build rule for "configure-target-libio" is combined with
other "configure-target-xxx" type targets under
the $(CONFIGURE_TARGET_MODULES) rule in the top-level Makefile.

Unfortunately, $(CONFIGURE_TARGET_MODULES) is a somewhat unruly
(no pun intended) rule.  To make this (already) long story short, it's
the "symlink-tree" script that the $(CONFIGURE_TARGET_MODULES)
rule invokes that's at fault.

While comments in gcc/Makefile (oddly not also in the top-level Makefile)
indicate that some systems (like Interix!) may not have symbolic links and
that the Makefile will either use hard-links (if available) or a copy, the
top-level
script "symlink-tree" makes no similar allowance.  It simply assumes that
"ln -s" will work; it doesn't even check the exit status of the command!
Furthermore, the fact that certain Makefiles make allowances for systems
that don't have symbolic links can lead the naive Makefile user into
thinking
that the link "errors" are properly handled by the Makefile and that the
error messages can therefore safely be ignored.  (One must certainly admit,
given the complexity of the build, that it is difficult to discover
otherwise.)

I think the fix is as follows:

	1.  Fix the top-level Makefile to be like the gcc/Makefile, so that
		it allows for systems without symbolic links or without
		hard-links.  (Introduce the LN_S macro -- see gcc/Makefile.)

	2.  Pass the value of the LN_S macro to the "symlink-tree" script.
		(Could be an environment variable or a command line arg.)

	3.  Use the value of LN_S in the symlink-tree script.  In place of:

		else
		   echo "$f                     ..linked"
		   rm -f $f
		   ln -s ${srcdir}/$f
		fi

	    try instead:

		else
		  rm -f $f
		  eval $(LN_S) ${srcdir}/$f  .  ||  cp -p ${srcdir}/$f  .
&&  \
			echo "$f          ..linked"
		fi

-- Jonathan Wistar

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com