[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

[Ludovic Courtès]

Hi,

Lluís Batlle <viriketo at gmail.com> writes:

> 2009/12/8 Ludovic Courtès <ludo at gnu.org>:

[...]

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

> than having environment variables that may have any kind of side
> effect. The gcc build system involves building some internally used
> gcc versions, gcc libraries, ... and we only need to pass parameters
> to *some* of those programs/libraries built. Using environment
> variables like LIBRARY_PATH or CPATH will affect any internal or
> non-internal gcc call, either building for the build computer or the
> target computer (this later specially disabled any cross-compiler
> building).

[In the 4.4 Nix expression as is currently in trunk, $LIBRARY_PATH and
$CPATH are only used to pass to let GCC know about the location of the
glibc headers and crt*.o files (and for additional dependencies when
building gcj).]

IIUC, using these variables is inappropriate in the cross-compiler case
because both host and target headers/libraries end up being searched for
in these paths.

http://gcc.gnu.org/install/build.html reads:

  [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?

[...]

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42318 - libtool does not
> pass -B; we had a patch for this in the gcc 4.3 expression, and I
> added it back again for the gcc 4.4 expression

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 expression actually uses $LIBRARY_PATH instead of these variables.)

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

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

(BTW, zlib is only needed when building GCJ, as can be seen in the
expression in trunk.)

Thanks,
Ludo’.