OSDev.org

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:



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.)

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

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

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

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.

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.

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

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.

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.

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.

/facepalm

all-gcc...