GCC 4.5.0 and the cross-compiler tutorial

[Solar]

Transferring this from the Wiki discussion page...

GCC 4.5.0 introduces a new dependency, the MPC library, which isn't covered by the tutorial yet. But that isn't my problem.

It seems that the tutorial only works when you use /usr/local as the prefix.

During the configure step for GCC, you state --with-gmp=..., --with-mpfr=... and --with-mpc=..., which allows the build process to find the headers and linker libraries. Unfortunately the search path for the libraries does not get coded into the resulting executables:

Code: Select all

/usr/src/build-gcc/gcc $ ldd cc1
	linux-gate.so.1 =>  (0xb804e000)
	libmpc.so.2 => not found
	libmpfr.so.1 => /usr/lib/libmpfr.so.1 (0xb7fed000)
	libgmp.so.10 => not found
	libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7fe8000)
	libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e85000)
	libgmp.so.3 => /usr/lib/libgmp.so.3 (0xb7e3e000)
	/lib/ld-linux.so.2 (0xb804f000)

Not only does cc1 not find the libmpc.so.2 despite being told it resides in /usr/cross/lib during the configure, it also links the system-provided gmp / mpfr libraries in /usr/lib despite being told to use those in /usr/cross/lib.

I really despise this kind of autoconfig stupidity.

I don't like mixing manually-installed libraries with the code under control of my system package manager, and anyway by using $PREFIX our tutorial gives the impression of being independent of the actual location binaries are installed to - which obviously it is not.

And editing /etc/ld.so.conf isn't an option for people who are working as non-root on shared systems.

I'd really like to file this as a bug in GCC / Autoconfig, but I know what the answer would be.

How do we handle this in the tutorial? Hardcode /usr/local and scrap $PREFIX, recommend editing /etc/ld.so.conf (which would be tricky since distros differ in this regard), or something else? (Please nobody recommend setting LD_LIBRARY_PATH, that's evil.)

[Solar]

Personally, I'd suggest scrapping the "installing from source" part for GMP, MPFR and MPC (which aren't cross-compile specific anyway), and instead recommend installing the appropriate packages (e.g. libmpc-devel) through the respective system package manager. That way, cross-binutils and cross-GCC can be installed anywhere you like, and you don't even have to state --with-gmp etc. during config.

[JackScott]

I totally agree with you. It seems the best solution for everybody (including, even, the people using cygwin). It's mentioned deep in the bowels of the wiki, but the only requisite package you need for Debian is 'libmpfr-dev'. It'll install everything else as a dependency.

[Solar]

Hmmm... I just tried my own suggestion, and it doesn't work.

GCC requires mpc 0.8.0+, and e.g. my Linux Mint installs v 0.5.2...

Damn. I wouldn't want to start explaining people how to use unstable / testing repositories for their respective distros...

[JackScott]

Isn't being able to use your current operating system a prerequisite for starting off in OSDev?

[Solar]

Yep. I should retire from the field - the reason for my libmpc being outdated is that I'm still using Mint v7.0 when v9.0 is bound for release this month.

So ignore my last post. Using the system package manager is the way to go.

[Combuster]

I'd still file the bug for the sake of it. If they do tell us "that's a feature, not a bug" we have a legit excuse to call them names.

Maybe I should try how well llvm suits as a drop-in replacement for gcc.

[Solar]

I'd still file the bug for the sake of it.

Have fun. I got bitten by this in several projects already. It's a commen occurence in Autoconfig projects, dragging in system libraries even when being told to use different ones. It's a ***** when you want to compile for a production system using a specific version of e.g. Boost, but the Autoconfig keeps dragging in your *system* Boost, which is a completely different version...

[quok]

Personally, I'd suggest scrapping the "installing from source" part for GMP, MPFR and MPC (which aren't cross-compile specific anyway), and instead recommend installing the appropriate packages (e.g. libmpc-devel) through the respective system package manager. That way, cross-binutils and cross-GCC can be installed anywhere you like, and you don't even have to state --with-gmp etc. during config.

I'll second that. If anyone really wants to install those from source, all they have to do is unpack the GMP source to gmp/ inside the GCC source tree. Also unpack MPFR to mpfr/, and MPC to mpc/. Then GCC will compile and use the ones in the source tree instead. Supposedly anyway, I haven't tested it, but the docs say it should work.

Personally I just use my package manager to install those libraries and allow the cross compiler to link against them.

[Solar]

