OSDev.org

• Export variables for all of your host tools (the ones being used to compile your toolchain) like so

  Code: Select all

  export SDK_PATH=/C/MinGW
  
  export CPP=$SDK_PATH/bin/cpp
  export CC=$SDK_PATH/bin/gcc
  export CXX=$SDK_PATH/bin/g++
  export AS=$SDK_PATH/bin/as
  export LD=$SDK_PATH/bin/ld
  export NM=$SDK_PATH/bin/nm
  export READELF=$SDK_PAth/bin/readelf
  export OBJCOPY=$SDK_PATH/bin/objcopy
  export OBJDUMP=$SDK_PATH/bin/objdump
  export DLLTOOL=$SDK_PATH/bin/dlltool
  export AR=$SDK_PATH/bin/ar
  export RANLIB=$SDK_PATH/bin/ranlib
  export STRIP=$SDK_PATH/bin/strip
  export WINDMC=$SDK_PATH/bin/windmc
  export WINDRES=$SDK_PATH/bin/windres
  

  This is to prevent the build process from confusing the host toolchain with the target toolchain. If you don't do this, your build process will probably halt with a linking error; probably something about libiberty or libiconv.
• Pass the option '--program-prefix=""' to the configuration scripts for both binutils and gcc

cross
 +- bin
 +- i686-pc-elf
 +- include
 +- lib
 '- share

	arch)
		basic_machine=i686-pc
		os=-elf
		;;

DaemonR wrote:Export variables for all of your host tools (the ones being used to compile your toolchain) like so

Code: Select all

...

This is to prevent the build process from confusing the host toolchain with the target toolchain. If you don't do this, your build process will probably halt with a linking error; probably something about libiberty or libiconv.

sortie wrote:I really don't think --enable-64-bit-bfd is required when making a cross-compiler for a 64-bit system on a 32-bit system. Do you have evidence for this?

sortie wrote:Why would you possibly want your cross-tools to not be prefixed with a target triplet or something unique? That is mad and causes conflicts with the local toolchain as you discovered. Always prefix your cross-tools.

export PATH=/C/MinGW/bin:$PATH

Lastly what you see in the directory tree is the obscure `tools directory'. You can't override it from the configure line, but it's fairly simple to override the toolsdir variable in the makefile. This is really of no concern when cross-compiling, you don't want to actually use the programs in that directory directly, just use the regular ones in the bin directory that have the target triplet prefixed.

XenOS wrote:This linking error never happened to me, and I don't know of anyone else who encountered this problem. I dare to say that a linking error is a lot less probable than you assume.

export PATH=$PREFIX/bin:$PATH

export PATH=$PATH:$PREFIX/bin

DaemonR wrote:The error only occurs when you're using --program-prefix="". It happens because the programs in your target toolchain and your host toolchain are both named exactly the same.[/code]

jnc100 wrote:The only times you should need to specify it explicitly is if the --target is a 32-bit target, but you also specify a 64-bit target with an additional --enable-targets= option.

bluemoon wrote:Why do you want to have those compilers having exactly same names and managed by search path? The rest of the world choose to identify them by different names.

export PATH=$TOOLCHAINPATH:$PATH

export PREFIX=x86_64-pc-elf-

export CC=$PREFIXgcc
export CXX=$PREFIXg++
export AS=$PREFIXas
export LD=$PREFIXld
export AR=$PREFIXld
export RANLIB=$PREFIXranlib
export OBJDUMP=$PREFIXobjdump
export OBJCOPY=$PREFIXobjcpy

DaemonR wrote:...the information is necessary to those who are building native toolchains for their operating systems.

DaemonR wrote:@XenOS, As I stated before, the information is necessary to those who are building native toolchains for their operating systems.

As I've already said, it's so that I can easily switch between my toolchains by typing

Combuster wrote:Usability differences are that people will have problem building your project, and will most likely accuse you of not using a cross compiler for failing the sanity checks listed in the Posting Checklist.