Building toolchain with crosstool-ng on Mac OS X 10.6.2 (SL) - libtool error

Uwe Papengut
Tue Feb 2 15:18:00 GMT 2010

Hi Titus, Yann and all,

I wrote a short script for MacOS SL and crosstool-ng-1.6.0. I got an error with libtool, because the crosstool-ng/configure wrote:

  Checking for 'libtool'... no
  libtool 1.5.26 or above was not found

I used the newest version of libtool 2.2.6b_0. Script and log-file see attachment.

Can anyone please help me?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: MacOS_SL
Type: application/octet-stream
Size: 851 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MacOS_SL.log
Type: application/octet-stream
Size: 2795 bytes
Desc: not available
URL: <>
-------------- next part --------------

Best Regards,

Am 01.02.2010 um 03:25 schrieb

>>> I recently made a patch for using crosstool-ng on mac and freebsd.
>>> I will rework the cosmetics according to Yann's comments this month.
>> Titus, I think you are the one that can handle this stuff, as you have a
> Uwe, Yann, all
> here is the reworked patch for crosstool-ng on FreeBSD and MacOS against a current (31 January 23:00 CET) version.
> And two new READMEs (instead of docs/MacOS-X.txt).
> 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.
> - make all calls to stat(1) dependent to `uname -s` or replace the call.
> - replace all calls to readlink(1GNU) with compatible variants.
>  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.
> - uname -o is not portable. use -s when -o fails
> - a bug in the sed-expression that sets the nanoseconds to 0 for a date(1) not handling %N
> Notable other reasons besides GNU/BSD are:
> - have to compile mpfr with --disable-thread-safe on darwin.
> - "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?
> 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).
> - you should not link statically on MacOS (wrapper.c command line again)
> - under Darwin, use DYLD_LIBRARY_PATH in wrapper.c
> - added printenv to the build.log (I found that helpful).
> 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.
> Hope this helps.
> Further comments are welcome.
> Regards
> Titus
> <ct-ng-bsdpatch.txt><README.freebsd><README.macos>

-------------- next part --------------
For unsubscribe information see

More information about the crossgcc mailing list