Re: Problem with natively-built armhf bootstrap compiler

[Mark H Weaver <mhw@netris.org>]

Mark H Weaver <mhw@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