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

2009/12/8 Ludovic Courtès <ludo at gnu.org>:
> Hi,
>
> Llus Batlle <viriketo at gmail.com> writes:
>
>> --- nixpkgs/branches/stdenv-updates/pkgs/development/compilers/gcc-4.4/libtool-glibc.patch                            (rev 0)
>> +++ nixpkgs/branches/stdenv-updates/pkgs/development/compilers/gcc-4.4/libtool-glibc.patch    2009-12-08 09:36:19 UTC (rev 18833)
>> @@ -0,0 +1,48 @@
>> +diff --git a/libgomp/configure b/libgomp/configure
>> +index deef673..9e4a790 100755
>> +--- a/libgomp/configure
>> ++++ b/libgomp/configure
>> +@@ -23848,6 +23848,11 @@ old_archive_cmds=$lt_old_archive_cmds
>> + # A language specific compiler.
>> + CC=$lt_compiler
>> +
>> ++# Ugly hack to get libmudflap (and other libraries) to build.
>> ++# Libtool filters out \`-B' flags when linking (why?), so the \`-B' flag
>> ++# to Glibc gets lost.  Here we forcibly add it to any invocation.
>> ++CC="\$CC $NIX_EXTRA_CFLAGS_TARGET $NIX_EXTRA_LDFLAGS_TARGET"
>> ++
>
> 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). :)
>
> 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, 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).

We could try to push the "-B should pass libtool" change into gcc, so
we don't need the 'Ugly hack'. I think libtool not passing -B on
linking is uglier, by their side. :)

>
> I’m not offering any fix here, as I don’t want to spend time working on
> cross-compilation, but I’d really love it if we could sit back and make
> sure no kosher way exists to achieve what we want.
I think that setting LIBRARY_PATH and CPATH worked a bit by chance,
instead of using any patch or make variable to pass the flags we want
in the places we want.
The uglier part is the NIX_EXTRA environment variables needed for the
target libraries libtool to consider the -B..., which I hope some day
the gcc people will fix. Any nixer knowing libtool well enough could
try to send a patch. I spend quite enough time reading the libtool
script (it took me two days to realize that nixers fixed this with a
patch in the gcc-4.3 expression), and I understand how -B flags are
ignored, but I don't know libtool enough to fix it in a way other than
a hard patch to the libtool scripts, maybe making them aware of -B
when adding the CFLAGS/LDFLAGS to the linking command.

>
> Can you please re-send the GCC bug reports you made and perhaps a
> summary of the approaches you tried?
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

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)

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.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42300 - having
LIBRARY_PATH set but with null contents has the same effect as
LIBRARY_PATH=.  This breaks a cross-built, because an internal
gcc-for-native creates a './specs' file dumping its specs, and a later
gcc-for-target call from the same directory reads those specs thought
for the native system, breaking a cross-building. The null
LIBRARY_PATH comes from getting it assigned conditionally as a
derivation attribute (some gcj rules by ludo), and I have to unset
LIBRARY_PATH and CPATH at all by now to get cross-builds working (done
in the actual gcc-4.4 expression). The bug report says that the
'./specs' file is not created anymore by default in the actual gcc svn
tree, but I have not checked that. So for cross builds we could not
simply have a void LIBRARY_PATH, but we had to have it unset.

Regards,
Lluís.