Putting the gmp / mpfr / mpc directories into the GCC source tree indeed works. However, the build insists on configuring libstdc++-v3, which bails out with "error: Link tests are not allowed after GCC_NO_EXECUTABLES"...

That's not only GCC 4.5.0, GCC 4.4.4 does the same.

Strange. Suddenly it's me who can't build a cross-compiler while everybody else says things are fine.

[pcmattman]

libstdc++-v3 will only be compiled if you didn't use only "make all-gcc && make install-gcc", which the tutorial says to do.

Unless of course 4.5.0 has libstdc++-v3 included in the all-gcc target now, which would be silly.

[Solar]

/facepalm

all-gcc...

[protecyon]

It's a hack but to help GCC find the libraries you can create the LD_LIBRARY_PATH for example:
LD_LIBRARY_PATH=/mydir/gmp/lib:/mydir/mpc/lib:/mydir/mpfr/lib

Transferring this from the Wiki discussion page...

GCC 4.5.0 introduces a new dependency, the MPC library, which isn't covered by the tutorial yet. But that isn't my problem.

It seems that the tutorial only works when you use /usr/local as the prefix.

During the configure step for GCC, you state --with-gmp=..., --with-mpfr=... and --with-mpc=..., which allows the build process to find the headers and linker libraries. Unfortunately the search path for the libraries does not get coded into the resulting executables:

Code: Select all

/usr/src/build-gcc/gcc $ ldd cc1
	linux-gate.so.1 =>  (0xb804e000)
	libmpc.so.2 => not found
	libmpfr.so.1 => /usr/lib/libmpfr.so.1 (0xb7fed000)
	libgmp.so.10 => not found
	libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7fe8000)
	libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e85000)
	libgmp.so.3 => /usr/lib/libgmp.so.3 (0xb7e3e000)
	/lib/ld-linux.so.2 (0xb804f000)

Not only does cc1 not find the libmpc.so.2 despite being told it resides in /usr/cross/lib during the configure, it also links the system-provided gmp / mpfr libraries in /usr/lib despite being told to use those in /usr/cross/lib.

I really despise this kind of autoconfig stupidity.

I don't like mixing manually-installed libraries with the code under control of my system package manager, and anyway by using $PREFIX our tutorial gives the impression of being independent of the actual location binaries are installed to - which obviously it is not.

And editing /etc/ld.so.conf isn't an option for people who are working as non-root on shared systems.

I'd really like to file this as a bug in GCC / Autoconfig, but I know what the answer would be.

How do we handle this in the tutorial? Hardcode /usr/local and scrap $PREFIX, recommend editing /etc/ld.so.conf (which would be tricky since distros differ in this regard), or something else? (Please nobody recommend setting LD_LIBRARY_PATH, that's evil.)

[pcmattman]

It's a hack but to help GCC find the libraries you can create the LD_LIBRARY_PATH for example

It's not a hack but to help GCC find the libraries you can use:

Code: Select all

--with-gmp
--with-mpfr
--with-mpc

Install GMP, MPFR and MPC in one root, say, /usr, and then pass "--with-gmp=/usr" to configure and it will find the rest.

configure will probe <with_gmp_path>/lib and <with_gmp_path>/include for all three dependencies - if you have separate directories for each you'll need all three options.

There's absolutely no need to fiddle with environment variables in this tutorial, apart from adding $PREFIX/bin to $PATH (which is only necessary if you want to run the output after building it).

[protecyon]

I had a situation where the 3 libraries were in separate places for example:

/opt/name/mpc
/opt/name/mpfr
/opt/name/gmp

and after I ran the configure using the
--with-gmp=/opt/name/gmp
--with-mpc=/opt/name/mpc
and
--with-mpfr flags=/opt/name/mpfr

the make would not complete successfully until I added the libraries to LD_LIBRARY_PATH.

I am new to this so I might have done something wrong to make the previous necessary, but it was something that I ended up having to do to successfully create a cross-compiler for a PowerPC target.

It's a hack but to help GCC find the libraries you can create the LD_LIBRARY_PATH for example

It's not a hack but to help GCC find the libraries you can use:

Code: Select all

--with-gmp
--with-mpfr
--with-mpc

Install GMP, MPFR and MPC in one root, say, /usr, and then pass "--with-gmp=/usr" to configure and it will find the rest.

configure will probe <with_gmp_path>/lib and <with_gmp_path>/include for all three dependencies - if you have separate directories for each you'll need all three options.

There's absolutely no need to fiddle with environment variables in this tutorial, apart from adding $PREFIX/bin to $PATH (which is only necessary if you want to run the output after building it).