Patches for crosscompiling on Mac OS X

[Titus von Boxberg]

Yann, all,

Am 09.11.2010 um 23:57 schrieb Yann E. MORIN:

> Titus, Geoffrey, All,
> 
> On Tuesday 09 November 2010 20:55:25 Titus von Boxberg wrote:
>> I see that host dependencies are difficult for the menuconfig.
>> But I think there should be a correction of this static linking setting
>> based on the host, just like I introduced it for the (now obsolescent?)
>> binary tool wrappers.
> 
> Well, I am not too found of letting the user set some stuff, and then
> silently overriding it. Let the option not be there in the first place
> if possible, and if not, then document the corner cases.
I didn't say "silently", and I did not mean it, either.
There should be an informational message.
And I do not follow entirely that the user sets something when it is the
default. As I understood Geoffrey he has experienced the problem because
currently the feature is "silently" enabled because the doc is missing
that it does not work for his case.

> 
> As for the tools wrapper, I really hope it is going away.
> 
> Now that distributions are coming up-to-speed wrt those libraries,
> we can see three possibilities:
> 
> 1) the distribution has those libs, in which case we'll get to use
>   whatever is provided by the distribtuion;
> 
> 2) the distribution does not have those libs, so we compile our own
>   versions, as static libs.
> 
> 3) the distribution does not have those libs, the user does not want to
>   link them staticaly, so (s)he is responsible for installing those
>   libs manually, so that they are available system-wide. But basically,
>   for crostool-NG, this is equivalent to 1).
> 
>> (Actually, I did not get yet why static linking is important, anyway...)
> 
> It helps when moving the toolchain to another machine, where the odds that
> the libstdc++ would be too different from the one you used when building
> the toolchain.
Is this a problem that anyone has already experienced?
Or is it just a guess?

> 
> I agree that moving a toolchain from one machine to a completely different
> one is asking for trouble in the first place. But the system libraries,
> such as libc.so, can be almost safely expected to be compatible. libstdc++
> on the other hand comes from the compiler, and is much less 'compatible'
> from [machine / gcc version] to another [machine / gcc version].
> 
> Hence the ability to link libstdc++ statically to the toolchain. That this
> is the default is arguably disputable.
I'd vote for dynamic linking being the default, see below.

> 
> Anyway, the real way to be able to safely move the toolchain to another
> machine is to have the toolchain entirely statically linked. But that
> will be coming soon: patches pending...
I'd say that moving the toolchain between machines with so wildly differing
installations that you could expect libstdc++ being incompatible is a less
desireable goal than to support the user on more host platforms in the first place.
I wouldn't expect to compile the toolchain on OSX 10.6 and then have the
binaries working on 10.4, or SUSE 11.2 and move it to, say, 10.0.

I'd recommend to keep ct-ng being able to build the same tools ON different
machines but not produce tool chains FOR different machines in one step.

Regards
Titus


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