From dahalls at gmail.com  Sat Nov  1 22:03:51 2014
From: dahalls at gmail.com (David Halls)
Date: Sat, 1 Nov 2014 22:03:51 +0000
Subject: [Aboriginal] Aboriginal post from dahalls@gmail.com requires
	approval
In-Reply-To: <544EF7F8.5050404@landley.net>
References: <mailman.2593.1414404988.12509.aboriginal-landley.net@lists.landley.net>
	<544E4FCF.1040704@landley.net>
	<CABX1NxEknX5No_OrSz7c36t+tvYzYOdFq=6TL2bHOzJoDpcp5g@mail.gmail.com>
	<544EF7F8.5050404@landley.net>
Message-ID: <CABX1NxHNYA4HBiJGykSUNDX=vjXTTp2_qH7Roj0nGvgsVNYVDA@mail.gmail.com>

Thanks Rob.

Regarding the TLS problem, I added:

    UCLIBC_HAS_TLS=y

to baseconfig-uClibc but am still getting:

    Program uses unsupported TLS data!

It seems the code in ldso.c which does this checks for USE_TLS, which
should be set because native threads are configured, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20141101/dd0b1291/attachment.htm>

From rob at landley.net  Sat Nov  1 23:54:20 2014
From: rob at landley.net (Rob Landley)
Date: Sat, 01 Nov 2014 18:54:20 -0500
Subject: [Aboriginal] Aboriginal post from dahalls@gmail.com requires
	approval
In-Reply-To: <CABX1NxHNYA4HBiJGykSUNDX=vjXTTp2_qH7Roj0nGvgsVNYVDA@mail.gmail.com>
References: <mailman.2593.1414404988.12509.aboriginal-landley.net@lists.landley.net>	<544E4FCF.1040704@landley.net>	<CABX1NxEknX5No_OrSz7c36t+tvYzYOdFq=6TL2bHOzJoDpcp5g@mail.gmail.com>	<544EF7F8.5050404@landley.net>
	<CABX1NxHNYA4HBiJGykSUNDX=vjXTTp2_qH7Roj0nGvgsVNYVDA@mail.gmail.com>
Message-ID: <545572AC.1070702@landley.net>

On 11/01/14 17:03, David Halls wrote:
> Thanks Rob.
> 
> Regarding the TLS problem, I added:
> 
>     UCLIBC_HAS_TLS=y 
> 
> to baseconfig-uClibc but am still getting:
> 
>     Program uses unsupported TLS data!
> 
> It seems the code in ldso.c which does this checks for USE_TLS, which
> should be set because native threads are configured, right? 

Ah, the old "has" vs "use" nonsense uClibc kept doing:

http://lists.uclibc.org/pipermail/uclibc/2009-July/042818.html

Is there a reasonably small tls test program I can use to check if I've
enabled it right? I can take another crack at it, but don't currently
know what success looks like so can't tell when I've done it.

Rob

 1414886060.0

From dahalls at gmail.com  Mon Nov  3 07:18:15 2014
From: dahalls at gmail.com (David Halls)
Date: Mon, 3 Nov 2014 07:18:15 +0000
Subject: [Aboriginal] Aboriginal post from dahalls@gmail.com requires
	approval
In-Reply-To: <545572AC.1070702@landley.net>
References: <mailman.2593.1414404988.12509.aboriginal-landley.net@lists.landley.net>
	<544E4FCF.1040704@landley.net>
	<CABX1NxEknX5No_OrSz7c36t+tvYzYOdFq=6TL2bHOzJoDpcp5g@mail.gmail.com>
	<544EF7F8.5050404@landley.net>
	<CABX1NxHNYA4HBiJGykSUNDX=vjXTTp2_qH7Roj0nGvgsVNYVDA@mail.gmail.com>
	<545572AC.1070702@landley.net>
Message-ID: <CABX1NxFje++wXzBX-9hvKVLcuhM8+mO9CFk-nVb8dz6KYbJL3w@mail.gmail.com>

Sure:

(x86_64:1) /home/source/go/src # cat test.c
__thread int foo;

int main(int argc, char**argv)
{
}

(x86_64:1) /home/source/go/src # gcc test.c
(x86_64:1) /home/source/go/src # ./a.out

On 1 November 2014 23:54, Rob Landley <rob at landley.net> wrote:

> On 11/01/14 17:03, David Halls wrote:
> > Thanks Rob.
> >
> > Regarding the TLS problem, I added:
> >
> >     UCLIBC_HAS_TLS=y
> >
> > to baseconfig-uClibc but am still getting:
> >
> >     Program uses unsupported TLS data!
> >
> > It seems the code in ldso.c which does this checks for USE_TLS, which
> > should be set because native threads are configured, right?
>
> Ah, the old "has" vs "use" nonsense uClibc kept doing:
>
> http://lists.uclibc.org/pipermail/uclibc/2009-July/042818.html
>
> Is there a reasonably small tls test program I can use to check if I've
> enabled it right? I can take another crack at it, but don't currently
> know what success looks like so can't tell when I've done it.
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20141103/d7bdf26e/attachment.htm>

From dahalls at gmail.com  Mon Nov  3 09:14:59 2014
From: dahalls at gmail.com (David Halls)
Date: Mon, 3 Nov 2014 09:14:59 +0000
Subject: [Aboriginal] Aboriginal post from dahalls@gmail.com requires
	approval
In-Reply-To: <CABX1NxFje++wXzBX-9hvKVLcuhM8+mO9CFk-nVb8dz6KYbJL3w@mail.gmail.com>
References: <mailman.2593.1414404988.12509.aboriginal-landley.net@lists.landley.net>
	<544E4FCF.1040704@landley.net>
	<CABX1NxEknX5No_OrSz7c36t+tvYzYOdFq=6TL2bHOzJoDpcp5g@mail.gmail.com>
	<544EF7F8.5050404@landley.net>
	<CABX1NxHNYA4HBiJGykSUNDX=vjXTTp2_qH7Roj0nGvgsVNYVDA@mail.gmail.com>
	<545572AC.1070702@landley.net>
	<CABX1NxFje++wXzBX-9hvKVLcuhM8+mO9CFk-nVb8dz6KYbJL3w@mail.gmail.com>
Message-ID: <CABX1NxGmHmrtNLa8o9fW++znDdskPfLXBYOPRQUDLLiozNnzXA@mail.gmail.com>

On 3 November 2014 07:18, David Halls <dahalls at gmail.com> wrote:

> Sure:
>
> (x86_64:1) /home/source/go/src # cat test.c
> __thread int foo;
>
> int main(int argc, char**argv)
> {
> }
>
> (x86_64:1) /home/source/go/src # gcc test.c
> (x86_64:1) /home/source/go/src # ./a.out
>
> On 1 November 2014 23:54, Rob Landley <rob at landley.net> wrote:
>
>> On 11/01/14 17:03, David Halls wrote:
>> > Thanks Rob.
>> >
>> > Regarding the TLS problem, I added:
>> >
>> >     UCLIBC_HAS_TLS=y
>> >
>> > to baseconfig-uClibc but am still getting:
>> >
>> >     Program uses unsupported TLS data!
>> >
>> > It seems the code in ldso.c which does this checks for USE_TLS, which
>> > should be set because native threads are configured, right?
>>
>> Ah, the old "has" vs "use" nonsense uClibc kept doing:
>>
>> http://lists.uclibc.org/pipermail/uclibc/2009-July/042818.html
>>
>> Is there a reasonably small tls test program I can use to check if I've
>> enabled it right? I can take another crack at it, but don't currently
>> know what success looks like so can't tell when I've done it.
>>
>> Rob
>>
>
>
If I remove this line from sources/targets/x86_64:

LINUXTHREADS_OLD=y

then ntpl tries to build but I get:

