I'm trying to build a cross toolchain using gcc-3.4.3.20050110. The host is a Gentoo i686 with glibc, the target is an arm with uclibc. As far as I can tell from the results, configure always performs its checks against the host headers (/usr/include), not against the target headers (/usr/arm-unknown-linux-uclibc/include in my case). I noticed that because: * The "configure" step of a full cross gcc build succeeds with normal-looking results even when the target headers have not yet been installed at all! (I think it should fail in that case) * Even after installing the target headers, some configure guesses look wrong w.r.t. to the target uclibc (I'm still analyzing that...) In my case, the headers are very different (glibc versus uclibc), and for building the target parts (libgcc, Java libs, ...), configure should of course analyze the target headers! gcc's configure provides the options "--with-headers=..." and "--with-sysroot" for that purpose, but according to the log, these are not used when emerging a cross gcc.
i can only assume you did it wrong since you neglected to provide `emerge info`, a description of how you built your toolchain, or any log files ive built arm-pc-linux-uclibc cross toolchains many times and none had probs
First of all, sorry for not providing any additional info's. I'm building this cross-toolchain at work, and I'm not allowed to connect that "experimental" machine to the company's network (according to the rules of the house, only windows machines installed by the central administration may be hooked up). So I have no web or mail access from there. I'm closely following the gentoo cross development howto. There are several reasons why I believe something's going wrong (I can't check the details now from home): * On my very first attempt, I forgot to install the target uclibc in the target directory (I emerged it with -B without actually installing it). Then, I tried to compile the "real" gcc for the target (not the bootstrapping C-only gcc). Surprisingly, the configure step did not complain although there were no target headers at all (except for the linux kernel headers), and although the libgcc configure definitely performs some tests which require and analyze the target headers. The emerge then failed when actually compiling some libgcc files (with "header ... not found"). Hence, the libgcc configure obviously performed its tests w.r.t. to the host header files, otherwise, it would have failed. * After I actually installed the target uclibc, the cross gcc emerged without any problem. As I did not yet compile any applications for the target, I cannot tell yet if the resulting libgcc is fine or has some subtile, still unnoticed defects showing up later. However, a first glance at the log of the emerge (as I said, I still have to check the details) suggests that libgcc is correctly built against the target headers (and hence might actually work), but the configure step of libgcc has configured it w.r.t. the host headers (which might or might not result in problems or inconsistencies). * By searching the internet, looking at other, similar cross-toolchain build tools, and checking the gcc documentation, I got the impression that cross builds of gcc must be configured with either "--with-headers=..." or "--with-sysroot=..." when source and target headers differ. According to the emerge log, neither of these options is used when emerging a cross gcc.
if the gcc version was 3.3.5*, then search the embedded ml for an ebuild patch that solves your problem
No, I tried with gcc-3.4.3.20050110.
did you use emerge to install binutils/gcc/linux-headers/uclibc ?
Yes, I followed the Gentoo Howto for building the cross toolchain.
try emerging crossdev-0.9.1+ and using that ... clean out all your old stuff first
I've tried crossdev before, and I did the same steps manually (I just double-checked). It still does not use --with-sysroot when building gcc. According to the docs of gcc configure, it should. However, as far as I can tell, even without --with-sysroot, it does the right thing... I also compared with the way gcc is built by the "buildroot" script: "buildroot" uses --with-sysroot for the first gcc configure. It does not use --with-sysroot for the second gcc configure, however, it sets the --prefix to the root of the target directory tree (and hence the target include files).
when i tested --with-sysroot, the build required more info/etc... in order to work properly utilizing --with-headers worked fine for me though and is backwards compat with gcc-3.3.x unlink --with-sysroot
stage2 gcc uses sysroot now
