Preliminary 'wip-armhf' branch pushed

Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

Hello Guix,

I've pushed a new branch 'wip-armhf' (not to be confused with 'wip-arm')
which seems likely to finish natively building bootstrap tarballs soon.
It is based on the 'core-updates' branch.

I chose system name "armhf-linux", GNU triplet "arm-linux-gnueabihf",
and the following GCC configure flags:

   --with-arch=armv7-a
   --with-float=hard
   --with-mode=thumb
   --with-fpu=vfpv3-d16

I believe this coincides with what Debian does for their 'armhf' port.

This branch is *not* ready for use.  For one thing, the current
bootstrap tarballs are cross-compiled, and we should wait for the
natively-compiled ones.

The branch is for review.  Comments and suggestions solicited!

      Mark

Re: Preliminary 'wip-armhf' branch pushed

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]

It would seem then, that the only difference between the wip-arm and the wip-armhf
branches is the value of the --with-fpu flag.

I'm not an ARM expert, so I don't know how important that setting is.  But I do know
that there are many different fpus - if we are going to have a new branch for every combination
of flags then there are going to be rather a lot of branches.

We need to find a better solution.

J'

On Wed, Dec 31, 2014 at 12:31:03PM -0500, Mark H Weaver wrote:
     Hello Guix,
     
     I've pushed a new branch 'wip-armhf' (not to be confused with 'wip-arm')
     which seems likely to finish natively building bootstrap tarballs soon.
     It is based on the 'core-updates' branch.
     
     I chose system name "armhf-linux", GNU triplet "arm-linux-gnueabihf",
     and the following GCC configure flags:
     
        --with-arch=armv7-a
        --with-float=hard
        --with-mode=thumb
        --with-fpu=vfpv3-d16
     
     I believe this coincides with what Debian does for their 'armhf' port.
     
     This branch is *not* ready for use.  For one thing, the current
     bootstrap tarballs are cross-compiled, and we should wait for the
     natively-compiled ones.
     
     The branch is for review.  Comments and suggestions solicited!
     
           Mark

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

Hi John,

John Darrington <john@darrington.wattle.id.au> writes:
> It would seem then, that the only difference between the wip-arm and
> the wip-armhf branches is the value of the --with-fpu flag.

That is not even close to the truth, as anyone who actually looks at the
branches (or tries to build them) can easily see.  John, I appreciate
your preliminary work on 'wip-arm', and I credited you in the final
patch on 'wip-armhf', but you didn't get very far.

> I'm not an ARM expert, so I don't know how important that setting is.

I assuming that the Debian armhf developers are far more knowledgeable
than either of us, so I followed their lead.  There is some discussion
here:

  https://wiki.debian.org/ArmHardFloatPort
  https://wiki.debian.org/ArmHardFloatPort/VfpComparison

> But I do know that there are many different fpus - if we are going to
> have a new branch for every combination of flags then there are going
> to be rather a lot of branches.

First of all, the branch is temporary.  Like mips64el before it, this
branch will be merged into 'core-updates' and 'master' when it's ready.

I don't think we need a 'system' for every combination of flags.  We
should just find a small number of "sweet spots" in the tradeoff between
minimum requirements vs performance.  IMO, for 32-bit ARM, two systems
should be enough: armhf, and maybe another one (armel?) that works on
lower-end processors.

Other opinions?

     Mark

Re: Preliminary 'wip-armhf' branch pushed

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

On Wed, Dec 31, 2014 at 02:23:30PM -0500, Mark H Weaver wrote:
     
     John Darrington <john@darrington.wattle.id.au> writes:
     > It would seem then, that the only difference between the wip-arm and
     > the wip-armhf branches is the value of the --with-fpu flag.
     
     That is not even close to the truth, as anyone who actually looks at the
     branches (or tries to build them) can easily see.  John, I appreciate
     your preliminary work on 'wip-arm', and I credited you in the final
     patch on 'wip-armhf', but you didn't get very far.

No I didn't.   I didn't think it worth even creating a branch, but civodul asked me to.
So I was surprised and disappointed that nobody wanted to help take it further.

