Re: Help with Building toolchain with crosstool-ng on Mac OS X 10.6.2 (Snow Leopard)

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Titus, All,

On Monday 01 February 2010 03:25:56 tvb377@gmx.de wrote:
> here is the reworked patch for crosstool-ng on FreeBSD and MacOS

This patch is still very large, and contains unrelated changes.
It is thus hard to see the implications of each change.

Please, split the patch into self-contained patches that each add a
single change, as I suggested ealier. For example:
- the sed->$(sed) change in samples.mk on its own
- the configure+Makefile.in changes into their own (one for libtool, one
  for objcopy, ...)
- one for Darwin/*BSD vs. GNU
- and so on...

Having each change in a separate patch will help with review. Small patches
(few-liners) will most probably pass in a blink of an eye. When they get
applied, they will each yield a new changeset in the tree, and that would
be easier to revert the one(s) that is(are) faulty without having to revert
the whole stuff.

Also, if you would provide mercurial patches, it would be easier to work
with. See docs/overview.txt, section "Contributing".

> And two new READMEs (instead of docs/MacOS-X.txt).

Good. :-)

> Almost all patch parts revolve around GNU/BSD incompatibilities.
> I try to explain what I did:
> - enlarge the list of configurable tools that ctng uses (for usage of
> GNU tools).
> - also make sure that the configured tools actually get used.

One patch per new tool, please. Also, be sure to see how it plays with
the companion tools that were recently added.

> - make all calls to stat(1) dependent to `uname -s` or replace the call.

One patch for that.

> - replace all calls to readlink(1GNU) with compatible variants.

"readlink -e" and "readlink" are not equivalent.

>   This makes the usage of wrapper.c mandatory on MacOS because there is
>   no way known to me emulating readlink -m without a lengthy shell script.

Separate patch for that.

> - uname -o is not portable. use -s when -o fails

Ditto.

> - a bug in the sed-expression that sets the nanoseconds to 0 for a
>   date(1) not handling %N

On my system (%Q is not recognised, so use that)
  > date +%Q
  %Q

So this change seems to imply that on MacOS-X or *BSD, we get:
  > date +%N
  N

Right?

> Notable other reasons besides GNU/BSD are:
> - have to compile mpfr with --disable-thread-safe on darwin.

Separate patch for that as well.

> - "You did not specify the build system. That's OK, I can guess...":
>   Under MacOS 10.6 gcc reports itself as "i686-apple-..."
>   However, it's default behaviour is to generate 64bit objects.
>   This clashes with some configure scripts that require "x86_64-..." for
>   configuring for a 64bit host.
>   Using CT_DoConfigGuess does the job correctly.
>   Why not use that in general?

Not reliable on my system:
  > config.guess
  x86_64-unknown-linux-gnu
  > gcc -dumpmachine
  x86_64-linux-gnu

And I have the tools for x86_64-linux-gnu-{gcc,ld,...}, but not the ones for
x86_64-unknown-linux-gnu-{gcc,ld,...}. So it is much more reliable to ask
gcc than to ask config.guess.

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.

> BTW, the above two changes are the only changes actually for BUILDING the
> toolchain, and not for porting ctng itself.
> - the compiler command line options for compiling wrapper.c crashes gcc
>   on MacOS (and IMHO were a little bit overdone for the complexity of
>   wrapper.c).

Separate patch for that.

> - you should not link statically on MacOS (wrapper.c command line again)

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

> - under Darwin, use DYLD_LIBRARY_PATH in wrapper.c

Separate patch for that as well.

> - added printenv to the build.log (I found that helpful).

Separate patch.

> I can now compile gcc4.4.2 for powerpc for linux/glibc under Linux, BSD,
> and MacOS. I only shortly grepped through scripts not necessary for this
> configuration, so more incompatibilities may arise. However, they should
> be easy to fix in this manner.

Please, provide a split-up patchset as instructed above, and we'll be
able to easily review it.

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