all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Switching to GCC 4.8
@ 2013-11-01 14:40 Ludovic Courtès
  2013-11-16 14:23 ` Ludovic Courtès
  0 siblings, 1 reply; 3+ messages in thread
From: Ludovic Courtès @ 2013-11-01 14:40 UTC (permalink / raw)
  To: guix-devel

So we want to switch to GCC 4.8 as the default compiler.  I tried that
in ‘core-updates’, but ‘gcc-cross-boot0’ fails to build because some of
its helper programs built natively (‘genchecksum’, ‘gcc-nm’, etc.) rely
on C++ headers not provided by our current bootstrap GCC.  Some can be
easily worked around (e.g., replace <cstring> by <string.h>), but others
cannot (e.g., <iosfwd>.)

Thus, we’ll have to update the bootstrap GCC.

The good thing is that it will allow us to have same-version binaries
for x86_64/i686 and mips64el.  Perhaps we can achieve fixed-point while
we’re at it.

Ludo’.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Switching to GCC 4.8
  2013-11-01 14:40 Switching to GCC 4.8 Ludovic Courtès
@ 2013-11-16 14:23 ` Ludovic Courtès
  2013-11-17 23:34   ` Ludovic Courtès
  0 siblings, 1 reply; 3+ messages in thread
From: Ludovic Courtès @ 2013-11-16 14:23 UTC (permalink / raw)
  To: guix-devel

ludo@gnu.org (Ludovic Courtès) skribis:

> So we want to switch to GCC 4.8 as the default compiler.  I tried that
> in ‘core-updates’, but ‘gcc-cross-boot0’ fails to build because some of
> its helper programs built natively (‘genchecksum’, ‘gcc-nm’, etc.) rely
> on C++ headers not provided by our current bootstrap GCC.  Some can be
> easily worked around (e.g., replace <cstring> by <string.h>), but others
> cannot (e.g., <iosfwd>.)
>
> Thus, we’ll have to update the bootstrap GCC.

Done with commit 0621349.  This turned out to be trickier than expected,
due to the fact that C++ is now a requirement for GCC.

There’s still one problem though: the infamous “libgcc_s.so.1 must be
installed for pthread_cancel to work”, which breaks Guile.  We didn’t
have that problem before because libgc.so NEEDed libgcc_s.so; this is no
longer the case, for some reason.

What’s more, the guile RUNPATH contains ${gcc}/lib (where libgcc_s.so
is), but the dynamic linker ignores that entry:

--8<---------------cut here---------------start------------->8---
$ LD_DEBUG=libs ./check-guile threads.test
  [...]
     22551:	find library=libgcc_s.so.1 [0]; searching
     22551:	 search path=/tmp/nix-build-guile-2.0.9.drv-0/guile-2.0.9/libguile/.libs		(LD_LIBRARY_PATH)
     22551:	  trying file=/tmp/nix-build-guile-2.0.9.drv-0/guile-2.0.9/libguile/.libs/libgcc_s.so.1
     22551:	 search path=/nix/store/080d391y67nm362gr5fdnwlxymp3qwa2-libgc-7.2d/lib:/nix/store/c8g538vxnrmqfp1s4jd3axrkg9f76fsm-libffi-3.0.13/lib:/nix/store/8pmkh1fnm3an4dnilhi9nxn1mvfymi72-libunistring-0.9.3/lib:/nix/store/w08bzyqcwm9hs41wj2b6329rzswcwc5k-gmp-5.1.3/lib:/nix/store/9kwmx9f1by9na0lw83b4bj8mj5x567a2-libtool-2.4.2/lib		(RUNPATH from file /tmp/nix-build-guile-2.0.9.drv-0/guile-2.0.9/libguile/.libs/guile)
     22551:	  trying file=/nix/store/080d391y67nm362gr5fdnwlxymp3qwa2-libgc-7.2d/lib/libgcc_s.so.1
     22551:	  trying file=/nix/store/c8g538vxnrmqfp1s4jd3axrkg9f76fsm-libffi-3.0.13/lib/libgcc_s.so.1
     22551:	  trying file=/nix/store/8pmkh1fnm3an4dnilhi9nxn1mvfymi72-libunistring-0.9.3/lib/libgcc_s.so.1
     22551:	  trying file=/nix/store/w08bzyqcwm9hs41wj2b6329rzswcwc5k-gmp-5.1.3/lib/libgcc_s.so.1
     22551:	  trying file=/nix/store/9kwmx9f1by9na0lw83b4bj8mj5x567a2-libtool-2.4.2/lib/libgcc_s.so.1
     22551:	 search cache=/etc/etc/ld.so.cache
     22551:	 search path=/nix/store/j1nbq7prs34wd09yj5hmcnqr7krlacf4-glibc-2.18/lib		(system search path)
     22551:	  trying file=/nix/store/j1nbq7prs34wd09yj5hmcnqr7krlacf4-glibc-2.18/lib/libgcc_s.so.1
     22551:	
libgcc_s.so.1 must be installed for pthread_cancel to work
Aborted

$ objdump -x /tmp/nix-build-guile-2.0.9.drv-0/guile-2.0.9/libguile/.libs/guile | grep PATH
  RPATH                /nix/store/gki8sf345ymchq59j3y7r1nw8r3w636g-guile-2.0.9/lib:/nix/store/080d391y67nm362gr5fdnwlxymp3qwa2-libgc-7.2d/lib:/nix/store/c8g538vxnrmqfp1s4jd3axrkg9f76fsm-libffi-3.0.13/lib:/nix/store/8pmkh1fnm3an4dnilhi9nxn1mvfymi72-libunistring-0.9.3/lib:/nix/store/w08bzyqcwm9hs41wj2b6329rzswcwc5k-gmp-5.1.3/lib:/nix/store/9kwmx9f1by9na0lw83b4bj8mj5x567a2-libtool-2.4.2/lib:/nix/store/j1nbq7prs34wd09yj5hmcnqr7krlacf4-glibc-2.18/lib:/nix/store/i9x5nm2ff05n67f81zx7dswsq6bl7iaq-gcc-4.8.2/lib64:/nix/store/i9x5nm2ff05n67f81zx7dswsq6bl7iaq-gcc-4.8.2/lib
  RUNPATH              /nix/store/gki8sf345ymchq59j3y7r1nw8r3w636g-guile-2.0.9/lib:/nix/store/080d391y67nm362gr5fdnwlxymp3qwa2-libgc-7.2d/lib:/nix/store/c8g538vxnrmqfp1s4jd3axrkg9f76fsm-libffi-3.0.13/lib:/nix/store/8pmkh1fnm3an4dnilhi9nxn1mvfymi72-libunistring-0.9.3/lib:/nix/store/w08bzyqcwm9hs41wj2b6329rzswcwc5k-gmp-5.1.3/lib:/nix/store/9kwmx9f1by9na0lw83b4bj8mj5x567a2-libtool-2.4.2/lib:/nix/store/j1nbq7prs34wd09yj5hmcnqr7krlacf4-glibc-2.18/lib:/nix/store/i9x5nm2ff05n67f81zx7dswsq6bl7iaq-gcc-4.8.2/lib64:/nix/store/i9x5nm2ff05n67f81zx7dswsq6bl7iaq-gcc-4.8.2/lib
--8<---------------cut here---------------end--------------->8---

(Note that the “RUNPATH from file” debug statement doesn’t include
${glibc}/lib and ${gcc}/lib, although they do appear in the RUNPATH.)

I’m looking for a proper fix to that.

Nixpkgs has worked around it by adding an explicit -lgcc_s, but that
shouldn’t be needed.

> The good thing is that it will allow us to have same-version binaries
> for x86_64/i686 and mips64el.  Perhaps we can achieve fixed-point while
> we’re at it.

Not for this time yet, but I think we’re not far from it now.

Ludo’.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Switching to GCC 4.8
  2013-11-16 14:23 ` Ludovic Courtès