You said your branch also wasn't ready, that's why I haven't tried to build it.
From your description, I wasn't clear what your branch achieves that my attempt
doesn't.
     
J'


-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

Hi John,

John Darrington <john@darrington.wattle.id.au> writes:

> On Wed, Dec 31, 2014 at 02:23:30PM -0500, Mark H Weaver wrote:
>      
>      John Darrington <john@darrington.wattle.id.au> writes:
>      > It would seem then, that the only difference between the wip-arm and
>      > the wip-armhf branches is the value of the --with-fpu flag.
>      
>      That is not even close to the truth, as anyone who actually looks at the
>      branches (or tries to build them) can easily see.  John, I appreciate
>      your preliminary work on 'wip-arm', and I credited you in the final
>      patch on 'wip-armhf', but you didn't get very far.
>
> No I didn't.   I didn't think it worth even creating a branch, but civodul asked me to.
> So I was surprised and disappointed that nobody wanted to help take it further.

Initially, I hoped to build upon your branch instead of starting a new
one.  However, when I took a close look, I found that there was not a
single hunk of your initial commit (0386b83a2) that I could use:

* You called the system 'armel-linux', but I preferred to save that name
  for a possible soft-float system analogous to Debian's 'armel' port.

* You used the triplet 'armel-linux-gnueabihf'.  I tried that, but found
  that a great many copies of 'config.sub' in the wild fail to recognize
  'armel' as the machine name when there is also a company name in the
  triplet.  After a few experiments with other triplets, I settled on
  'arm-linux-gnueabihf', which is what Debian uses.

* You chose higher FPU requirements than Debian, and tuned compiles for
  cortex-a9.  I'm open to discussing these choices, but without careful
  research I'd be more inclined to follow Debian's lead.

* You added "CFLAGS=-Wno-cast-qual" and "--disable-werror" for ARM in
  'gcc-configure-flags-for-triplet', which I thought was a bad idea and
  didn't belong there.

* You patched gcc/config/arm/linux-eabi.h unnecessarily.

Given that every piece of your foundation needed modification, it didn't
seem to make sense to build on it.

> You said your branch also wasn't ready, that's why I haven't tried to
> build it.  From your description, I wasn't clear what your branch
> achieves that my attempt doesn't.

'wip-armhf' is well on its way to building native bootstrap tarballs on
my Novena board.  Given the many problems in the early bootstrap that I
had to fix along the way, it is clear that 'wip-arm' in it's current
state wouldn't get very far.

       Mark

Re: Preliminary 'wip-armhf' branch pushed

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

On Wed, Dec 31, 2014 at 06:40:23PM -0500, Mark H Weaver wrote:
     
     * You added "CFLAGS=-Wno-cast-qual" and "--disable-werror" for ARM in
       'gcc-configure-flags-for-triplet', which I thought was a bad idea and
       didn't belong there.

Have you tried actually building GCC ?  I found that without those, it failed to build.
     
     * You patched gcc/config/arm/linux-eabi.h unnecessarily.

Without that patch, GCC actually builds soft-float code, even though you may have passed 
the --with-float=hard flag.  What bits of that patch do you think are not necessary?
If you have reverted it, then I suspect you are actually have a soft-float achitecture
which you erroneously believe to be hard float.     (I went down that path before 
civodul pointed out this needed to be patched).  This would explain your earlier
 comments about soft vs. hard float.

J'


-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

John Darrington <john@darrington.wattle.id.au> writes:

> On Wed, Dec 31, 2014 at 06:40:23PM -0500, Mark H Weaver wrote:
>      
>      * You added "CFLAGS=-Wno-cast-qual" and "--disable-werror" for ARM in
>        'gcc-configure-flags-for-triplet', which I thought was a bad idea and
>        didn't belong there.
>
> Have you tried actually building GCC ?

Yes, I've built several GCCs including gcc-final.  I've also
successfully built the 'hello' package.

> I found that without those, it failed to build.

Perhaps the problem you ran into was fixed in GCC 4.8.4.

