From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: Problem with natively-built armhf bootstrap compiler Date: Thu, 01 Jan 2015 21:19:32 -0500 Message-ID: <8761cp6i17.fsf@netris.org> References: <87lhln7mlk.fsf@netris.org> <87a9225o3z.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44934) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y6rpS-0003dO-8q for guix-devel@gnu.org; Thu, 01 Jan 2015 21:19:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y6rpP-0006K8-2R for guix-devel@gnu.org; Thu, 01 Jan 2015 21:19:06 -0500 Received: from world.peace.net ([50.252.239.5]:60805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y6rpO-0006K0-Ue for guix-devel@gnu.org; Thu, 01 Jan 2015 21:19:02 -0500 In-Reply-To: <87a9225o3z.fsf@netris.org> (Mark H. Weaver's message of "Thu, 01 Jan 2015 13:53:36 -0500") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: guix-devel@gnu.org Mark H Weaver 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 ;; .) (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