Re: Darwin target

[Ray Donnelly <mingw dot android at gmail dot com>]

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.

> If so, why bother with autotooling such a big package?

Well, it's already done (years ago by the OpenDarwin project - I just
updated it); I know 'it's already done' isn't a technical argument,
but I also think it was technically a reasonable choice. The autotools
patch allows cctools to be built on Linux, Windows and Darwin. Sure it
could be switched out for some other cross platform build system but I
fear we'd end up re-implementing something very similar to autotools.
I'm not a big fan of autotools but it serves a useful purpose and I've
not really familiar with cmake which is AFAIK the only viable
alternative - in future I'd like to see how well qbs performs for this

Further patching would end up uglier I think, especially if other host
platforms were to be added later, compared to the orthogonal tests and
config.h generated by autotools. With simple #if __linux__ statements
everywhere we'd still run into problems with for example, glibc
versions providing different features and function prototype
differences between different c libraries (qsort_r was an issue here -
the glibc guys reordered the parameters from BSD-land for no good
reason that I can think of, other than to annoy people).

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.

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

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)

Cheers,

Ray.

On Wed, Nov 14, 2012 at 8:36 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Ray, All,
>
> On Wednesday 14 November 2012 Ray Donnelly wrote:
>> 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.
>
> Why do we not use that plain Makefile, then?
> Can we make it to work with minimal effort: patching and/or environment
> variables?
> If so, why bother with autotooling such a big package?
>
>> 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!
>
> Sorry, I'm a bit at loss, here... For each of the following statements, say
> whether it is true or false:
>
> Statements                                            | True or False |
> ------------------------------------------------------+---------------+
> cctools' linker can link 32-bit objects               |               |
> cctools' linker can link 64-bit objects               |               |
> cctools' linker can be built on 32-bit systems        |               |
> cctools' linker can be built on 64-bit systems        |               |
> cctools' is distributed as binary-only                |               |
> ------------------------------------------------------+---------------+
> ld64 can link 32-bit objects                          |               |
> ld64 can link 64-bit objects                          |               |
> ld64 can be built on 32-bit systems                   |               |
> ld64 can be built on 64-bit systems                   |               |
> ld64 is distributed as binary-only                    |               |
> ------------------------------------------------------+---------------+
> ld64 replaces cctools' linker in your /merge/         |               |
> cctools' linker will not be used for Darwin in ct-ng  |               |
>
>> There's a few other bits and pieces merged in, e.g. libprunetrie which
>> is used for dead code stripping.
>
> Is libprunetrie mandatory?
> Can we make it a companion library?
>
>> There's also dependencies on OpenSSL and an old version of llvmCore
>> but there's no reason to merge these.
>
> Wait, you mean dependency on OpenSSL is not mandatory?
>
> Basically, I'd like that whatever is *not* mandatory not be added in
> the first submission, to lower the cost of review and inclusion.
>
> Whether we add them later or not, will have to be discussed later.
>
> 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