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] |
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] |