/home/david/Downloads/aboriginal-1.2.9/build/simple-cross-compiler-x86_64/lib/../x86_64-unknown-linux/bin/ld:
libpthread/nptl/libpthread_so.a(pthread_once.oS): relocation R_X86_64_PC32
against `__fork_generation' can not be used when making a shared object;
recompile with -fPIC
/home/david/Downloads/aboriginal-1.2.9/build/simple-cross-compiler-x86_64/lib/../x86_64-unknown-linux/bin/ld:
final link failed: Bad value
collect2: ld returned 1 exit status
libpthread/nptl/Makefile.in:78: recipe for target 'lib/libpthread.so' failed
make: *** [lib/libpthread.so] Error 1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20141103/ba68f173/attachment.htm>

From rob at landley.net  Mon Nov  3 22:07:40 2014
From: rob at landley.net (Rob Landley)
Date: Mon, 03 Nov 2014 16:07:40 -0600
Subject: [Aboriginal] Fun with TLS [was requires approval]
In-Reply-To: <CABX1NxGmHmrtNLa8o9fW++znDdskPfLXBYOPRQUDLLiozNnzXA@mail.gmail.com>
References: <mailman.2593.1414404988.12509.aboriginal-landley.net@lists.landley.net>	<544E4FCF.1040704@landley.net>	<CABX1NxEknX5No_OrSz7c36t+tvYzYOdFq=6TL2bHOzJoDpcp5g@mail.gmail.com>	<544EF7F8.5050404@landley.net>	<CABX1NxHNYA4HBiJGykSUNDX=vjXTTp2_qH7Roj0nGvgsVNYVDA@mail.gmail.com>	<545572AC.1070702@landley.net>	<CABX1NxFje++wXzBX-9hvKVLcuhM8+mO9CFk-nVb8dz6KYbJL3w@mail.gmail.com>
	<CABX1NxGmHmrtNLa8o9fW++znDdskPfLXBYOPRQUDLLiozNnzXA@mail.gmail.com>
Message-ID: <5457FCAC.7070801@landley.net>



On 11/03/14 03:14, David Halls wrote:
> On 3 November 2014 07:18, David Halls <dahalls at gmail.com
> <mailto:dahalls at gmail.com>> wrote:
> 
>     Sure:
> 
>     (x86_64:1) /home/source/go/src # cat test.c
>     __thread int foo;
> 
>     int main(int argc, char**argv)
>     {
>     }
>
>     (x86_64:1) /home/source/go/src # gcc test.c
>     (x86_64:1) /home/source/go/src # ./a.out

I built that with simple-cross-compiler-i686 and
simple-cross-compiler-x86 (building --static each time) and nothing
happened.

However, when I change it to:

#include <stdio.h>

__thread int foo;

int main(int argc, char**argv) { printf("%d\n", foo);}


The result segfaulted on x86-64. (Printed 0 on i686.)

>     On 1 November 2014 23:54, Rob Landley <rob at landley.net
>     <mailto:rob at landley.net>> wrote:
> 
>         On 11/01/14 17:03, David Halls wrote:
>         > Thanks Rob.
>         >
>         > Regarding the TLS problem, I added:
>         >
>         >     UCLIBC_HAS_TLS=y
>         >
>         > to baseconfig-uClibc but am still getting:
>         >
>         >     Program uses unsupported TLS data!

You're building with the native compiler in the aboriginal image?

Ah, I see. Yup, works on i686, gives me the message on x86-64.

>         > It seems the code in ldso.c which does this checks for
>         USE_TLS, which
>         > should be set because native threads are configured, right?
> 
>         Ah, the old "has" vs "use" nonsense uClibc kept doing:
> 
>         http://lists.uclibc.org/pipermail/uclibc/2009-July/042818.html
> 
>         Is there a reasonably small tls test program I can use to check
>         if I've
>         enabled it right? I can take another crack at it, but don't
>         currently
>         know what success looks like so can't tell when I've done it.
> 
>         Rob
> 
> 
> 
> If I remove this line from sources/targets/x86_64:
> 
> LINUXTHREADS_OLD=y
> 
> then ntpl tries to build but I get:
> 
> /home/david/Downloads/aboriginal-1.2.9/build/simple-cross-compiler-x86_64/lib/../x86_64-unknown-linux/bin/ld:
> libpthread/nptl/libpthread_so.a(pthread_once.oS): relocation
> R_X86_64_PC32 against `__fork_generation' can not be used when making a
> shared object; recompile with -fPIC
> /home/david/Downloads/aboriginal-1.2.9/build/simple-cross-compiler-x86_64/lib/../x86_64-unknown-linux/bin/ld:
> final link failed: Bad value
> collect2: ld returned 1 exit status
> libpthread/nptl/Makefile.in:78: recipe for target 'lib/libpthread.so' failed
> make: *** [lib/libpthread.so] Error 1

Sigh. I very vaguely recall that...

Ah: http://landley.net/hg/aboriginal/rev/1522

Ok, yeah, I left a thing I need to fix. :)

Rob

 1415052460.0

From dahalls at gmail.com  Mon Nov  3 22:34:52 2014
From: dahalls at gmail.com (David Halls)
Date: Mon, 3 Nov 2014 22:34:52 +0000
Subject: [Aboriginal] Fun with TLS [was requires approval]
In-Reply-To: <5457FCAC.7070801@landley.net>
References: <mailman.2593.1414404988.12509.aboriginal-landley.net@lists.landley.net>
	<544E4FCF.1040704@landley.net>
	<CABX1NxEknX5No_OrSz7c36t+tvYzYOdFq=6TL2bHOzJoDpcp5g@mail.gmail.com>
	<544EF7F8.5050404@landley.net>
	<CABX1NxHNYA4HBiJGykSUNDX=vjXTTp2_qH7Roj0nGvgsVNYVDA@mail.gmail.com>
	<545572AC.1070702@landley.net>
	<CABX1NxFje++wXzBX-9hvKVLcuhM8+mO9CFk-nVb8dz6KYbJL3w@mail.gmail.com>
	<CABX1NxGmHmrtNLa8o9fW++znDdskPfLXBYOPRQUDLLiozNnzXA@mail.gmail.com>
	<5457FCAC.7070801@landley.net>
Message-ID: <CABX1NxHXnDtxnyMovzAyY4sGPDZX-zoXL+qKtin7-qvbhMwNWA@mail.gmail.com>

>
> Ah, I see. Yup, works on i686, gives me the message on x86-64.
>

Yep

