[Nix-dev] Re: [Nix-commits] SVN commit: nix - 18833 - viric - in nixpkgs/branches/stdenv-updates/pkgs: development/compilers/gcc-4.3 development/compilers/gcc-4.4 top-level

[Lluís Batlle]

Hello,

2009/12/8 Ludovic Courtès <ludo at gnu.org>:
> Hi,
>>> We’ve already discussed that elsewhere, but having cleaned the gcc 4.4
>>> expression from such nix-specific kludges, I was really hoping they
>>> would not come back a few months later.  ;-)
>> We still need to find something simpler and *keeping functionality*.
>> You wrote a simpler code, loosing some functionality (compared to the
>> gcc-4.3 expression that can build a cross compiler, I mean). :)
>
> There was no cross-compilation support back then.  But I agree that we
> want a solution that makes it possible to build a cross compiler.
>
>>> I understand using $LIBRARY_PATH and $CPATH was somehow causing you
>>> troubles for building a cross-compiler (or was it cross-compiling a
>>> compiler?), but still, I think we should strive to use the standard
>>> build system as much as we can so that it’s maintainable,
>>> understandable, etc.
>> I prefer the approach of a patch at the proper place,
>
> The patches you committed are against ‘configure’ and ‘Makefile.in’
> files; the former are large automatically generated scripts and the
> latter are large automatically generated makefile templates.  I think
> maintaining patches against such beasts is going to be a lot of work.
I agree. We should push for proper patches to get upstream. But I also
don't like the idea of patching the source of those generated files,
and then we doing the work of generating the rest of the files.
For gcc 4.3 it has not been any pain maintaining the patches, for 4.4
parts changed, and for 4.5 it may change even more.
>
>  [y]ou should also provide the target libraries and headers before
>  configuring GCC, specifying the directories with --with-sysroot or
>  --with-headers and --with-libs
>
> How does it work for you?
--with-libs copies all the path-you-pass/* to the proper target/lib
directory inside the gcc build. --with-headers does something similar
with the headers. Then those paths are automatically included in the
build process.
It may very well work - while I use --with-headers, I did not try
--with-libs. I will try. I hope we can avoid then the libtool patches
for -B.

> It seems similar to what I described in
> http://gcc.gnu.org/ml/gcc-help/2008-04/msg00185.html .  My understanding
> was that $LDFLAGS_FOR_TARGET alone is not enough; ‘-B’ also needs to be
> passed in $BOOT_LDFLAGS at ‘make’ time (not at ‘configure’ time).
The BOOT_LDFLAGS are used only in building a native compiler, for the
internal bootstrap, afaik.
And even using them, -B will not pass to the libmudflap shared library
I think. Have you checked that?

>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279 - gcc 4.3.4 related;
>> the libmudflap build system received the wrong CPP (that of the host,
>> instead of that of the target). It made the its configure script take
>> system glibc headers instead of the target libc's. We have that fix in
>> the actual gcc-4.3.4 expression (fixed in gcc 4.4.2 I think)
>
> So is it fixed in 4.4.2?
By now I have not seen that problem in gcc-4.4.2, so I have not
written any patch for it. But I will test better with uclibc, that
triggers the probelm, and I may not have tested it with gcc 4.4.
>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42280 - in gcc 4.4.2 they
>> packaged  'zlib' additionally in the core package. This broke some
>> target libgcc dependency calculation in the configure script. We have
>> this patch (removing the supplied zlib) in the actual gcc 4.4
>> expression.
>
> As was said ‘--without-headers’ probably isn’t the right option (what
> would it mean to build without C library headers?).  AIUI, it should be
> ‘--with-headers=/path/to/cross/glibc/include’.
In order to bootstrap a cross-compiler, the usual build steps I've
seen around are:
1. Build a gcc without libc, capable of compiling C into object files,
not capable of creating ELFs or any shared object.
2. With the gcc in 1., build a libc. After that, we will have
startfiles, headers and libs installed.
3. With the gcc in 1. and the libc of 2., build the final gcc
involving the libc headers, libc libraries, startfiles and whatever
libc parts.
>
> (BTW, zlib is only needed when building GCJ, as can be seen in the
> expression in trunk.)
That zlib is not that of the gcc tree, so I guess you don't need the
libc in the gcc tree.

Thank you,
Lluís.