From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Problem with natively-built armhf bootstrap compiler Date: Fri, 02 Jan 2015 22:06:26 +0100 Message-ID: <87k314gael.fsf@gnu.org> References: <87lhln7mlk.fsf@netris.org> <87a9225o3z.fsf@netris.org> <8761cp6i17.fsf@netris.org> <871tnd6as5.fsf@netris.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y79QT-00074A-Ro for guix-devel@gnu.org; Fri, 02 Jan 2015 16:06:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y79QP-0006uS-Qf for guix-devel@gnu.org; Fri, 02 Jan 2015 16:06:29 -0500 Received: from hera.aquilenet.fr ([2a01:474::1]:52667) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y79QP-0006uI-JC for guix-devel@gnu.org; Fri, 02 Jan 2015 16:06:25 -0500 In-Reply-To: <871tnd6as5.fsf@netris.org> (Mark H. Weaver's message of "Thu, 01 Jan 2015 23:56:10 -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: Mark H Weaver Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain Mark H Weaver skribis: > 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. > > [...] > >> 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. Doh! >> Any suggestions on how best to fix this? My first crude idea is to >> simply remove the "-lgcc_s" from %gcc-static. > > For now, this is the approach I took, in commit 5336e4c74. Sounds good. I was tempting to do something like this: --=-=-= Content-Type: text/x-patch Content-Disposition: inline diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm index a7156bf..dd33a26 100644 --- a/gnu/packages/gcc.scm +++ b/gnu/packages/gcc.scm @@ -213,7 +213,7 @@ where the OS part is overloaded to denote a specific ABI---into GCC ;; below, make sure to update the relevant code in ;; %gcc-static package as needed. (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" +\"-L~a/lib %{!static:-rpath=~a/lib %{!static-libgcc:-rpath=~a/lib64 -rpath=~a/lib %{pthread: -lgcc_s}}} \" ~a" libc libc libdir libdir suffix)) (("#define GNU_USER_TARGET_STARTFILE_SPEC.*$" line) (format #f "#define STANDARD_STARTFILE_PREFIX_1 \"~a/lib\" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I believe this is enough to address what the comment mentions (glibc dlopening libgcc_s for pthread functions), but this will need testing. WDYT? Ludo=E2=80=99. --=-=-=--