>
> > If I remove this line from sources/targets/x86_64:
> >
> > LINUXTHREADS_OLD=y
> >
> > then ntpl tries to build but I get:
> >
> >
> /home/david/Downloads/aboriginal-1.2.9/build/simple-cross-compiler-x86_64/lib/../x86_64-unknown-linux/bin/ld:
> > libpthread/nptl/libpthread_so.a(pthread_once.oS): relocation
> > R_X86_64_PC32 against `__fork_generation' can not be used when making a
> > shared object; recompile with -fPIC
> >
> /home/david/Downloads/aboriginal-1.2.9/build/simple-cross-compiler-x86_64/lib/../x86_64-unknown-linux/bin/ld:
> > final link failed: Bad value
> > collect2: ld returned 1 exit status
> > libpthread/nptl/Makefile.in:78: recipe for target 'lib/libpthread.so'
> failed
> > make: *** [lib/libpthread.so] Error 1
>
> Sigh. I very vaguely recall that...
>
> Ah: http://landley.net/hg/aboriginal/rev/1522
>
> Ok, yeah, I left a thing I need to fix. :)
>
>
Doing this in nptl/sysdeps/unix/sysv/linux/x86_64/pthread_once.S:

 +       .hidden __fork_generation
         .comm   __fork_generation, 4, 4

fixes the compile problem - have to hide __fork_generation in the assembly,
like the C declaration does.
(I have yet to test the TLS stuff in the image.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20141103/7b3a29ac/attachment.htm>

From dahalls at gmail.com  Mon Nov  3 22:40:26 2014
From: dahalls at gmail.com (David Halls)
Date: Mon, 3 Nov 2014 22:40:26 +0000
Subject: [Aboriginal] Fun with TLS [was requires approval]
In-Reply-To: <CABX1NxHXnDtxnyMovzAyY4sGPDZX-zoXL+qKtin7-qvbhMwNWA@mail.gmail.com>
References: <mailman.2593.1414404988.12509.aboriginal-landley.net@lists.landley.net>
	<544E4FCF.1040704@landley.net>
	<CABX1NxEknX5No_OrSz7c36t+tvYzYOdFq=6TL2bHOzJoDpcp5g@mail.gmail.com>
	<544EF7F8.5050404@landley.net>
	<CABX1NxHNYA4HBiJGykSUNDX=vjXTTp2_qH7Roj0nGvgsVNYVDA@mail.gmail.com>
	<545572AC.1070702@landley.net>
	<CABX1NxFje++wXzBX-9hvKVLcuhM8+mO9CFk-nVb8dz6KYbJL3w@mail.gmail.com>
	<CABX1NxGmHmrtNLa8o9fW++znDdskPfLXBYOPRQUDLLiozNnzXA@mail.gmail.com>
	<5457FCAC.7070801@landley.net>
	<CABX1NxHXnDtxnyMovzAyY4sGPDZX-zoXL+qKtin7-qvbhMwNWA@mail.gmail.com>
Message-ID: <CABX1NxE6QHTzVXbnN5PYK0fggoaFK7jCsw80nHWyfacwa-LD+A@mail.gmail.com>

>
> Doing this in nptl/sysdeps/unix/sysv/linux/x86_64/pthread_once.S:
>
>  +       .hidden __fork_generation
>          .comm   __fork_generation, 4, 4
>
> fixes the compile problem - have to hide __fork_generation in the
> assembly, like the C declaration does.
> (I have yet to test the TLS stuff in the image.)
>
>
I no longer get the TLS warning on x86_64. FYI this I what I did:

Applied the patch above (added .hidden __fork_generation).

Add these lines to sources/baseconfig-uClibc:

UCLIBC_HAS_TLS=y
UCLIBC_HAS_STDIO_FUTEXES=y
UCLIBC_HAS_SSP=y

(I needed SSP to compile Perl).

Remove this line from sources/targets/x86_64:

LINUXTHREADS_OLD=y
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20141103/0dc37892/attachment.htm>

From dahalls at gmail.com  Tue Nov  4 09:21:32 2014
From: dahalls at gmail.com (David Halls)
Date: Tue, 4 Nov 2014 09:21:32 +0000
Subject: [Aboriginal] Fun with TLS [was requires approval]
In-Reply-To: <CABX1NxE6QHTzVXbnN5PYK0fggoaFK7jCsw80nHWyfacwa-LD+A@mail.gmail.com>
References: <mailman.2593.1414404988.12509.aboriginal-landley.net@lists.landley.net>
	<544E4FCF.1040704@landley.net>
	<CABX1NxEknX5No_OrSz7c36t+tvYzYOdFq=6TL2bHOzJoDpcp5g@mail.gmail.com>
	<544EF7F8.5050404@landley.net>
	<CABX1NxHNYA4HBiJGykSUNDX=vjXTTp2_qH7Roj0nGvgsVNYVDA@mail.gmail.com>
	<545572AC.1070702@landley.net>
	<CABX1NxFje++wXzBX-9hvKVLcuhM8+mO9CFk-nVb8dz6KYbJL3w@mail.gmail.com>
	<CABX1NxGmHmrtNLa8o9fW++znDdskPfLXBYOPRQUDLLiozNnzXA@mail.gmail.com>
	<5457FCAC.7070801@landley.net>
	<CABX1NxHXnDtxnyMovzAyY4sGPDZX-zoXL+qKtin7-qvbhMwNWA@mail.gmail.com>
	<CABX1NxE6QHTzVXbnN5PYK0fggoaFK7jCsw80nHWyfacwa-LD+A@mail.gmail.com>
Message-ID: <CABX1NxHK6NqxtgQBkPBT6eNxbqsucdAVcsD5U308jmH0KFC4Kw@mail.gmail.com>

So the problem I have now is that GCC spins when compiling anything (inside
QEMU)
:(


On 3 November 2014 22:40, David Halls <dahalls at gmail.com> wrote:

> Doing this in nptl/sysdeps/unix/sysv/linux/x86_64/pthread_once.S:
>>
>>  +       .hidden __fork_generation
>>          .comm   __fork_generation, 4, 4
>>
>> fixes the compile problem - have to hide __fork_generation in the
>> assembly, like the C declaration does.
>> (I have yet to test the TLS stuff in the image.)
>>
>>
> I no longer get the TLS warning on x86_64. FYI this I what I did:
>
> Applied the patch above (added .hidden __fork_generation).
>
> Add these lines to sources/baseconfig-uClibc:
>
> UCLIBC_HAS_TLS=y
> UCLIBC_HAS_STDIO_FUTEXES=y
> UCLIBC_HAS_SSP=y
>
> (I needed SSP to compile Perl).
>
> Remove this line from sources/targets/x86_64:
>
> LINUXTHREADS_OLD=y
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20141104/06ccc756/attachment.htm>

From rob at landley.net  Tue Nov  4 16:40:18 2014
From: rob at landley.net (Rob Landley)
Date: Tue, 04 Nov 2014 10:40:18 -0600
Subject: [Aboriginal] Fun with TLS [was requires approval]
In-Reply-To: <CABX1NxHK6NqxtgQBkPBT6eNxbqsucdAVcsD5U308jmH0KFC4Kw@mail.gmail.com>
References: <mailman.2593.1414404988.12509.aboriginal-landley.net@lists.landley.net>	<544E4FCF.1040704@landley.net>	<CABX1NxEknX5No_OrSz7c36t+tvYzYOdFq=6TL2bHOzJoDpcp5g@mail.gmail.com>	<544EF7F8.5050404@landley.net>	<CABX1NxHNYA4HBiJGykSUNDX=vjXTTp2_qH7Roj0nGvgsVNYVDA@mail.gmail.com>	<545572AC.1070702@landley.net>	<CABX1NxFje++wXzBX-9hvKVLcuhM8+mO9CFk-nVb8dz6KYbJL3w@mail.gmail.com>	<CABX1NxGmHmrtNLa8o9fW++znDdskPfLXBYOPRQUDLLiozNnzXA@mail.gmail.com>	<5457FCAC.7070801@landley.net>	<CABX1NxHXnDtxnyMovzAyY4sGPDZX-zoXL+qKtin7-qvbhMwNWA@mail.gmail.com>	<CABX1NxE6QHTzVXbnN5PYK0fggoaFK7jCsw80nHWyfacwa-LD+A@mail.gmail.com>
	<CABX1NxHK6NqxtgQBkPBT6eNxbqsucdAVcsD5U308jmH0KFC4Kw@mail.gmail.com>
Message-ID: <54590172.7010309@landley.net>

On 11/04/14 03:21, David Halls wrote:
> So the problem I have now is that GCC spins when compiling anything
> (inside QEMU)
> :(

For host==target you can chroot into the build/root-filesystem-$ARCH
directory, which should let you run gdb on a process. (I believe you can
attach by PID and see where it's spinning, with stack backtrace and
everything.)

But if uClibc's NPTL doesn't "just work" for a target (not just a
configuration issue but needing nontrivial debugging), the best course
of action is probably for me to finish the musl migration for the
supported targets. (Of which x86-64 should be one.) uClibc is sort of a
dead-end project (Despite the existence of the various uClibc-ng forks.)

Rob

 1415119218.0

From dahalls at gmail.com  Tue Nov  4 21:01:34 2014
From: dahalls at gmail.com (David Halls)
Date: Tue, 4 Nov 2014 21:01:34 +0000
Subject: [Aboriginal] Fun with TLS [was requires approval]
In-Reply-To: <54590172.7010309@landley.net>
References: <mailman.2593.1414404988.12509.aboriginal-landley.net@lists.landley.net>
	<544E4FCF.1040704@landley.net>
	<CABX1NxEknX5No_OrSz7c36t+tvYzYOdFq=6TL2bHOzJoDpcp5g@mail.gmail.com>
	<544EF7F8.5050404@landley.net>
	<CABX1NxHNYA4HBiJGykSUNDX=vjXTTp2_qH7Roj0nGvgsVNYVDA@mail.gmail.com>
	<545572AC.1070702@landley.net>
	<CABX1NxFje++wXzBX-9hvKVLcuhM8+mO9CFk-nVb8dz6KYbJL3w@mail.gmail.com>
	<CABX1NxGmHmrtNLa8o9fW++znDdskPfLXBYOPRQUDLLiozNnzXA@mail.gmail.com>
	<5457FCAC.7070801@landley.net>
	<CABX1NxHXnDtxnyMovzAyY4sGPDZX-zoXL+qKtin7-qvbhMwNWA@mail.gmail.com>
	<CABX1NxE6QHTzVXbnN5PYK0fggoaFK7jCsw80nHWyfacwa-LD+A@mail.gmail.com>
	<CABX1NxHK6NqxtgQBkPBT6eNxbqsucdAVcsD5U308jmH0KFC4Kw@mail.gmail.com>
	<54590172.7010309@landley.net>
Message-ID: <CABX1NxGodRBp7CbHXFi-SqzvybcqPafNxftn4vGtRkxT3bdP1w@mail.gmail.com>

>
> For host==target you can chroot into the build/root-filesystem-$ARCH
> directory, which should let you run gdb on a process. (I believe you can
> attach by PID and see where it's spinning, with stack backtrace and
> everything.)
>
> But if uClibc's NPTL doesn't "just work" for a target (not just a
> configuration issue but needing nontrivial debugging), the best course
> of action is probably for me to finish the musl migration for the
> supported targets. (Of which x86-64 should be one.) uClibc is sort of a
> dead-end project (Despite the existence of the various uClibc-ng forks.)
>
> Rob
>

It seems to be distcc. Perhaps there's a network/Qemu problem of some kind.
If I remove distcc from the path then it's fine. Is there a simple way to
disable distcc when running dev_environment.sh?

Nevertheless, switching to musl is a good idea IMHO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20141104/784614b5/attachment.htm>

From rob at landley.net  Tue Nov  4 22:15:09 2014
From: rob at landley.net (Rob Landley)
Date: Tue, 04 Nov 2014 16:15:09 -0600
Subject: [Aboriginal] Fun with TLS [was requires approval]
In-Reply-To: <CABX1NxGodRBp7CbHXFi-SqzvybcqPafNxftn4vGtRkxT3bdP1w@mail.gmail.com>
References: <mailman.2593.1414404988.12509.aboriginal-landley.net@lists.landley.net>	<544E4FCF.1040704@landley.net>	<CABX1NxEknX5No_OrSz7c36t+tvYzYOdFq=6TL2bHOzJoDpcp5g@mail.gmail.com>	<544EF7F8.5050404@landley.net>	<CABX1NxHNYA4HBiJGykSUNDX=vjXTTp2_qH7Roj0nGvgsVNYVDA@mail.gmail.com>	<545572AC.1070702@landley.net>	<CABX1NxFje++wXzBX-9hvKVLcuhM8+mO9CFk-nVb8dz6KYbJL3w@mail.gmail.com>	<CABX1NxGmHmrtNLa8o9fW++znDdskPfLXBYOPRQUDLLiozNnzXA@mail.gmail.com>	<5457FCAC.7070801@landley.net>	<CABX1NxHXnDtxnyMovzAyY4sGPDZX-zoXL+qKtin7-qvbhMwNWA@mail.gmail.com>	<CABX1NxE6QHTzVXbnN5PYK0fggoaFK7jCsw80nHWyfacwa-LD+A@mail.gmail.com>	<CABX1NxHK6NqxtgQBkPBT6eNxbqsucdAVcsD5U308jmH0KFC4Kw@mail.gmail.com>	<54590172.7010309@landley.net>
	<CABX1NxGodRBp7CbHXFi-SqzvybcqPafNxftn4vGtRkxT3bdP1w@mail.gmail.com>
Message-ID: <54594FED.5040402@landley.net>



On 11/04/14 15:01, David Halls wrote:
>     For host==target you can chroot into the build/root-filesystem-$ARCH
>     directory, which should let you run gdb on a process. (I believe you can
>     attach by PID and see where it's spinning, with stack backtrace and
>     everything.)
> 
>     But if uClibc's NPTL doesn't "just work" for a target (not just a
>     configuration issue but needing nontrivial debugging), the best course
>     of action is probably for me to finish the musl migration for the
>     supported targets. (Of which x86-64 should be one.) uClibc is sort of a
>     dead-end project (Despite the existence of the various uClibc-ng forks.)
> 
>     Rob
> 
> 
> It seems to be distcc. Perhaps there's a network/Qemu problem of some
> kind. If I remove distcc from the path then it's fine. Is there a simple
> way to disable distcc when running dev_environment.sh?

Yes, the distcc binaries are in their own directory, so adjust the $PATH
so that's not searched.

> Nevertheless, switching to musl is a good idea IMHO. 

Indeed. I just need to catch up enough on everything else to devote a
couple weekends to it...

Rob

 1415139309.0

From stephen.n.turner at gmail.com  Wed Nov  5 22:49:05 2014
From: stephen.n.turner at gmail.com (stephen Turner)
Date: Wed, 5 Nov 2014 17:49:05 -0500
Subject: [Aboriginal] busybox awk
Message-ID: <CAA7aPHh5oa=iOYc-SrgnG5geMVaLBtAw7rtjMNnneuMjFEuLSw@mail.gmail.com>

Rob, have you seen any issues with busybox awk throwing errors during a
recompile of gcc? Im currently seeing a awk -f error. You don't have awk in
the precompiled toybox bin at the moment so i would assume on your
aboriginal platform that your using busybox awk or an alternative?

thanks
Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20141105/7c6f3209/attachment.htm>

From rob at landley.net  Thu Nov  6 03:16:34 2014
From: rob at landley.net (Rob Landley)
Date: Wed, 05 Nov 2014 21:16:34 -0600
Subject: [Aboriginal] busybox awk
In-Reply-To: <CAA7aPHh5oa=iOYc-SrgnG5geMVaLBtAw7rtjMNnneuMjFEuLSw@mail.gmail.com>
References: <CAA7aPHh5oa=iOYc-SrgnG5geMVaLBtAw7rtjMNnneuMjFEuLSw@mail.gmail.com>
Message-ID: <545AE812.8060702@landley.net>

On 11/05/14 16:49, stephen Turner wrote:
> Rob, have you seen any issues with busybox awk throwing errors during a
> recompile of gcc?

Not that I noticed? (I just built an m68k

> Im currently seeing a awk -f error. You don't have awk
> in the precompiled toybox bin at the moment so i would assume on your
> aboriginal platform that your using busybox awk or an alternative?

It's using busybox awk. The host-tools.sh stage populates build/host and
the restricts the $PATH to point at just build/host so it doesn't leak
host dependencies into the build.

I covered that in the big presentation, the three slides starting at:

https://speakerdeck.com/landley/developing-for-non-x86-targets-using-qemu?slide=98

Rob

 1415243794.0

From stephen.n.turner at gmail.com  Thu Nov  6 03:22:07 2014
From: stephen.n.turner at gmail.com (stephen Turner)
Date: Wed, 5 Nov 2014 22:22:07 -0500
Subject: [Aboriginal] busybox awk
In-Reply-To: <545AE812.8060702@landley.net>
References: <CAA7aPHh5oa=iOYc-SrgnG5geMVaLBtAw7rtjMNnneuMjFEuLSw@mail.gmail.com>
	<545AE812.8060702@landley.net>
Message-ID: <CAA7aPHjB090T0-Zcb6TjMBsLQqHQ--KmsWquyKGMGnNqY6fr2w@mail.gmail.com>

Thanks, I have a script that downloads the latest busybox from a folder
labeled latest which apparently hasnt been updated in a while and so I was
using an unpatched busybox *sigh*  which has a awk bug that was repaired
apparently a year ago so says one source. So much for being the latest......
On Nov 5, 2014 10:16 PM, "Rob Landley" <rob at landley.net> wrote:

> On 11/05/14 16:49, stephen Turner wrote:
> > Rob, have you seen any issues with busybox awk throwing errors during a
> > recompile of gcc?
>
> Not that I noticed? (I just built an m68k
>
> > Im currently seeing a awk -f error. You don't have awk
> > in the precompiled toybox bin at the moment so i would assume on your
> > aboriginal platform that your using busybox awk or an alternative?
>
> It's using busybox awk. The host-tools.sh stage populates build/host and
> the restricts the $PATH to point at just build/host so it doesn't leak
> host dependencies into the build.
>
> I covered that in the big presentation, the three slides starting at:
>
>
> https://speakerdeck.com/landley/developing-for-non-x86-targets-using-qemu?slide=98
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20141105/6dceca4e/attachment.htm>

From rob at landley.net  Thu Nov  6 12:21:33 2014
From: rob at landley.net (Rob Landley)
Date: Thu, 06 Nov 2014 06:21:33 -0600
Subject: [Aboriginal] busybox awk
In-Reply-To: <CAA7aPHjB090T0-Zcb6TjMBsLQqHQ--KmsWquyKGMGnNqY6fr2w@mail.gmail.com>
References: <CAA7aPHh5oa=iOYc-SrgnG5geMVaLBtAw7rtjMNnneuMjFEuLSw@mail.gmail.com>	<545AE812.8060702@landley.net>
	<CAA7aPHjB090T0-Zcb6TjMBsLQqHQ--KmsWquyKGMGnNqY6fr2w@mail.gmail.com>
Message-ID: <545B67CD.1080208@landley.net>

On 11/05/14 21:22, stephen Turner wrote:
> Thanks, I have a script that downloads the latest busybox from a folder
> labeled latest which apparently hasnt been updated in a while and so I
> was using an unpatched busybox *sigh*  which has a awk bug that was
> repaired apparently a year ago so says one source. So much for being the
> latest......

Um, that's probably my fault. I used to upload busybox binaries from my
aboriginal builds to busybox.net, but haven't done so in ages because
toybox is now replacing most of the commands out of that so I haven't
bothered to upgrade the busybox version aboriginal is using in a while.

Locally I have the latest one in the build, I can upload binaries from
that next time I cut a release. (If I can remember my password to the
busybox server, anyway. Login's via ssh key but sudo prompts me. I keep
changing the permissions on the directory so I can write to it without
that and somebody keeps "fixing" it so I have to use sudo. Because
requiring me to do stuff as root is far more secure than letting my user
have write permission to specific directories...)

Rob

 1415276493.0

From stephen.n.turner at gmail.com  Thu Nov  6 16:19:56 2014
From: stephen.n.turner at gmail.com (stephen Turner)
Date: Thu, 6 Nov 2014 11:19:56 -0500
Subject: [Aboriginal] busybox awk
In-Reply-To: <545B67CD.1080208@landley.net>
References: <CAA7aPHh5oa=iOYc-SrgnG5geMVaLBtAw7rtjMNnneuMjFEuLSw@mail.gmail.com>
	<545AE812.8060702@landley.net>
	<CAA7aPHjB090T0-Zcb6TjMBsLQqHQ--KmsWquyKGMGnNqY6fr2w@mail.gmail.com>
	<545B67CD.1080208@landley.net>
Message-ID: <CAA7aPHj91N_=B1Gtotp5PxYP-6v6PsQHt=ZF=Xbfg84AnMa7Fw@mail.gmail.com>

I just need a Crutch to get me through till Toybox is finished. Busybox is
a easy and obvious choice but caught me by surprise when i received the awk
error. I'm glad the latest version fixes it so i can just manually fetch
the latest busybox.

You still do some work for busybox then or just maintain the latest folder?

On Thu, Nov 6, 2014 at 7:21 AM, Rob Landley <rob at landley.net> wrote:

> On 11/05/14 21:22, stephen Turner wrote:
> > Thanks, I have a script that downloads the latest busybox from a folder
> > labeled latest which apparently hasnt been updated in a while and so I
> > was using an unpatched busybox *sigh*  which has a awk bug that was
> > repaired apparently a year ago so says one source. So much for being the
> > latest......
>
> Um, that's probably my fault. I used to upload busybox binaries from my
> aboriginal builds to busybox.net, but haven't done so in ages because
> toybox is now replacing most of the commands out of that so I haven't
> bothered to upgrade the busybox version aboriginal is using in a while.
>
> Locally I have the latest one in the build, I can upload binaries from
> that next time I cut a release. (If I can remember my password to the
> busybox server, anyway. Login's via ssh key but sudo prompts me. I keep
> changing the permissions on the directory so I can write to it without
> that and somebody keeps "fixing" it so I have to use sudo. Because
> requiring me to do stuff as root is far more secure than letting my user
> have write permission to specific directories...)
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20141106/7eb58f16/attachment.htm>

From rob at landley.net  Thu Nov  6 20:10:34 2014
From: rob at landley.net (Rob Landley)
Date: Thu, 06 Nov 2014 14:10:34 -0600
Subject: [Aboriginal] busybox awk
In-Reply-To: <CAA7aPHj91N_=B1Gtotp5PxYP-6v6PsQHt=ZF=Xbfg84AnMa7Fw@mail.gmail.com>
References: <CAA7aPHh5oa=iOYc-SrgnG5geMVaLBtAw7rtjMNnneuMjFEuLSw@mail.gmail.com>	<545AE812.8060702@landley.net>	<CAA7aPHjB090T0-Zcb6TjMBsLQqHQ--KmsWquyKGMGnNqY6fr2w@mail.gmail.com>	<545B67CD.1080208@landley.net>
	<CAA7aPHj91N_=B1Gtotp5PxYP-6v6PsQHt=ZF=Xbfg84AnMa7Fw@mail.gmail.com>
Message-ID: <545BD5BA.3000503@landley.net>

On 11/06/14 10:19, stephen Turner wrote:
> I just need a Crutch to get me through till Toybox is finished.

If you do this in the aboriginal source:

  sed '/toybox/,$d' sources/baseconfig-busybox

That's the busybox miniconfig it's building. The full file is all the
things you need to switch on to build Linux From Scratch (and have a few
niceties like "top"). The stuff after the "toybox" comment is the stuff
that toybox already replaces.

Each release I update the countdown of remaining commands in
http://landley.net/toybox/roadmap.html#dev_env

> Busybox is a easy and obvious choice

Oh sure, that's why I'm still using it as I replace stuff in aboriginal.

> but caught me by surprise when i received
> the awk error. I'm glad the latest version fixes it so i can just
> manually fetch the latest busybox.
> 
> You still do some work for busybox then or just maintain the latest folder?

Pretty much neither at this point. There was this guy named Bruce
trolling the list about license issues while taking credit for my work,
so I wandered off to do other things...

Rob

 1415304634.0

From stephen.n.turner at gmail.com  Thu Nov  6 21:29:58 2014
From: stephen.n.turner at gmail.com (stephen Turner)
Date: Thu, 6 Nov 2014 16:29:58 -0500
Subject: [Aboriginal] busybox awk
In-Reply-To: <545BD5BA.3000503@landley.net>
References: <CAA7aPHh5oa=iOYc-SrgnG5geMVaLBtAw7rtjMNnneuMjFEuLSw@mail.gmail.com>
	<545AE812.8060702@landley.net>
	<CAA7aPHjB090T0-Zcb6TjMBsLQqHQ--KmsWquyKGMGnNqY6fr2w@mail.gmail.com>
	<545B67CD.1080208@landley.net>
	<CAA7aPHj91N_=B1Gtotp5PxYP-6v6PsQHt=ZF=Xbfg84AnMa7Fw@mail.gmail.com>
	<545BD5BA.3000503@landley.net>
Message-ID: <CAA7aPHj+hZULWAdTkuV2dEnCi2d=5uhGD9caf5hgwGpuzPM-2w@mail.gmail.com>

On Thu, Nov 6, 2014 at 3:10 PM, Rob Landley <rob at landley.net> wrote:

> On 11/06/14 10:19, stephen Turner wrote:
> > I just need a Crutch to get me through till Toybox is finished.
>
> If you do this in the aboriginal source:
>
>   sed '/toybox/,$d' sources/baseconfig-busybox
>
> That's the busybox miniconfig it's building. The full file is all the
> things you need to switch on to build Linux From Scratch (and have a few
> niceties like "top"). The stuff after the "toybox" comment is the stuff
> that toybox already replaces.
>

Nice, and throw in a diff and you would have exactly what you need to turn
on in busybox :-p



>
> Each release I update the countdown of remaining commands in
> http://landley.net/toybox/roadmap.html#dev_env
>
>
Yup, i check this fairly regularly :)



> > Busybox is a easy and obvious choice
>
> Oh sure, that's why I'm still using it as I replace stuff in aboriginal.
>
> > but caught me by surprise when i received
> > the awk error. I'm glad the latest version fixes it so i can just
> > manually fetch the latest busybox.
> >
> > You still do some work for busybox then or just maintain the latest
> folder?
>
> Pretty much neither at this point. There was this guy named Bruce
> trolling the list about license issues while taking credit for my work,
> so I wandered off to do other things...
>
> Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20141106/2516b9e6/attachment.htm>

From james_mcmechan at hotmail.com  Fri Nov 14 15:16:57 2014
From: james_mcmechan at hotmail.com (James McMechan)
Date: Fri, 14 Nov 2014 07:16:57 -0800
Subject: [Aboriginal] testing on a variety of platforms
Message-ID: <COL125-W249B1C6E8A9F096E57B0B6E28C0@phx.gbl>

compile results from my current test setup
unless I messed up these were all built from the aboriginal-1.2.9.tar.bz2
with no changes to the config

host x86_64 armv6 armv5 ppc SPARC
target
armv4eb F?????? F ????? F ???? F ??? F
armv4l??? S?????? F?????? F ???? F ??? F
armv4tl?? S?????? S?????? F ???? F ??? F
armv5l??? S?????? S?????? F ???? F ??? F
armv6l??? S?????? S?????? F ???? F ??? F
i486?????? S?????? S?????? S ???? F ??? F
i586?????? S?????? S?????? S ???? F ??? F
i686?????? S?????? S?????? S ???? F ??? F
m68k???? S?????? S?????? S ???? S ??? S
mips????? S?????? F?????? F ???? S ??? S
mips64? S?????? F?????? F ???? S ??? S
mipsel?? S?????? S?????? S ???? S ??? S
powerpc S?????? F?????? F ???? S ??? S
sh4?????? S?????? S?????? S ???? S ??? S
sparc??? S?????? F?????? F ???? S ??? S
x86_64? S?????? F?????? F ???? S ??? S


What I find interesting is that the only archs that compile consistantly are
m68k, mipsel, sh4 needless to say these are not what I would call the
most active architures in linux, apparently however they keep up on things
not breaking in weird cross compile setups...
I also note that the two big endian systems both compile the exact same? set
of big endian targets successfully.
arm does not like bigendian mips, powerpc,sparc or x86_64 but both are happy
with 32bit intel
my armv5 ArchLinux wont even cross-compile any arm maybe I should see
if I can get a debian going on it since it is about twice as fast as the armv6
The failure modes seem to come in families.

results with last few lines of errors

foxcon nettop Intel Atom 330 (2x2 threads) 1.6GHz 4GB
gcc (Gentoo 4.8.3 p1.1, pie-0.5.9)
x86_64-pc-linux-gnu

armv4eb failed:

? STRIP -x -R .note -R .comment libc/libc_so.a
make[1]: 'lib/ld-uClibc.so' is up to date.
? LD libuClibc-0.9.33.2.so
libc/Makefile.in:64: recipe for target 'lib/libc.so' failed

armv4l success:

armv4tl success:

armv5l success:

armv6l success:

i486 success:

i586 success:

i686 success:

m68k success:

mips success:

mips64 success:

mipsel success:

powerpc success:

sh4 success:

sparc success:

x86_64 success:



Raspberry PI  Broadcom BCM2835 700MHz 512MB
current raspbian (wheezy)
gcc (Debian 4.6.3-14+rpi1)
arm-linux-gnueabihf

armv4eb failed:

? STRIP -x -R .note -R .comment libc/libc_so.a
? LD libuClibc-0.9.33.2.so
libc/Makefile.in:64: recipe for target 'lib/libc.so' failed

armv4l failed:

make[1]: Entering directory '/home/pi/aboriginal-1.2.9/build/temp-armv4l/build-gcc/gcc'
make[1]: Leaving directory '/home/pi/aboriginal-1.2.9/build/temp-armv4l/build-gcc/gcc'
Checking multilib configuration for libstdc++-v3...
mkdir armv4l-unknown-linux
mkdir armv4l-unknown-linux/libstdc++-v3
Makefile:8872: recipe for target 'configure-target-libstdc++-v3' failed

armv4tl success:

armv5l success:

armv6l success:

i486 success:

i586 success:

i686 success:

m68k success:

mips failed:

make[1]: Entering directory '/home/pi/aboriginal-1.2.9/build/temp-mips/build-gcc/gcc'
make[1]: Leaving directory '/home/pi/aboriginal-1.2.9/build/temp-mips/build-gcc/gcc'
Checking multilib configuration for libstdc++-v3...
mkdir mips-unknown-linux
mkdir mips-unknown-linux/libstdc++-v3
Makefile:8872: recipe for target 'configure-target-libstdc++-v3' failed


mips64 failed:

mips64-cc
 -DHAVE_CONFIG_H -I. 
-I/home/pi/aboriginal-1.2.9/build/temp-mips64/binutils/binutils -I. 
-D_GNU_SOURCE -I. 
-I/home/pi/aboriginal-1.2.9/build/temp-mips64/binutils/binutils -I../bfd
 -I/home/pi/aboriginal-1.2.9/build/temp-mips64/binutils/binutils/../bfd 
-I/home/pi/aboriginal-1.2.9/build/temp-mips64/binutils/binutils/../include
 -DLOCALEDIR="\"/home/pi/aboriginal-1.2.9/build/native-compiler-mi
ps64/share/locale\""
 -Dbin_dummy_emulation=bin_vanilla_emulation?? -W -Wall 
-Wstrict-prototypes -Wmissing-prototypes -O2 --static? -c 
/home/pi/aboriginal-1.2.9/build/temp-mips64/binutils/binutils/filemode.c
/bin/bash
 ./libtool --tag=CC --mode=link mips64-cc -W -Wall -Wstrict-prototypes 
-Wmissing-prototypes -O2 --static??? -o size? size.o bucomm.o version.o 
filemode.o ../bfd/libbfd.la ../libiberty/libiberty.a? -lm 
libtool: 
link: mips64-cc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -O2 
--static -o size size.o bucomm.o version.o filemode.o? 
../bfd/.libs/libbfd.a ../libiberty/libiberty.a -lm
Makefile:652: recipe for target 'size' failed
make[4]: Leaving directory '/home/pi/aboriginal-1.2.9/build/temp-mips64/build-binutils/binutils'

mipsel success:

powerpc failed:

make[1]: Entering directory '/home/pi/aboriginal-1.2.9/build/temp-powerpc/build-gcc/gcc'
make[1]: Leaving directory '/home/pi/aboriginal-1.2.9/build/temp-powerpc/build-gcc/gcc'
Checking multilib configuration for libstdc++-v3...
mkdir powerpc-unknown-linux
mkdir powerpc-unknown-linux/libstdc++-v3
Makefile:8872: recipe for target 'configure-target-libstdc++-v3' failed

sh4 success:

sparc failed:

make[1]: Leaving directory '/home/pi/aboriginal-1.2.9/build/temp-sparc/build-gcc/gcc'
Checking multilib configuration for libstdc++-v3...
mkdir sparc-unknown-linux
mkdir sparc-unknown-linux/libstdc++-v3
Makefile:8872: recipe for target 'configure-target-libstdc++-v3' failed

x86_64 failed:

x86_64-cc
 -DHAVE_CONFIG_H -I. 
-I/home/pi/aboriginal-1.2.9/build/temp-x86_64/binutils/binutils -I. 
-D_GNU_SOURCE -I. 
-I/home/pi/aboriginal-1.2.9/build/temp-x86_64/binutils/binutils -I../bfd
 -I/home/pi/aboriginal-1.2.9/build/temp-x86_64/binutils/binutils/../bfd 
-I/home/pi/aboriginal-1.2.9/build/temp-x86_64/binutils/binutils/../include
 
-DLOCALEDIR="\"/home/pi/aboriginal-1.2.9/build/native-compiler-x86_64/share/locale\""
 -Dbin_dummy_emulation=bin_vanilla_emulation?? -W -Wall 
-Wstrict-prototypes -Wmissing-prototypes -O2 --static? -c 
/home/pi/aboriginal-1.2.9/build/temp-x86_64/binutils/binutils/filemode.c
/bin/bash
 ./libtool --tag=CC --mode=link x86_64-cc -W -Wall -Wstrict-prototypes 
-Wmissing-prototypes -O2 --static??? -o size? size.o bucomm.o version.o 
filemode.o ../bfd/libbfd.la ../libiberty/libiberty.a? -lm 
libtool: 
link: x86_64-cc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -O2 
--static -o size size.o bucomm.o version.o filemode.o? 
../bfd/.libs/libbfd.a ../libiberty/libiberty.a -lm
Makefile:652: recipe for target 'size' failed
make[4]: Leaving directory '/home/pi/aboriginal-1.2.9/build/temp-x86_64/build-binutils/binutils'



Seagate GoFlex Home Marvell "Kirkwood" Feroceon 88FR131r1 (5TE/v5l) 1.2GHz 128MB
current ArchLinux (alarm)
gcc (GCC) 4.8.2 20131219
armv5tel-unknown-linux-gnueabi

armv4eb failed:

? STRIP -x -R .note -R .comment libc/libc_so.a
? LD libuClibc-0.9.33.2.so
libc/Makefile.in:64: recipe for target 'lib/libc.so' failed

armv4l failed:

armv4l-c++ -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv4l/gcc-core/libstdc++-v3/../gcc -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv4l/build-gcc/armv4l-unknown-linux/libstdc++-v3/include/armv4l-unknown-linux -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv4l/build-gcc/armv4l-unknown-linux/libstdc++-v3/include -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv4l/gcc-core/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c /home/mcmechan/aboriginal-1.2.9/build/temp-armv4l/gcc-core/libstdc++-v3/libsupc++/del_op.cc? -fPIC -DPIC -o del_op.o
Makefile:519: recipe for target 'del_op.lo' failed

armv4tl failed:

armv4tl-c++ -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv4tl/gcc-core/libstdc++-v3/../gcc -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv4tl/build-gcc/armv4tl-unknown-linux-gnueabi/libstdc++-v3/include/armv4tl-unknown-linux-gnueabi -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv4tl/build-gcc/armv4tl-unknown-linux-gnueabi/libstdc++-v3/include -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv4tl/gcc-core/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c /home/mcmechan/aboriginal-1.2.9/build/temp-armv4tl/gcc-core/libstdc++-v3/libsupc++/del_op.cc? -fPIC -DPIC -o del_op.o
Makefile:519: recipe for target 'del_op.lo' failed

armv5l failed:

armv5l-c++ -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv5l/gcc-core/libstdc++-v3/../gcc -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv5l/build-gcc/armv5l-unknown-linux-gnueabi/libstdc++-v3/include/armv5l-unknown-linux-gnueabi -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv5l/build-gcc/armv5l-unknown-linux-gnueabi/libstdc++-v3/include -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv5l/gcc-core/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c /home/mcmechan/aboriginal-1.2.9/build/temp-armv5l/gcc-core/libstdc++-v3/libsupc++/del_op.cc? -fPIC -DPIC -o del_op.o
Makefile:519: recipe for target 'del_op.lo' failed

armv6l failed:

armv6l-c++ -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv6l/gcc-core/libstdc++-v3/../gcc -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv6l/build-gcc/armv6l-unknown-linux-gnueabi/libstdc++-v3/include/armv6l-unknown-linux-gnueabi -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv6l/build-gcc/armv6l-unknown-linux-gnueabi/libstdc++-v3/include -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv6l/gcc-core/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c /home/mcmechan/aboriginal-1.2.9/build/temp-armv6l/gcc-core/libstdc++-v3/libsupc++/del_op.cc? -fPIC -DPIC -o del_op.o
Makefile:519: recipe for target 'del_op.lo' failed

i486 success:

i586 success:

i686 success:

m68k success:

mips failed:

mips-c++ -I/home/mcmechan/aboriginal-1.2.9/build/temp-mips/gcc-core/libstdc++-v3/../gcc -I/home/mcmechan/aboriginal-1.2.9/build/temp-mips/build-gcc/mips-unknown-linux/libstdc++-v3/include/mips-unknown-linux -I/home/mcmechan/aboriginal-1.2.9/build/temp-mips/build-gcc/mips-unknown-linux/libstdc++-v3/include -I/home/mcmechan/aboriginal-1.2.9/build/temp-mips/gcc-core/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c /home/mcmechan/aboriginal-1.2.9/build/temp-mips/gcc-core/libstdc++-v3/libsupc++/del_op.cc? -fPIC -DPIC -o del_op.o
Makefile:519: recipe for target 'del_op.lo' failed

mips64 failed:

mips64-cc -DHAVE_CONFIG_H -I. -I/home/mcmechan/aboriginal-1.2.9/build/temp-mips6
4/binutils/binutils -I. -D_GNU_SOURCE -I. -I/home/mcmechan/aboriginal-1.2.9/buil
d/temp-mips64/binutils/binutils -I../bfd -I/home/mcmechan/aboriginal-1.2.9/build
/temp-mips64/binutils/binutils/../bfd -I/home/mcmechan/aboriginal-1.2.9/build/te
mp-mips64/binutils/binutils/../include -DLOCALEDIR="\"/home/mcmechan/aboriginal-
1.2.9/build/native-compiler-mips64/share/locale\"" -Dbin_dummy_emulation=bin_van
illa_emulation?? -W -Wall -Wstrict-prototypes -Wmissing-prototypes -O2 --static 
?-c /home/mcmechan/aboriginal-1.2.9/build/temp-mips64/binutils/binutils/filemode.c
/bin/sh ./libtool --tag=CC --mode=link mips64-cc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -O2 --static??? -o size? size.o bucomm.o version.o filemode.o ../bfd/libbfd.la ../libiberty/libiberty.a? -lm 
libtool: link: mips64-cc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -O2 --static -o size size.o bucomm.o version.o filemode.o? ../bfd/.libs/libbfd.a ../libiberty/libiberty.a -lm
Makefile:652: recipe for target 'size' failed
make[4]: Leaving directory '/home/mcmechan/aboriginal-1.2.9/build/temp-mips64/build-binutils/binutils'

mipsel success:

powerpc failed:

powerpc-c++ -I/home/mcmechan/aboriginal-1.2.9/build/temp-powerpc/gcc-core/libstdc++-v3/../gcc -I/home/mcmechan/aboriginal-1.2.9/build/temp-powerpc/build-gcc/powerpc-unknown-linux/libstdc++-v3/include/powerpc-unknown-linux -I/home/mcmechan/aboriginal-1.2.9/build/temp-powerpc/build-gcc/powerpc-unknown-linux/libstdc++-v3/include -I/home/mcmechan/aboriginal-1.2.9/build/temp-powerpc/gcc-core/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c /home/mcmechan/aboriginal-1.2.9/build/temp-powerpc/gcc-core/libstdc++-v3/libsupc++/del_op.cc? -fPIC -DPIC -o del_op.o
Makefile:519: recipe for target 'del_op.lo' failed

sh4 success:

sparc failed:

sparc-c++ -I/home/mcmechan/aboriginal-1.2.9/build/temp-sparc/gcc-core/libstdc++-v3/../gcc -I/home/mcmechan/aboriginal-1.2.9/build/temp-sparc/build-gcc/sparc-unknown-linux/libstdc++-v3/include/sparc-unknown-linux -I/home/mcmechan/aboriginal-1.2.9/build/temp-sparc/build-gcc/sparc-unknown-linux/libstdc++-v3/include -I/home/mcmechan/aboriginal-1.2.9/build/temp-sparc/gcc-core/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c /home/mcmechan/aboriginal-1.2.9/build/temp-sparc/gcc-core/libstdc++-v3/libsupc++/del_op.cc? -fPIC -DPIC -o del_op.o
Makefile:519: recipe for target 'del_op.lo' failed

x86_64 failed:

x86_64-cc -DHAVE_CONFIG_H -I. -I/home/mcmechan/aboriginal-1.2.9/build/temp-x86_64/binutils/binutils -I. -D_GNU_SOURCE -I. -I/home/mcmechan/aboriginal-1.2.9/build/temp-x86_64/binutils/binutils -I../bfd -I/home/mcmechan/aboriginal-1.2.9/build/temp-x86_64/binutils/binutils/../bfd -I/home/mcmechan/aboriginal-1.2.9/build/temp-x86_64/binutils/binutils/../include -DLOCALEDIR="\"/home/mcmechan/aboriginal-1.2.9/build/native-compiler-x86_64/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation?? -W -Wall -Wstrict-prototypes -Wmissing-prototypes -O2 --static -c /home/mcmechan/aboriginal-1.2.9/build/temp-x86_64/binutils/binutils/filemode.c
/bin/sh ./libtool --tag=CC --mode=link x86_64-cc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -O2 --static??? -o size? size.o bucomm.o version.o filemode.o ../bfd/libbfd.la ../libiberty/libiberty.a? -lm 
libtool: link: x86_64-cc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -O2 --static -o size size.o bucomm.o version.o filemode.o? ../bfd/.libs/libbfd.a ../libiberty/libiberty.a -lm
Makefile:652: recipe for target 'size' failed
make[4]: Leaving directory '/home/mcmechan/aboriginal-1.2.9/build/temp-x86_64/build-binutils/binutils'



Macintosh G4 (Quicksilver 2002) PPC G4 (7450) 800MHz 512MB
gcc (Gentoo 4.8.3 p1.1, pie-0.5.9)
powerpc-unknown-linux-gnu

armv4eb failed:

? STRIP -x -R .note -R .comment libc/libc_so.a
? LD libuClibc-0.9.33.2.so
libc/libc_so.a(close.oS):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
collect2: ld returned 1 exit status
make: *** [lib/libc.so] Error 1

armv4l failed:

klogd (KLOGD) [Y/n/?] (NEW) n
logger (LOGGER) [Y/n/?] (NEW) n
/home/mcmechan/aboriginal-1.2.9/build/temp-armv4l/busybox/scripts/gcc-version.sh
: line 11: /home/mcmechan/aboriginal-1.2.9/build/cross-compiler-armv4l/bin/armv4l-gcc: cannot execute binary file
? SPLIT?? include/autoconf.h -> include/config/*
? GEN???? include/bbconfigopts.h
? HOSTCC? applets/usage
applets/usage.c: In function 'main':
applets/usage.c:52:8: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result]
? GEN???? include/usage_compressed.h
? HOSTCC? applets/applet_tables
applets/applet_tables.c: In function 'main':
applets/applet_tables.c:144:9: warning: ignoring return value of 'fgets', declared with attribute warn_unused_result [-Wunused-result]
? GEN???? include/applet_tables.h
? CC????? applets/applets.o
/bin/sh: /home/mcmechan/aboriginal-1.2.9/build/cross-compiler-armv4l/bin/armv4l-gcc: cannot execute binary file
make[1]: *** [applets/applets.o] Error 126
make: *** [applets_dir] Error 2

Exiting due to errors (armv4l simple-root-filesystem busybox)

armv4tl failed: same as armv4l above

armv5l failed: same as armv4l and armv4tl above

armv6l failed: same as armv4l, armv4tl and armv5l above

i486 failed: same as armv4l, armv4tl, armv5l and armv6l above

i586 failed: same as armv4l, armv4tl, armv5l, armv6l and i486 above

i686 failed: same as armv4l, armv4tl, armv5l, armv6l, i486 and i586 above

m68k sucess:

mips success:

mips64 success:

mipsel success:

powerpc success:

sh4 success:

sparc success:

x86_64 success:

Sun Ultra 60 UltraSPARCIIi 2x450Mhz 1GB
gcc (Gentoo 4.7.3-r1 p1.5, pie-0.5.5)
sparc-unknown-linux-gnu

armv4eb failed:

? STRIP -x -R .note -R .comment libc/libc_so.a
make[1]: `lib/ld-uClibc.so' is up to date.
? LD libuClibc-0.9.33.2.so
libc/libc_so.a(close.oS):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
collect2: ld returned 1 exit status

