This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


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

Re: Building arm-elf cross under GCC 3.0.4 on HP-UX 11.00


Jepsen Hans Peter wrote:
> 
> >  Don't ever use PATH for setting search paths for GCC, see
> > the default search
> > paths using 'gcc -print-search-dirs' etc., and add more
> > directories there using
> > the 'GCC_EXEC_PREFIX'... Consult your GCC-manual about these
> > things : "Environment
> > Settings for GCC" or something there...

 To elaborate:  the GCC-driver, 'gcc' or something, searches first from
its own path, told with the 'programs' in the 'gcc -print-search-dirs'
output, and using the base names, 'cpp0', 'cc1', 'as', 'ld', 'nm'.., then
if not found there, using the system PATH. A common mistake is to configure
and install the GNU binutils using different settings for $prefix and $target
than with GCC, then the built 'gcc/xgcc' cannot find them and the native 'as',
'ld' etc. will be tried... 

 When the user writes a command on the command prompt, the system PATH
will be used. This happens also in Makefiles etc., but 'gcc' is another
kind of 'sh' with its own search paths...

> >  If you can build the 'arm-elf' targeted GCC yourself, there
> > is no reason to not
> > use the default '$prefix/$target/bin' for the target
> > binutils, so that the GCC
> > and the binutils configured using them will work perfectly
> > together... Then even
> > the GCC_EXEC_PREFIX is not necessary.
> 
> I tried this on my HP-UX 10.20 machine:
> 
> cd build-binutils
> 
> ../binutils-2.11.2/configure --host=hppa2.0-hp-hpux10.20
> --target=powerpc-eabi --prefix=/opt/local/gcc-3.0.4/powerpc-eabi
> 
> gmake all install

 The stuff which 'gcc' may need will be installed into the '$prefix/$target/bin',
while the stuff which the user, Makefiles etc. may need will be installed into
the '$prefix/bin' using the exec-prefix, '$target-', here 'powerpc-eabi-'.

 Of course everything the user, Makefiles etc. may need, should be on the system PATH,
so the '$prefix/bin' should be on the system PATH, but the '$prefix/$target/bin' shouldn't
ever be there...

 Your '$prefix/$target/bin' here is '/opt/local/gcc-3.0.4/powerpc-eabi/powerpc-eabi/bin',
ie. the 'powerpc-eabi' being there twice... Why ?  Wouldn't the $target appearing there
once could have been better, so using '--prefix=/opt/local/gcc-3.0.4' a better choice?

> cd ../build-gcc-core
> 
> ../gcc-3.0.4-core/configure
> --with-gcc-version-trigger=/home/hpj/work/gcc-3.0.4-core/gcc/version.c
> --host=hppa2.0-hp-hpux10.20 --target=powerpc-eabi
> --prefix=/opt/local/gcc-3.0.4/powerpc-eabi --enable-languages=c
> --with-local-prefix=/opt/local/gcc-3.0.4/powerpc-eabi/powerpc-eabi

  I remember the '--with-local-prefix=' setting the place for the LOCAL_INCLUDE_DIR,
so your setting will put it to be the same as the TOOL_INCLUDE_DIR ('$prefix/$target/include'),
ie. the place for the target headers. But the FSF-sources don't enable LOCAL_INCLUDE_DIR for
cross-compilers (it can be enabled by patching 'gcc/cccp.c' or with gcc-3.x 'gcc/cpp-defaults.h'),
so this hasn't a meaning here... But perhaps it influences to the GPP_INCLUDE_DIR too...

> --without-headers --with-newlib --disable-shared
> 
> gmake all-gcc install-gcc
> 
> Then I get the error:
> powerpc-eabi-ar  rc ./libgcc.a ........
> gmake[2]: powerpc-eabi-ar: Command not found
>
> What should I to to avoid this error???

 The '$prefix/bin' should be on the system PATH.  The configure puts the Makefile to use the
'needed-by-user' executables, not the 'needed-by-gcc' executables in '$prefix/$target/bin'.
The aim is that the '$target-' prefixed executables would be available for the user.

> >  I remember the messing with PATH being very common among the
> > HP-UX users, meanwhile
> > all the other GCC-users never use it to point to the GNU
> > binutils...  So there must
> > be some FAQ or something the HP-UX-users all have read, and
> > it saying that the GNU
> > binutils must be pointed with PATH or something... Any clues
> > about where you got
> > this idea?
> 
> I can not remember, where I got this idea from. But I have experienced
> several times, that when I not set the PATH between building binutils and
> building gcc, I get an error.

 Yes, PATH must be set to point to the common (for all cross-GCCs) '$prefix/bin'...
If using the default prefix, '/usr/local' (ie. not using the '--prefix=' at all), it may
be that the '/usr/local/bin' already is in the PATH...

 Perhaps there is something wrong with the native HP-UX binutils and the base-named GNU-
binutils in '$prefix/hppa1.1-hpux11.00/bin' or something are preferred in the native
installations... The NG 'gnu.gcc.help' used to have messages from HP-UX users and they
always using PATH to point into the '$prefix/$target/bin' in their native GCC-installs...

Cheers, Kai



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


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