Mark H Weaver <m...@netris.org> writes:
> I was able to natively build bootstrap tarballs on the Novena. However,
> the compiler in these new bootstrap tarballs is broken. The problem is
> that the new compiler driver (gcc) passes -lgcc_s when linking, but
> libgcc_s.so does not exist in the gcc bootstrap tarball.
[...]
> * The new (broken) one passes the following extra flags to 'collect2':
> "-L/gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.20/lib
> -rpath=/gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.20/lib
> -rpath=/gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-gcc-static-4.8.4/lib64
> -rpath=/gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-gcc-static-4.8.4/lib
> -lgcc_s"
These new flags directly correspond to the modification we make to
GNU_USER_TARGET_LIB_SPEC in the pre-configure phase of our gcc-4.7
package in gcc.scm (and inherited by our other gcc packages):
--8<---------------cut here---------------start------------->8---
;; Tell where to find libstdc++, libc, and `?crt*.o', except
;; `crt{begin,end}.o', which come with GCC.
(substitute* (find-files "gcc/config"
"^gnu-user.*\\.h$")
(("#define GNU_USER_TARGET_LIB_SPEC (.*)$" _ suffix)
;; Help libgcc_s.so be found (see also below.) Always use
;; '-lgcc_s' so that libgcc_s.so is always found by those
;; programs that use 'pthread_cancel' (glibc dlopens
;; libgcc_s.so when pthread_cancel support is needed, but
;; having it in the application's RUNPATH isn't enough; see
;;
<http://sourceware.org/ml/libc-help/2013-11/msg00023.html>.)
(format #f "#define GNU_USER_TARGET_LIB_SPEC \
\"-L~a/lib %{!static:-rpath=~a/lib %{!static-libgcc:-rpath=~a/lib64
-rpath=~a/lib -lgcc_s}} \" ~a"
libc libc libdir libdir suffix))
--8<---------------cut here---------------end--------------->8---
It turns out that the "-lgcc_s" above was added just a few days after
we generated our last set of bootstrap tarballs, in commit a7bf595ff.
I guess that ever since that commit, any natively-built bootstrap
tarballs we generated for any platform would have created a broken
compiler, and that this is the first time we've tried since then.
Any suggestions on how best to fix this? My first crude idea is to
simply remove the "-lgcc_s" from %gcc-static. Thoughts?
Mark
