Re: Darwin target

["Yann E. MORIN" <yann dot morin dot 1998 at free dot fr>]

Yann, All,

On Wednesday 14 November 2012 Diorcet Yann wrote:
> Le 14/11/2012 01:13, Yann E. MORIN a écrit :
[--SNIP--]
> > 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)?

Well, I'm not sure that's the only case.

For MingW, we moved everything from the kernel into the C library script.
I wonder if it would make sense to do the same for Darwin: there is nothing
that is really provided by the 'kernel' part, but rather by the 'C library'.

In fact, the 'kernel' part is almost certainly only needed for Linux. AFAIK,
installing the 'kernel headers' is only needed for Linux. Other OSes do not
have that requirement. So, we should *not* try to emulate the Linux steps
for other OSes.

So, for Darwin, we'd still need to 'build' the C library (even if that's
only about installing the pre-compiled Darwin system libraries).

In this case, the core pass-1 and -2 are superfluous for:
  - no C library (CT_LIBC_none)
  - Darwin (CT_KERNEL_darwin)
  - others in the future?  (eg. *BSDs)

We'd need to have a single way to express that we require the core-pass-1
and core-pass-2 compilers. For example, something like:

    [in config/cc.in]
    # Select this from the C libraries that need to be compiled,
    # and thus require a compiler
    config CC_CORE_PASSES_NEEDED
        bool

    [in config/libc/glibc.in]
    ## select CC_CORE_PASSES_NEEDED

    [in config/libc/darwin.in]
    # We do not need to select CC_CORE_PASES_NEEDED

Then, in do_cc_core_pass_{1,2}, we can test ${CT_CC_CORE_PASSES_NEEDED} and
decide to build or not to build the core passes.

> > 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})

So, it is not possible to compile a 64-bit toolchain? What component
is at fault: apple-gcc or cctools?

> The x86_64 system may not have libuuid 32 bits version (installed or 
> even provided by distribution)

OK, that makes sense. Sad, though... :-(

> >     - ditto openssl?
> Openssl will be used by the linker in order to sign the produced 
> binaries (it's the Ray Donnelly's domain)

OK, I understand. However:
  - is it possible to produce unsigned binaries?
  - is it possible to sign unsigned binaries after-the-fact?

For example, is this possible:
    darwin-gcc -o ess ess.c     <-- produce an unsigned 'ess' executable
    darwin-sign -o ess.sig ess  <-- produce signed 'ess.sign' executable
                                    from unsigned 'ess'
?

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

OK, I'll read his reply.

Thank you!

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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