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

[bgat at billgatliff dot com]

Check out http://crossgcc.billgatliff.com.  It's a modestly updated FAQ, and contains a link to a script that can build a powerpc-eabi xgcc.

b.g.

On Wed, Jun 13, 2001 at 01:17:40PM -0400, Wistar, Jonathan wrote:
> 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
> 

-- 
Bill Gatliff
bgat@billgatliff.com

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