@ 2013-11-17 23:34   ` Ludovic Courtès
  0 siblings, 0 replies; 3+ messages in thread
From: Ludovic Courtès @ 2013-11-17 23:34 UTC (permalink / raw)
  To: guix-devel

ludo@gnu.org (Ludovic Courtès) skribis:

> There’s still one problem though: the infamous “libgcc_s.so.1 must be
> installed for pthread_cancel to work”, which breaks Guile.  We didn’t
> have that problem before because libgc.so NEEDed libgcc_s.so; this is no
> longer the case, for some reason.
>
> What’s more, the guile RUNPATH contains ${gcc}/lib (where libgcc_s.so
> is), but the dynamic linker ignores that entry:

After some more investigation I found an explanation:

  http://sourceware.org/ml/libc-help/2013-11/msg00026.html

We could tell glibc to consider $(gcc)/lib as one part of the “system
search path” (see $(user-defined-trusted-dirs) in $glibc/elf/Makefile).
However, that means glibc-final would hold a reference to gcc-boot0,
which is not what we want (and that’s the reason why glibc uses dlopen
in the first place.)

So commit 65d3b7c just changes GCC to always link against libgcc_s.so.
That’s not optimal, but not unreasonable either.

Ludo’.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-11-17 23:34 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-01 14:40 Switching to GCC 4.8 Ludovic Courtès
2013-11-16 14:23 ` Ludovic Courtès
2013-11-17 23:34   ` Ludovic Courtès

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.