[paludis-user] Tale of an evening with Contrarius

Jérôme Carretero cJ-paludis at rez-metz.supelec.fr
Sat May 3 07:30:39 UTC 2008


For some time I've been wanting to build a cross-compilation toolchain to use distcc on my machines having different architectures, but contrarius didn't like me much.
Tonight, exceeded, I decided to succeed in using it.

The first machines : the i686 one is MacGyver and the x86_64 one is newnew.

In the next paragraph I'm telling my installation story on MacGyver, hoping to help (could be useful to #paludis troubleshooters, or users grepping the ML).
As contrarius didn't work out of the box (see ticket #552) I have had to use "-* nocxx" use flags for cross-(i686|x86_64)-pc-linux-gnu/gcc (version 4.2.3 FYI).


Then, wanting to compile C++ stuff, I tried to install gcc with C++ support.
For that, you need glibc (if you try to build gcc without nocxx, gcc build miserably fails, complaining about glibc missing headers (in config.log, the displayed reason is something not useful)).

So, building glibc (2.7-r2) ...
-----%<-----
Checking gcc for __thread support ... [ !! ]
 * Could not find a gcc that supports the __thread directive!
-----%<-----

I messed with the want__thread function of files/eblits/common.eblit to override it (without understanding what happened) and had another problem in the configure script.

-----%<-----
configure:3297: checking for suffix of object files
configure:3323: i686-pc-linux-gnu-gcc -c -m64 -O2 -fno-strict-aliasing  conftest.c >&5
conftest.c:1: sorry, unimplemented: 64-bit mode not compiled in
[...]
configure:3341: error: cannot compute suffix of object files: cannot compile
-----%<-----

Of course -m64 can't work... this is due to the multilib.eclass, which added this cflag (see line 568).
I realized that this problem was caused by my careless setting of CC in the bashrc (I first edited the eclass, and saw that i686-...-gcc was used to compile target code...), so I unset it.
The installation went better : it finished.
I was able to verify that __thread stuff works, when CC is unset.


Now that the headers and glibc are there, it's time to build gcc with C++.
It happened quietly.

Conclusions, observations :
 * I saw that it is possible to use contrarius, it works.
 * All the errors I had were due to CC setting ->  _do not_ set CC when building a cross glibc
 * The toolchain ebuilds handle cross-stuff automatically and they are not simple ones, kudos to their creators (sudden pasta-eating urge).
So, a lot of users have figured out how to use paludis to build exotic cross-toolchains.
But it would be nice having contrarius to be able to use an alternative configuration file (platform tuples vs. packages (yes, "avr" makes a strange "tuple")).
 * cross-gcc binaries aren't appended with version names
 * local use flags descriptions for cross-*/* packages don't work (ciaranm, that's why I mentionned per-ebuild (I meant in-ebuild) use descriptions on #paludis today)

Installation of the i686-pc-linux-gnu toolchain went without trouble on newnew.
ccache and distcc work fine.


-- 
cJ aka Zougloub on freenode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.exherbo.org/pipermail/paludis-user/attachments/20080503/8d231b88/attachment.asc>


More information about the paludis-user mailing list