>      * You patched gcc/config/arm/linux-eabi.h unnecessarily.
>
> Without that patch, GCC actually builds soft-float code, even though
> you may have passed the --with-float=hard flag.  What bits of that
> patch do you think are not necessary?

All of it seems to be unnecessary, by experiment.  I've used the
resulting GCC to compile the following test program:

--8<---------------cut here---------------start------------->8---
#include <math.h>

double foo (double a, double b)
{
  return sinh(a * b);
}
--8<---------------cut here---------------end--------------->8---

Compiled with "/gnu/store/.../bin/gcc -O2 -S foo.c", here's the
resulting foo.s:

--8<---------------cut here---------------start------------->8---
	.syntax unified
	.arch armv7-a
	.eabi_attribute 27, 3
	.eabi_attribute 28, 1
	.fpu vfpv3-d16
	.eabi_attribute 20, 1
	.eabi_attribute 21, 1
	.eabi_attribute 23, 3
	.eabi_attribute 24, 1
	.eabi_attribute 25, 1
	.eabi_attribute 26, 2
	.eabi_attribute 30, 2
	.eabi_attribute 34, 1
	.eabi_attribute 18, 4
	.thumb
	.file	"foo.c"
	.text
	.align	2
	.global	foo
	.thumb
	.thumb_func
	.type	foo, %function
foo:
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 0, uses_anonymous_args = 0
	@ link register save eliminated.
	fmuld	d0, d0, d1
	b	sinh
	.size	foo, .-foo
	.ident	"GCC: (GNU) 4.8.4"
	.section	.note.GNU-stack,"",%progbits
--8<---------------cut here---------------end--------------->8---

'foo' accepts the double arguments via registers and passes a double to
sinh via registers.  I also checked a variant that simply returned a*b,
and it was clearly returning the result via register as well.

I think it's quite clear that this is using the hard-float ABI, no?

      Mark

Re: Preliminary 'wip-armhf' branch pushed

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

On Thu, Jan 01, 2015 at 02:11:19AM -0500, Mark H Weaver wrote:
     John Darrington <john@darrington.wattle.id.au> writes:
     
     > On Wed, Dec 31, 2014 at 06:40:23PM -0500, Mark H Weaver wrote:
     >      
     >      * You added "CFLAGS=-Wno-cast-qual" and "--disable-werror" for ARM in
     >        'gcc-configure-flags-for-triplet', which I thought was a bad idea and
     >        didn't belong there.
     >
     > Have you tried actually building GCC ?
     
     Yes, I've built several GCCs including gcc-final.  I've also
     successfully built the 'hello' package.
     
     > I found that without those, it failed to build.
     
     Perhaps the problem you ran into was fixed in GCC 4.8.4.

Yeah possibly. 
     
     >      * You patched gcc/config/arm/linux-eabi.h unnecessarily.
     >
     > Without that patch, GCC actually builds soft-float code, even though
     > you may have passed the --with-float=hard flag.  What bits of that
     > patch do you think are not necessary?
     
     All of it seems to be unnecessary, by experiment.  I've used the
     resulting GCC to compile the following test program:
     
     'foo' accepts the double arguments via registers and passes a double to
     sinh via registers.  I also checked a variant that simply returned a*b,
     and it was clearly returning the result via register as well.
     
     I think it's quite clear that this is using the hard-float ABI, no?

My results showed that simple binaries like that compiled (and ran) ok.  The problems arose when linking with
bigger projects.  I don't recall the details.  Have you tried building libc?  I suspect that is where the patch
will be needed.

J'


-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

John Darrington <john@darrington.wattle.id.au> writes:

> On Thu, Jan 01, 2015 at 02:11:19AM -0500, Mark H Weaver wrote:
>      John Darrington <john@darrington.wattle.id.au> writes:
>      
>      >      * You patched gcc/config/arm/linux-eabi.h unnecessarily.
>      >
>      > Without that patch, GCC actually builds soft-float code, even though
>      > you may have passed the --with-float=hard flag.  What bits of that
>      > patch do you think are not necessary?
>      
>      All of it seems to be unnecessary, by experiment.  I've used the
>      resulting GCC to compile the following test program:
>      
>      'foo' accepts the double arguments via registers and passes a double to
>      sinh via registers.  I also checked a variant that simply returned a*b,
>      and it was clearly returning the result via register as well.
>      
>      I think it's quite clear that this is using the hard-float ABI, no?
>
> My results showed that simple binaries like that compiled (and ran)
> ok.  The problems arose when linking with bigger projects.  I don't
> recall the details.  Have you tried building libc?

