delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/04/16/05:54:03

Date: Sun, 16 Apr 2000 13:32:43 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Ultan Henry <ultan AT cix DOT compulink DOT co DOT uk>
cc: djgpp AT delorie DOT com
Subject: Re: Environment variables
In-Reply-To: <memo.394413@cix.compulink.co.uk>
Message-ID: <Pine.SUN.3.91.1000416131808.3948C-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Sun, 16 Apr 2000, Ultan Henry wrote:

> I've built an arm-elf cross-compiler built and hosted on DJGPP. The tools 
> are installed in 'C:\armtools' and work correctly when run from other 
> directories on the C drive.
> 
> However, there is a problem if I try to run the compilers while in a 
> directory on another disk. In this case, no path seems to be found to the 
> 'crt0.o' file for linking.

What does the compiler and the linker print if you add -v to the 
compilation/link command line?  That should give you enough clues in most 
cases.

> COMPILER_PATH=%DJDIR%\arm-elf\bin\
> GCC_EXEC_PREFIX=%DJDIR%\lib\gcc-lib\

It is generally better to use forward slashes.  I don't know if that 
will solve your problems (probably not, see below), but it's worth doing 
anyway.

Also, I think only GCC_EXEC_PREFIX should end with a slash (and with a 
forward slash!), COMPILER_PATH should not.

> C_INCLUDE_PATH=%/>;C_INCLUDE_PATH%%DJDIR%/include
> LIBRARY_PATH=%/>;LIBRARY_PATH%%DJDIR%/lib
> -------------------
> 
> Without setting GCC_EXEC_PREFIX as shown, the compiler uses its built-in 
> specs and the CPP seems to be called recursively with a ever increasing 
> (and repeated) list of options. Again, this only happens when calling the 
> compilers from a drive other than the C drive on which they are installed 
> which I assume is due to the use of relative paths.
> 
> Is there a way to allow the 'crt0.o' file to be found correctly, or 
> perhaps this is due to a mistake in the configuration used to build the 
> compilers (shown below)?

The problem of infinite recursion in cpp invocation and the problem of 
finding the crt0.o file are two different problems.  In particular, 
neither GCC_EXEC_PREFIX nor COMPILER_PATH are relevant to where GCC looks 
for crt0.o.

As for the fact that the compiler uses its built-in specs, that might or 
might not be a problem.  The important question is: are the built-in 
specs appropriate for your cross-development configuration?  If they are, 
you don't need to worry about specs.  If they aren't, you need to make 
sure that specs is where GCC looks for it.

>            --with-local-prefix=/armtools/arm-elf \
>            --with-gxx-include-dir=/armtools/lang/cxx \
>            --prefix=/armtools

I think this is wrong: your *-prefix settings don't include the drive 
letter.  So GCC looks for its components in /armtools on the CURRENT
drive, which will only work when you invoke the compiler from the same 
drive where it's installed.

I suggest to reconfigure with prefix=c:/armtools/.. or /dev/c/armtools
(the latter might be better for various scripts that might not grok 
DOS-style file names with drive letters), then rebuild and see if that 
helps to solve the problem. 

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019