armv4l failed:

klogd (KLOGD) [Y/n/?] (NEW) n
logger (LOGGER) [Y/n/?] (NEW) n
/home/mcmechan/aboriginal-1.2.9/build/temp-armv4l/busybox/scripts/gcc-version.sh
: line 11: /home/mcmechan/aboriginal-1.2.9/build/cross-compiler-armv4l/bin/armv4
l-gcc: cannot execute binary file
? SPLIT?? include/autoconf.h -> include/config/*
? HOSTCC? applets/usage
applets/usage.c: In function 'main':
applets/usage.c:52:8: warning: ignoring return value of 'write', declared with a
ttribute warn_unused_result [-Wunused-result]
? GEN???? include/bbconfigopts.h
? HOSTCC? applets/applet_tables
applets/applet_tables.c: In function 'main':
applets/applet_tables.c:144:9: warning: ignoring return value of 'fgets', declared with attribute warn_unused_result [-Wunused-result]
? GEN???? include/usage_compressed.h
? GEN???? include/applet_tables.h
? HOSTCC? applets/usage_pod
applets/usage_pod.c: In function 'main':
applets/usage_pod.c:74:3: warning: format not a string literal and no format arguments [-Wformat-security]
? CC????? applets/applets.o
/bin/sh: /home/mcmechan/aboriginal-1.2.9/build/cross-compiler-armv4l/bin/armv4l-gcc: cannot execute binary file
make[1]: *** [applets/applets.o] Error 126
make[1]: *** Waiting for unfinished jobs....
make: *** [applets_dir] Error 2

Exiting due to errors (armv4l simple-root-filesystem busybox)

armv4tl failed: same as armv4l above

armv5l failed: same as armv4l and armv4tl above

armv6l failed: same as armv4l, armv4tl and armv5l above

i486 failed: same as armv4l, armv4tl, armv5l and armv6l above

i586 failed: same as armv4l, armv4tl, armv5l, armv6l and i486 above

i686 failed: same as armv4l, armv4tl, armv5l, armv6l, i486 and i586 above

m68k? success:

mips success:

mips64 success:

mipsel success:

powerpc success:

sh4 success:

sparc success:

x86_64 success:

 		 	   		  
 1415978217.0

From scsijon at lamiaworks.com.au  Thu Nov 20 09:50:47 2014
From: scsijon at lamiaworks.com.au (scsijon)
Date: Thu, 20 Nov 2014 20:50:47 +1100
Subject: [Aboriginal] ?adding packages
Message-ID: <546DB977.3030900@lamiaworks.com.au>

Rob, just a queery that i'm reading it right!

If I want to add a couple of extra packages to my aboriginal build to 
extend it, can I take it I just need to add them into the download.sh 
and the build.sh deals with it from there, or is there a better way?

thanks
jon

 1416477047.0

From rob at landley.net  Thu Nov 20 17:10:05 2014
From: rob at landley.net (Rob Landley)
Date: Thu, 20 Nov 2014 11:10:05 -0600
Subject: [Aboriginal] testing on a variety of platforms
In-Reply-To: <COL125-W249B1C6E8A9F096E57B0B6E28C0@phx.gbl>
References: <COL125-W249B1C6E8A9F096E57B0B6E28C0@phx.gbl>
Message-ID: <546E206D.9010804@landley.net>

On 11/14/14 09:16, James McMechan wrote:
> compile results from my current test setup
> unless I messed up these were all built from the aboriginal-1.2.9.tar.bz2
> with no changes to the config

Sorry for the delay, I cut a toybox release last night and now I'm
working on an aboriginal linux release using it, aimed at the end of the
month. (Trying to catch up with the kernel before _they_ get another
release out and I fall further behind...)

> host x86_64 armv6 armv5 ppc SPARC
> target
> armv4eb F       F       F      F     F
> armv4l    S       F       F      F     F
> armv4tl   S       S       F      F     F
> armv5l    S       S       F      F     F
> armv6l    S       S       F      F     F
> i486       S       S       S      F     F
> i586       S       S       S      F     F
> i686       S       S       S      F     F
> m68k     S       S       S      S     S
> mips      S       F       F      S     S
> mips64  S       F       F      S     S
> mipsel   S       S       S      S     S
> powerpc S       F       F      S     S
> sh4       S       S       S      S     S
> sparc    S       F       F      S     S
> x86_64  S       F       F      S     S

It looks like many of them are actually the same error. I'll try to take
a look this weekend.

> 
> What I find interesting is that the only archs that compile consistantly are
> m68k, mipsel, sh4 needless to say these are not what I would call the

I not that m68k is _now_working_, at least with Laurent Vivier's
qemu-m68k fork in the q800 branch. (Not sure I've checked the changes in
yet, but... working on it.)

Alas, it's a bit like sh4 in that it only has 128 megs of ram instead of
256, so if you try to build linux from scratch under it the ./configure
stage triggers the OOM killer. (I should extend the init script to set
up a swap file if there isn't enough memory...)

Thanks for the heads up, I'm not ignoring you just juggling many balls.

Rob

 1416503405.0

From rob at landley.net  Thu Nov 20 17:11:11 2014
From: rob at landley.net (Rob Landley)
Date: Thu, 20 Nov 2014 11:11:11 -0600
Subject: [Aboriginal] ?adding packages
In-Reply-To: <546DB977.3030900@lamiaworks.com.au>
References: <546DB977.3030900@lamiaworks.com.au>
Message-ID: <546E20AF.5060104@landley.net>

On 11/20/14 03:50, scsijon wrote:
> Rob, just a queery that i'm reading it right!
> 
> If I want to add a couple of extra packages to my aboriginal build to
> extend it, can I take it I just need to add them into the download.sh
> and the build.sh deals with it from there, or is there a better way?
> 
> thanks
> jon

You can do that, but the build control images are designed to let you
natively build additional packages under qemu.

http://landley.net/aboriginal/control-images

The static-tools.hdc builds a couple packageas and uploads them to the
host. The lfs-bootstrap.hdc snapshots the root filesystem into a
writeable chroot and then builds and installs a _lot_ of packages into
it, tarring up the resulting directory and uploading that to the host.

I did a big presentation on the design ideas behind all this a few years
back:

https://speakerdeck.com/landley/developing-for-non-x86-targets-using-qemu

Maybe I should do podcasts or something explaining this. I try to
document but there's a lot of reading to understand all of it...

Rob

 1416503471.0

From stephen.n.turner at gmail.com  Wed Nov 26 14:49:46 2014
From: stephen.n.turner at gmail.com (stephen Turner)
Date: Wed, 26 Nov 2014 09:49:46 -0500
Subject: [Aboriginal] GCC 4.2.1 bug
Message-ID: <CAA7aPHggNByj=kH0xPNB9qE2=g-R7VyNvZkskgC3fGfC7E3qYw@mail.gmail.com>

I dont know who is using gcc 4.2.1 anymore besides me, and some of you will
be aware of this bug im sure but while i was compiling gcc-4.2.1 I ran int
a error with linux-unwind.h and as it turns out you have to patch the
header to compile without newlib support. For anyone interested i am
copying over the link and patch. this is only for i386 as that is all im
using and all i found thus far.

http://forge.ispras.ru/issues/4295

diff --git a/libgcc/config/i386/linux-unwind.h
b/libgcc/config/i386/linux-unwind.h
index f17a46c..33810c5 100644
--- a/libgcc/config/i386/linux-unwind.h
+++ b/libgcc/config/i386/linux-unwind.h
@@ -139,9 +139,9 @@ x86_fallback_frame_state (struct _Unwind_Context *context,
    {
      struct rt_sigframe {
       int sig;
-      struct siginfo *pinfo;
+      siginfo_t *pinfo;
       void *puc;
-      struct siginfo info;
+      siginfo_t info;
       struct ucontext uc;
      } *rt_ = context->cfa;
      /* The void * cast is necessary to avoid an aliasing warning.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20141126/c8169586/attachment.htm>