Yes, of course.  I looked further into this, and discovered that the
reason it all works is that the main 'gcc' driver arranges to pass
"-mfloat-abi=hard" (and several others) to 'cc1' and 'as'.

      Mark

Re: Preliminary 'wip-armhf' branch pushed

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]

On Thu, Jan 01, 2015 at 01:22:53PM -0500, Mark H Weaver wrote:
     John Darrington <john@darrington.wattle.id.au> writes:
     
     > On Thu, Jan 01, 2015 at 02:11:19AM -0500, Mark H Weaver wrote:
     >      John Darrington <john@darrington.wattle.id.au> writes:
     >      
     >      >      * You patched gcc/config/arm/linux-eabi.h unnecessarily.
     >      >
     >      > Without that patch, GCC actually builds soft-float code, even though
     >      > you may have passed the --with-float=hard flag.  What bits of that
     >      > patch do you think are not necessary?
     >      
     >      All of it seems to be unnecessary, by experiment.  I've used the
     >      resulting GCC to compile the following test program:
     >      
     >      'foo' accepts the double arguments via registers and passes a double to
     >      sinh via registers.  I also checked a variant that simply returned a*b,
     >      and it was clearly returning the result via register as well.
     >      
     >      I think it's quite clear that this is using the hard-float ABI, no?
     >
     > My results showed that simple binaries like that compiled (and ran)
     > ok.  The problems arose when linking with bigger projects.  I don't
     > recall the details.  Have you tried building libc?
     
     Yes, of course.  I looked further into this, and discovered that the
     reason it all works is that the main 'gcc' driver arranges to pass
     "-mfloat-abi=hard" (and several others) to 'cc1' and 'as'.
     
Ok.  Right now, I don't remember exactly at what point I discovered the linux-eabi.h
changes were necessary, but they were indeed necessary - I didn't do it for fun!
I expect you will find out in due course.

J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Preliminary 'wip-armhf' branch pushed

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> I don't think we need a 'system' for every combination of flags.  We
> should just find a small number of "sweet spots" in the tradeoff between
> minimum requirements vs performance.  IMO, for 32-bit ARM, two systems
> should be enough: armhf, and maybe another one (armel?) that works on
> lower-end processors.

It’s not even clear that “hf” needs to be part of the system name.

In theory, the bootstrap tarballs could be soft-float, which means they
would run everywhere, and from there users could choose what
--with-float and --with-fpu flags to use.

OTOH, changing the system name makes it much easier to refer to a
specific variant.

Ludo’.

Re: Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

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

> Mark H Weaver <mhw@netris.org> skribis:
>
>> I don't think we need a 'system' for every combination of flags.  We
>> should just find a small number of "sweet spots" in the tradeoff between
>> minimum requirements vs performance.  IMO, for 32-bit ARM, two systems
>> should be enough: armhf, and maybe another one (armel?) that works on
>> lower-end processors.
>
> It’s not even clear that “hf” needs to be part of the system name.

I think it needs to be part of the system name, because on ARM these are
two incompatible ABIs.  Among other things, the hard-float ABI passes
floating point arguments in registers.

> In theory, the bootstrap tarballs could be soft-float, which means they
> would run everywhere, and from there users could choose what
> --with-float and --with-fpu flags to use.

A single GCC can generate code for both ABIs, but each ABI uses its own
dynamic linker.  If we did as you suggest, we'd need two separate
bootstrap glibc's, and improve the dynamic-linker-name patching code in
our gcc package to rewrite the two dynamic linker names separately, etc.

     Thanks,
       Mark

Re: Preliminary 'wip-armhf' branch pushed

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> I don't think we need a 'system' for every combination of flags.  We
>>> should just find a small number of "sweet spots" in the tradeoff between
>>> minimum requirements vs performance.  IMO, for 32-bit ARM, two systems
>>> should be enough: armhf, and maybe another one (armel?) that works on
>>> lower-end processors.
>>
>> It’s not even clear that “hf” needs to be part of the system name.
>
> I think it needs to be part of the system name, because on ARM these are
> two incompatible ABIs.  Among other things, the hard-float ABI passes
> floating point arguments in registers.
>
>> In theory, the bootstrap tarballs could be soft-float, which means they
>> would run everywhere, and from there users could choose what
>> --with-float and --with-fpu flags to use.
>
> A single GCC can generate code for both ABIs, but each ABI uses its own
> dynamic linker.  If we did as you suggest, we'd need two separate
> bootstrap glibc's, and improve the dynamic-linker-name patching code in
> our gcc package to rewrite the two dynamic linker names separately, etc.

Very good points, I had overlooked this.

Thanks,
Ludo’.

Re: Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:

> I've pushed a new branch 'wip-armhf' (not to be confused with 'wip-arm')
> which seems likely to finish natively building bootstrap tarballs soon.
> It is based on the 'core-updates' branch.

I believe that my cross-compiled bootstrap tarballs are bad and have to
be rebuilt.  Despite passing both --target=arm-linux-gnueabihf and
--with-float=hard to GCC's configure, I believe that GCC was using the
soft-float ABI for ARM by default.  This is especially bad given that
our dynamic linker has a name that indicates the hard-float ABI.

For now, I've pushed another commit to the 'wip-armhf' branch that will
hopefully make it *cross-build* armhf bootstrap tarballs properly, but
it is not yet suitable for building on an arm box because it refers to
the existing (bad) bootstrap tarballs.

I'll post an update when this issue is resolved.

      Mark

Re: Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> I've pushed a new branch 'wip-armhf' (not to be confused with 'wip-arm')
>> which seems likely to finish natively building bootstrap tarballs soon.
>> It is based on the 'core-updates' branch.
>
> I believe that my cross-compiled bootstrap tarballs are bad and have to
> be rebuilt.  Despite passing both --target=arm-linux-gnueabihf and
> --with-float=hard to GCC's configure, I believe that GCC was using the
> soft-float ABI for ARM by default.

False alarm.  Looking at the source code of gcc/config/arm/linux-eabi.h
and seeing a patch in Debian made me think that we needed a patch in
order to make this work, but testing indicates that the hard-float ABI
is being used by GCC by default without any patches.

So, nevermind :)

      Mark

Problem with natively-built armhf bootstrap compiler

[Mark H Weaver]

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 seems that libgcc_s.so does not exist in any of our bootstrap
tarballs, so I guess that's intentional.  However, for some reason this
new bootstrap gcc is trying to link to it.

I've done a careful comparison of the output of "gcc -v bare-test.c"
between the old (cross-compiled) and new (native-compiled) bootstrap
tarballs.  bare-test.c contains only an empty main() function.  These
tests are run outside of the guix-daemon but using only the environment
variables set in the 'make-boot0' build.  Here are the non-trivial
differences:

* The GNU triplet is different.  The old (working) cross-compiled ones
  use "arm-linux-gnueabihf", but the new (broken) ones use
  "armv7l-unknown-linux-gnueabihf", the result of 'config.guess'.

* The LIBRARY_PATHs printed by "gcc -v" before running 'collect2' are
  different.  The old (working) cross-compiled one includes
  ":/lib/:/usr/lib/" at the end, whereas the new (broken) one includes
  only directories from /gnu/store.

