This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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?
Attachment:
MacOS_SL
Description: Binary data
Attachment:
MacOS_SL.log
Description: Binary data
Best Regards, Uwe Am 01.02.2010 um 03:25 schrieb tvb377@gmx.de: >>> 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>
-- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |