Darwin target

Ray Donnelly mingw.android@gmail.com
Wed Nov 14 12:36:00 GMT 2012


Hi guys,

The patch for cctools is currently looking fairly large, close to 2MB,
a lot of this is because the original source doesn't include autotools
support, instead offering just a plain Makefile.

Also, cctools includes an old linker which is fairly outdated (not 64
bit), and the new linker (ld64) is a separate project. Currently, my
toolchain4 merges this with cctools so that the autotools support work
is shared. Will this be an issue? The problem with keeping them split
up is that we'd have two large autoconf-adding patches instead of one!

There's a few other bits and pieces merged in, e.g. libprunetrie which
is used for dead code stripping.

There's also dependencies on OpenSSL and an old version of llvmCore
but there's no reason to merge these.

Cheers,

Ray.

On Wed, Nov 14, 2012 at 7:20 AM, Diorcet Yann <diorcet.yann@gmail.com> wrote:
> Le 14/11/2012 01:13, Yann E. MORIN a écrit :
>
>> Yann, All,
>>
>> On Wednesday 14 November 2012 Diorcet Yann wrote:
>>>
>>> Ray Donnelly and me have started to work on adding darwin target (OS X
>>> and iOS) in crosstool-ng.
>>> Currently, it's already working: you can create a toolchain (C,C++,
>>> Objective c) for OS X using XCode's SDKs.
>>> It's far to be done. Based on the Ray Donnelly's
>>> work(https://github.com/mingwandroid/toolchain4), we will add a better
>>> cctools/ld64 (binutils replacing for MACH-O).
>>> You can follow the progress on the following
>>> github:https://github.com/diorcety/crosstool-ng.
>>
>> OK, as promised on IRC, here's my initial review:
>>
>> 1) Split changes into smaller hunks.
>>
>>    a) fix the efl2flt config ('if BARE_METAL' --> '## depends on
>> BARE_METAL')
>>    b) ditto for the sstrip thingy
>>    c) add the EXTRA_{C,LD}FLAGS_FOR_{HOST,BUILD} config options
>>       - propagate to affected script, of course
>>    d) introduce the multi-binutils feature
>>       - don't add any new alternative, only the infrastructure to support
>>         multiple binutils
>>    e) introduce the /generic/ companion-libs build script
>>    f) add Darwin as a new kernel
>>       - depends on EXPERIMENTAL
>>       - propagate the "depends on !DARWIN" to affected components
>>    g) add cctools as alternate binutils
>>    h) you get the idea...
>
> I have just to split correctly my work..
>
>>
>>    Basically: one changeset introduces a minimal, self-contained,
>> semantically
>>    coherent change. See in your linux source tree:
>>      Documentation/SubmittingPatches: 3) Separate your changes
>>
>> 2) Patches in patches/compomnent/version
>>     - add an explanation at the top of the patch (if the reason is not
>> known
>>       but you got the patch from another source, point to that source)
>>     3) gcc Apple version
>>     a) no need to for the 'if CC_APPLE' test; just append the location for
>>        the Apple version to the existing list
>>     b) in gcc.sh, use 'if KERNEL == DARWIN' to check if the core compilers
>>        are needed; thus, no need for option CC_GCC_APPLE
>
> Ok it's not linked to the fact there is no LIBC? (LIBC_NONE)?
>
>> 4) Companion libs & tools
>>     - what is util-linux/libuuid required for?
>
> The crosstools have to be compiled in 32 bits (this is why there is the new
> flags EXTRA_{C,LD}FLAGS_FOR_{HOST,BUILD})
> The x86_64 system may not have libuuid 32 bits version (installed or even
> provided by distribution)
>>
>>     - ditto openssl?
>
> Openssl will be used by the linker in order to sign the produced binaries
> (it's the Ray Donnelly's domain)
>
>>
>> 5) patches/cctools/806/0001-nondarwin.patch
>>     - Whaoo... 2.3 MiB for a single patch... :-(
>>     - where's that patch coming from?  --> add origin at top of patch
>>     - why is it needed?  --> add (short) explanation at top of patch
>>     - can it be replaced by an equivalent patch series?
>
> It will be changed by the Ray Donnelly's work.
>
>>
>> Otherwise, the code looks pretty nice for a work-in-progress! :-)
>>
>> Regards,
>> Yann E. MORIN.
>>
>
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>

--
For unsubscribe information see http://sourceware.org/lists.html#faq



More information about the crossgcc mailing list