[OSX] does a toolchain need to support NPTL for OM?

[Dr. H. Nikolaus Schaller]

Am 08.01.2009 um 20:26 schrieb Christopher Friedt:

> a) The FR supports NTPL, but I wouldn't actually suggest trying to use
> anything else, be it linuxthreads or some 3rd party threading lib.

Ok, so the easiest approach could be to simply leave out NPTL from the  
toolchain instead of fighting to get it built.

> b)
>
> It's possible to build glibc-2.3.6 with nptl, but you need (quite) a
> few patches.
>
> Unfortunately, you will likely find that anybody who builds glibc
> (where >= 50 patches are needed) will likely refer you to some sort of
> build system, whether it's OpenEmbedded or not.

Yes - in fact I am developing a build system that really runs on a Mac  
and building toolchains is only part of it. Other parts are cross- 
compiling libs and apps for the embedded target.

It already works quite well to build mips-linux-gnu or i486-linux-gnu  
toolchains and now needs to be extended to other targets, i.e. the  
Freerunner arm-linux-gnueabi.

Basically, the directory

glibc-2.3.6/nptl/sysdeps/unix/sysv/linux/arm/bits does not exist where  
glibc make searches for semaphore.h

> That being said, I'm going to refer you to Portage :)
>
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-libs/glibc/glibc-2.3.6-r5.ebuild?view=markup

Can this be installed on a Mac?

Nevertheless this is a very good recource to look what they are doing.
Interestingly my approach is less than 10% (but may not cover all  
exceptions and specialities).

> Note that IUSE contains "nptl nptlonly", which means that you can
> build glibc to use native posix-level threads, and possibly so that it
> only supports native posix level threads. ARM support is also patched
> in. When building, I would USE="nptl nptlonly".
>
> You will need to basically inspect the ebuild (and whatever eclasses
> it derives from) in order to determine which patches to incorporate.
> Keep your eye on the SRC_URI variables as well as anything that
> resembles a URI.

Ok, I will search through it. The .ebuild itself does not show any ARM  
specific patching and want_nptl() even returns 1 (failure).

> I've never been successful building an apple -> arm cross compiler,
> although I have tried a few times, incidentally also with glibc-2.3.6,
> in order to build a cross compiler for the TS-7xxx series of SBC's. I
> had ssh access to my colleague's macbook, and was targetting
> arm-softfloat-linux-gnueabi.

That is what I am also targeting...

What I did have for years was an arm-hardfloat-linux-gnu (gcc 2.95.3  
with OABI) but that is too old for modern ARM code...

> Good luck, and please post any successful results that you have!

Yes, I will certainly do!

Thanks for the prompt answer and I will bother the list with more  
questions :)

Nikolaus

>
>
> Chris
>
> On Thu, Jan 8, 2009 at 12:58 PM, Dr. H. Nikolaus Schaller
> <hns at computer.org> wrote:
>> Hi,
>> I am in the process of building a native crosstoolchain for the
>> Freerunner to do some Objective-C development that runs natively on a
>> Mac OS X (Darwin).
>>
>> Currently I am sitting at the issue that glibc-2.3.6 with NPTL has no
>> support for ARM processors and I thought that every kernel since 2.5
>> needs NPTL.
>>
>> So my questions - where I hope someone can help:
>> a) does the FR need or support NPTL for ARM?
>> b) where can I find a patch to include in glibc-2.3.6?
>>
>> Nikolaus
>>
>> PS: There is no need to refer to crosstools or Open Embedded since
>> neither one works on Darwin.
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel at lists.openmoko.org
>> https://lists.openmoko.org/mailman/listinfo/devel
>>