* There are several differences in the call to 'collect2':

   * The old (working) cross-compiled one passes "-dynamic-linker
     /lib/ld-linux-armhf.so.3" early in the command line, whereas the
     new (broken) one passes "-dynamic-linker
     /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.20/lib/ld-linux-armhf.so.3".

     However, both of them pass a second -dynamic-linker argument that
     points to /gnu/store/*-glibc-bootstrap-0//lib/ld-linux-armhf.so.3
     which seems to be correct.

   * 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"

Obviously, that last -lgcc_s is what's causing problems here.
Any idea what's causing this, or how to fix it?

      Mark

Re: Problem with natively-built armhf bootstrap compiler

[Mark H Weaver]

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

Re: Problem with natively-built armhf bootstrap compiler

[Mark H Weaver]

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.

[...]

> 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.

For now, this is the approach I took, in commit 5336e4c74.

      Mark

Re: Problem with natively-built armhf bootstrap compiler

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

Mark H Weaver <mhw@netris.org> skribis:

> 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.
>
> [...]
>
>> 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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 844 bytes --]

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\"

[-- Attachment #3: Type: text/plain, Size: 165 bytes --]


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’.

Re: Problem with natively-built armhf bootstrap compiler

[Mark H Weaver]

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

> Mark H Weaver <mhw@netris.org> skribis:
>
>> Mark H Weaver <mhw@netris.org> writes:
>>
>>> 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:
>
> 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\"
>
> I believe this is enough to address what the comment mentions (glibc
> dlopening libgcc_s for pthread functions), but this will need testing.
>
> WDYT?

I confess I don't know enough about the relevant details to know whether
this would work reliably -- e.g. will -pthread always be passed to gcc
at link time whenever this problem would arise? -- but it certainly
looks like a cleaner solution in principle.

I'm glad to defer to your judgement on how best to fix this :)

   Thanks!
     Mark

Re: Problem with natively-built armhf bootstrap compiler

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

>> 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\"
>>
>> I believe this is enough to address what the comment mentions (glibc
>> dlopening libgcc_s for pthread functions), but this will need testing.

I see you applied this patch.  However, after grepping through libc, I
found there are other cases where libgcc_s is dlopened, including to
walk the stack, which has nothing to do with pthread.

So I think the status quo is safer.

WDYT?

Ludo’, who hopes gnu.org will be back soon.

Re: Problem with natively-built armhf bootstrap compiler

[Mark H Weaver]

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

> Mark H Weaver <mhw@netris.org> skribis:
>
>>> 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\"
>>>
>>> I believe this is enough to address what the comment mentions (glibc
>>> dlopening libgcc_s for pthread functions), but this will need testing.
>
> I see you applied this patch.  However, after grepping through libc, I
> found there are other cases where libgcc_s is dlopened, including to
> walk the stack, which has nothing to do with pthread.
>
> So I think the status quo is safer.
>
> WDYT?

Okay, sounds good to me.  I also discovered that tcl doesn't pass
-pthread on GNU/Linux by default, but only -lpthread.

I've reverted the patch above and will soon post another patch which
implements my original workaround and worked well in practice.

     Thanks,
       Mark

[PATCH] gnu: gcc-static: Remove -lgcc_s from GNU_USER_TARGET_LIB_SPEC

[Mark H Weaver]

[-- Attachment #1: Type: text/plain, Size: 273 bytes --]

Here's my proposed patch to fix our generated bootstrap gcc to not try
to link with the nonexistent -lgcc_s.  I used this to create the current
set of 'armhf-linux' bootstrap tarballs and to bootstrap my initial
system (including 'emacs').

What do you think?

      Mark


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: [PATCH] gnu: gcc-static: Remove -lgcc_s from GNU_USER_TARGET_LIB_SPEC --]
[-- Type: text/x-patch, Size: 2848 bytes --]

From 108a59f3b2ec5d3551c54d5f713a7ed34171acb3 Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw@netris.org>
Date: Thu, 1 Jan 2015 22:53:55 -0500
Subject: [PATCH] gnu: gcc-static: Remove -lgcc_s from GNU_USER_TARGET_LIB_SPEC.

* gnu/packages/make-bootstrap.scm (%gcc-static): Add 'remove-lgcc_s
  phase.
* gnu/packages/gcc.scm (gcc-4.7): Add comment.
---
 gnu/packages/gcc.scm            |  5 +++++
 gnu/packages/make-bootstrap.scm | 14 +++++++++++++-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index a510af4..02de128 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -207,6 +207,11 @@ where the OS part is overloaded to denote a specific ABI---into GCC
                    ;; 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>.)
+                   ;;
+                   ;; NOTE: The '-lgcc_s' added below needs to be removed in a
+                   ;; later phase of %gcc-static.  If you change the string
+                   ;; 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"
                            libc libc libdir libdir suffix))
diff --git a/gnu/packages/make-bootstrap.scm b/gnu/packages/make-bootstrap.scm
index f6ef2e3..88fad0e 100644
--- a/gnu/packages/make-bootstrap.scm
+++ b/gnu/packages/make-bootstrap.scm
@@ -430,7 +430,19 @@ for `sh' in $PATH, and without nscd, and with static NSS modules."
                        "--disable-libquadmath"
                        "--disable-decimal-float")
                       (remove (cut string-match "--(.*plugin|enable-languages)" <>)
-                              ,flags))))))
+                              ,flags)))
+            ((#:phases phases)
+             `(alist-cons-after
+               'pre-configure 'remove-lgcc_s
+               (lambda _
+                 ;; Remove the '-lgcc_s' added to GNU_USER_TARGET_LIB_SPEC in
+                 ;; the 'pre-configure phase of our main gcc package, because
+                 ;; that shared library is not present in this static gcc.  See
+                 ;; <https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00008.html>.
+                 (substitute* (find-files "gcc/config"
+                                          "^gnu-user.*\\.h$")
+                   ((" -lgcc_s}}") "}}")))
+               ,phases)))))
      (native-inputs
       (if (%current-target-system)
           `(;; When doing a Canadian cross, we need GMP/MPFR/MPC both
-- 
2.1.2

Re: [PATCH] gnu: gcc-static: Remove -lgcc_s from GNU_USER_TARGET_LIB_SPEC

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> Here's my proposed patch to fix our generated bootstrap gcc to not try
> to link with the nonexistent -lgcc_s.  I used this to create the current
> set of 'armhf-linux' bootstrap tarballs and to bootstrap my initial
> system (including 'emacs').
>
> What do you think?

I looks like the right thing to do at the moment.  Can you apply it to
core-updates?

I’ll look at the other patches from wip-armhf that we can include.

Thanks,
Ludo’.

Re: Preliminary 'wip-armhf' branch pushed

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> I've pushed a new branch 'wip-armhf' (not to be confused with 'wip-arm')
> which seems likely to finish natively building bootstrap tarballs soon.
> It is based on the 'core-updates' branch.

Cool!

> I chose system name "armhf-linux", GNU triplet "arm-linux-gnueabihf",
> and the following GCC configure flags:
>
>    --with-arch=armv7-a
>    --with-float=hard
>    --with-mode=thumb
>    --with-fpu=vfpv3-d16

Does it mean that GCC generates Thumb code by default?

Thanks,
Ludo’.

Re: Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

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

> Mark H Weaver <mhw@netris.org> skribis:
>
>> I chose system name "armhf-linux", GNU triplet "arm-linux-gnueabihf",
>> and the following GCC configure flags:
>>
>>    --with-arch=armv7-a
>>    --with-float=hard
>>    --with-mode=thumb
>>    --with-fpu=vfpv3-d16
>
> Does it mean that GCC generates Thumb code by default?

Yes.  I confess that I'm not sufficiently knowledgeable about ARM to
understand the tradeoffs here, and have simply followed Debian's lead.
There is some rationale here:

  https://wiki.debian.org/ArmHardFloatPort

There, it says:

  Thumb-2/ThumbEE: Thumb-2 provides code size improvements and unlike
  thumb(1) there is no interworking overhead except in a few corner
  cases. Also Thumb-2 is sufficiently complete that there is no need to
  fall back to ARM ISA for some operations (unlike thumb1). Thus
  defaulting to Thumb-2 on v7 or later makes sense.

I haven't yet verified that our GCC is generating Thumb-2 instructions
(as opposed to Thumb-1).  Debian's GCC apparently does, but they apply a
rather large patch from Linaro.  This should be checked at some point.

Anyway, here are some more links that might be worth looking at if we
run into build problems:

  https://wiki.ubuntu.com/ARM/Thumb2
  https://wiki.ubuntu.com/ARM/Thumb2PortingHowto

    Regards,
      Mark