Split patch for Mac OS/ was Re: Help with Building toolchain with crosstool-ng on Mac OS X 10.6.2 (Snow Leopard)

[Yann E. MORIN]

Hello Titus, All,

On Wednesday 03 February 2010 00:24:24 tvb377@gmx.de wrote:
> Sorry, I'm quite new to mercurial. And I guess the last step in
> "Contributing" means it wants to send emails, which I cannot provide 
> on this machine here in reasonable time.

Yes, the patches would be mailed, and upon reception, it becomes really
trivial to re-aplly the patches, in the same sequence as they are applied
on your side, keeping authorship, date...

> > > - replace all calls to readlink(1GNU) with compatible variants.
> > "readlink -e" and "readlink" are not equivalent.
> No, but
> a) ct-ng does not use libs it searches for (here only ncurses) by itself.
> b) The variable where is dropped for libs, afaik. It is also
>    questionnable if you would actually need the shared object instead of
>    the link.
> c) I'm not aware of installations where links point to links 
>    [that point to links...] that point to shared objects.
>    Then the check could in theory fail when removing the -e

And we don't care if the user's system is borken. It's his/her burden
todetect such a case. Granted.

> > gcc -dumpmachine will tell us the tuple for which it was configured, and
> > that means the prefix to use to the actual tools, which is what we need.
> Hmm, I see the point. But apparently then there is an inconsistency here
> on Darwin, be it in the gcc configuration or the configure (I think it
> was of gmp) that failed.
> Anyway, my change only is for Darwin + BSD.

Yes, I saw. I was just explaining why we used gcc -dumpmachine in this case.

> > Statically linking should hopefully speed up things. Having a /slow/
> > wrapper is not very interesting, is it? Of course, the ratio
> > time-in-wrapper / (time-in-wrapper + time-in-actual-tool) should be
> > fairly small, except for very trivial programs, where the total time
> > will anyway be almost imperceptible...
> imho, statically linking will not buy you a measurable amount of time,
> especially not when linking only to such mundane things like libc that
> are guaranteed to be in core, anyway.

As a side note, I was looking at how libtool works. Jeez... Such a lot
of shell scripting just to call the compiler/linker. That's sad... :-(
So, yes, our wrapper should be blindly fast when compared to the
auto-stuff/libtool fuzz, and especially since libc.so is cached.

Besides, static wrapper: 5558KiB
         shared wrapper:   7KiB
Woot! Let's go shared! :-/

> > > - under Darwin, use DYLD_LIBRARY_PATH in wrapper.c
> > Separate patch for that as well.
> OK. Please note that this patch requires the above cmd line patch.

That's why a proper patchseries as prepared by 'hg email' is interesting:
the patch order is maintained.

> Hope it fits now for you. Please note that
> - all patches (except for build-mpfr and using config.guess)
>   are necessary to run crosstool-ng itself.
> - all are tested except the one in populate.in

OK, see my comments below...

> Sorry for the inconvenience that these are not mercurial-sent patches.

I'll deal with that, but it may take a bit longer...

OK, for the patches now:

--> build-mpfr-on-darwin.patch          applied
--> corrected-date-sed-expr.patch       applied
--> uname-portable.patch                applied
--> nice-to-see-all-envvars.patch       applied

--> wrapper-compile-commandline.patch
diff --git a/scripts/build/internals.sh b/scripts/build/internals.sh
--- a/scripts/build/internals.sh
+++ b/scripts/build/internals.sh
@@ -55,9 +55,8 @@
                 if [ "${CT_DEBUG_CT}" = "y" ]; then
                   _t="" # If debugging crosstool-NG, don't strip the wrapper
                 fi
-                CT_DoExecLog DEBUG "${CT_HOST}-gcc"                           \
-                                   -Wall -Wextra -Wunreachable-code -Werror   \
-                                   -O3 -static ${_t}                          \
+                CT_DoExecLog DEBUG "cc" -Wall -Wextra -Werror        \
+                                   -O -D$CT_SYS_OS ${_t}             \

You broke canadian-cross and cross-native: the wrapper will have to run on
the host, not on the build machine. So we must be using ${CT_HOST}-gcc
Besides, it's space-damaged at the end of lines (line up \).

--> whyclearCT_CFLAGS_FOR_HOST.patch
Well, let's be sure the variable is empty before we add to it (in case the
user already had it in the enviornment). Notice that we do:
  CT_CFLAGS_FOR_HOST+=blabla

I'll handle the rest of the patchset after FOSDEM, i.e. next week.

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