Titus von Boxberg
Fri Aug 19 20:56:00 GMT 2011
Am 19.08.2011 um 20:00 schrieb Yann E. MORIN:
> Titus, All,
> On Friday 19 August 2011 09:09:27 Titus von Boxberg wrote:
>> Am 19.08.2011 um 00:32 schrieb Yann E. MORIN:
>>> On Wednesday 17 August 2011 23:31:36 Titus von Boxberg wrote:
>>>> -static is not supported on Darwin.
>>> So -static is not supported on Darwin? So why on Earth does the ncurses from
>>> Macports install static versions of the libraries?
>> Passing -static is not equivalent to linking to an archive file.
> I know, but it seems to me that creating static libraries is possible on
> Darwin, and thus there would be a way to ask for staticaly linking an
There are 3 things intermixed here.
1) You can link to static libraries.
E.g. my software is built as static libs.
No problem to link them in. But see below.
2) You cannot produce a statically linked executable.
Actually, I do not know exactly why that is the case,
viewed on Mach-O bit level (and strange enough, that
lack of knowledge doesn't bother me ;-).
You always have to produce an executable that requires
the dynamic linker/loader combo to start a process from it.
Or the other way round: no program can be started without
the dynamic linker/loader.
A third thing comes in from this particular problem:
you cannot select a static lib when a dynamic lib is found
in the same path.
You have to play tricks to get that done, as given in
From `man ld`, and points 1) and 3) above results that the elf-ld
compatible command line … -static -lnicelib -dynamic -lblah … does not work.
The only ways to achieve the equivalent of this command line
would be to ensure that
- libnicelib is present only as an archive file but not as a dylib, or
- the linker search paths are made up as outlined in Apple's reference.
In short: Drop the idea of static linking as completely as possible on Darwin.
Time's a too precious resource for that crap.
> No, absolutely not. I'll learn to post-pone such mails in the future, so
> I can be in a more relaxed state before I post. Apologies to anyone who
> might have resenseted offense…
No offense taken. I just wanted to know whether you are restricting
ct-ng to Linux.
>> If the former, then why not simply tackle those problems and add a fix?
> Sure, sure. It's just that I am a bit lost here, as I do not have the
> slightest idea on how we should do things on Darwin.
?? The things I tested worked very well. No need to be pessimistic.
As I wrote early 2010, compared to old crosstool and earlier tool chains,
things went very smoothly and the patches necessary for BSD/Darwin
were ridiculously small.
Darwin, may it be idiosyncratic in this or the other way, still is a
UNIX compliant system.
I never tried uclibc, so I'm not surprised that problems arise.
In general (not only for Darwin) I'd say:
Try to be as much UNIX/Posix compliant as possible.
Do not use the more or less unnecessary GNU extensions.
At least within ct-ng this rule can be easily followed.
Where the problems following this rule outweigh the benefit,
add the GNU tool as a prerequisite.
> On the one hand, I'd rather not have ugly kludges in the code to handle
> Darwin, or we could see a proliferation of those kludges, not only for
> Darwin, but also other OSes. Think Cygwin and mingw for example, which
> have their own idiosyncracies and limitations in their own subtle ways.
What is a kludge, here? You can also view it the other way round.
If you use nonportable features of one platform (like static linking)
then this might be regarded as a kludge (just like I still regard it in this
particular case). After all, if I remember correctly, you introduced static linking
because you fear that (libstd)c++ undergoes ABI changes and the Linux distros
cannot handle that (which I feel is an absolutely legitimate concern,
nonetheless all this is an Evil Kludge from GNU Hell).
> On the other hand, I'd like to have support for as many systems as
> possible (World Domination, anyone? ;-)), while not being capable or
> able to get my hands on said systems.
I'm afraid that even World Domination has to be gained in small steps.
divide et impera.
For continuous support of host OSs other than linux, here Darwin,
I'd recommend that there is a set of configs identified
that are expected to work on that OS / Darwin.
I could add mine to that set.
Maybe rename samples directory into "samples-linuxhost", and
add other samples directories for the particular host OSs.
We already know (and Guylhem just experienced) the build
systems of the tool chain parts are only portable to a certain extent.
Introducing a host OS specific set of working examples
would mean that one cannot expect to have ct-ng
build any tool chain combination (in the general/linux samples directory)
out of the box on non-GNU/Linux systems, but there is at
least a (smaller) starting point the user can rely upon.
How do you handle it now with older configs that eventually break
on newer Linux host systems? Or with now more or less unsupported things
like OABI for ARM? Do you silently delete the samples as the older tool chain
parts get dropped from menuconfig?
Or just add a "deprecated/broken" note? Do you drop anything at all?
Just do it the other way round for Darwin/other OSs.
Furthermore, you might also add patches directories specific
to the host OS; then maybe patches (like mine for eglibc,
or the coming ones for uclibc) could be introduced more quickly
because there is no danger that things get broken on Linux.
Do you have scripts for regular automatic tests of the samples?
Then - if the tool chains working on Darwin are identified -
testing at least the build steps (omitting menuconfig et.al.)
could be done automatically.
Just an idea.
Anyway, Guylhem sent me his .config.
I'll try the next days to get things to work.
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc