Darwin target

Yann E. MORIN yann.morin.1998@free.fr
Wed Nov 14 23:42:00 GMT 2012


Ray, Yann, All,

On Thursday 15 November 2012 Ray Donnelly wrote:
> Hi Yann(s),

:-)

> > Why do we not use that plain Makefile, then?
> 
> The Makefile is very hardcoded to only work with Apple's compilers
> which are significantly modified from normal GCCs.

OK, fine. Let's settle for autotooling, then.
Thanks for the detailed explanation, BTW! :-)

> Here's the table, filled in with 1 note.
> 
> Statements                                            | True or False |
> ------------------------------------------------------+---------------+
> cctools' linker can link 32-bit objects               |    True (1)   |
> cctools' linker can link 64-bit objects               |     False     |
> cctools' linker can be built on 32-bit systems        |     True      |
> cctools' linker can be built on 64-bit systems        | Not Sure      |
> cctools' is distributed as binary-only                |     False     |
> ------------------------------------------------------+---------------+
> ld64 can link 32-bit objects                          |     True      |
> ld64 can link 64-bit objects                          |     True      |
> ld64 can be built on 32-bit systems                   |     True      |
> ld64 can be built on 64-bit systems                   |     True      |
> ld64 is distributed as binary-only                    |     False     |
> ------------------------------------------------------+---------------+
> ld64 replaces cctools' linker in your /merge/         |     True      |
> cctools' linker will not be used for Darwin in ct-ng  |     True      |
> 
> (1) cctools' linker is not maintained anymore. It's left around (I suspect) as
>     it supports PPC whereas ld64 probably hasn't been tested with PPC.

Very good. So, the answers for cctools' linker are of no relevance, as it's
not gonna be used. And ld64 makes our life easier. Good, good. :-)

> > Is libprunetrie mandatory?
> > Can we make it a companion library?
> 
> The dependencies on libprunetrie and openssl could be removed but I
> think the net result would be a bigger patch to remove these features.
> libprunetrie is *tiny*. openssl isn't of course.
> 
> cctools is comprised of a lot of different executables, and without
> having the needed libraries in-place, certain parts would just not
> build. Mostly these parts get called from the linker when certain
> options are specified, the failure would happen when the user tries to
> use those options.

OK.

Pulling in OpenSSL is not something that pleases me, however.
Let's revisit that later. I don't have enough context for now, I need
to see your patchset when it is more in shape.

Basically, the problem centers around the fact that it is not possible to
build a host-64-bit toolchain, thus the host must be a 32-bit host, or a
64-bit host with 32-bit libs.

On a 32-bit host, there is no issue: the libs are already there. Maybe the
devel packages are missing, but it is sensible to ask the user to install
those missing devel packages.

On a 64-bit host, we require that the 32-bit C library be installed,
otherwise we would not even be able to compile. What prevents us from
also requiring that the 32-bit version of OpenSSL (and libuuid) be also
installed?

Really, I'd rather had this as an external dependency on the host system,
rather than pull OpenSSL in. That really, *really* makes me uneasy... :-(

For the current comp-libs, that was not possible, they are not available,
even on not-so-old distros (Debian Squeeze does not have some of them, or
the versions are too old; not speaking of Debian Lenny, which is still
largely used in production, and lacks all of them). OpenSSL on the other
hand, has been widely available for quite some time now, and we can expect
even old distributions to package it.

I do not want crosstool-NG to become Yet Another Build System, and I want
it focused on building toolchains, and nothing more. If a dependency is
widely available out-side (even at the expense of a package install), then
I'd rather use that, unless proven that's not doable.

> You asked about things being distributed as binary only; the source
> code for all of Apple's toolchains are open source with the exception
> of one program (dsymutil which is only needed for debugging with
> certain Apple tools). The licenses used are:
> 
> APSL v2 (cctools),
> GPL (gcc, llvmgcc)
> UoI/NCSA (ld64, llvmgcc)
> UoI/NCSA/MIT (llvm, clang)

Thank you for the details.

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



More information about the crossgcc mailing list