I had a working Debian Squeeze to Mac OSX Snow Leopard cross- compilation system working. It's documented here:

http://wiki.freepascal.org/Cross_compiling_OSX_on_Linux

Unfortunately the method described on that page is now broken.

The problem linking for OSX on a Linux no longer works for me.

It produces errors like these:

i386-darwin-ld: MacOSX10.6.sdk/usr/lib/libiconv.dylib load command 5 unknown cmd field
i386-darwin-ld: MacOSX10.6.sdk/usr/lib/libobjc.dylib load command 7 unknown cmd field
i386-darwin-ld: MacOSX10.6.sdk/usr/lib/libc.dylib load command 5 unknown cmd field
i386-darwin-ld:
MacOSX10.6.sdk/System/Library/Frameworks/Carbon.framework/Carbon load command 4 unknown cmd field
i386-darwin-ld:
MacOSX10.6.sdk/System/Library/Frameworks/Cocoa.framework/Cocoa load command 4 unknown cmd field
i386-darwin-ld:
MacOSX10.6.sdk/System/Library/Frameworks/OpenGL.framework/OpenGL load command 5 unknown cmd field
i386-darwin-ld:
MacOSX10.6.sdk/System/Library/Frameworks/Foundation.framework/Foundation load command 6 unknown cmd field

Here's what I'm using:

1) FPC 2.6.2 rc1 (and I've tried 2.6.0 as well).
2) Apple's cctools 809 release suitably patched.
3) A Debian Wheezy Linux host.

The cctools-809 source comes from:

http://www.opensource.apple.com/tarballs/cctools/cctools-809.tar.gz

The patch applied to make it buildable for Linux is:

https://github.com/mingwandroid/xchain/blob/master/patches/cctools-809-nondarwin.patch

plus a few tweaks of my own to fix some build bugs.

It's built against MacOSX10.6.sdk (I've tried MacOSX10.5.sdk too) for 32 bit (-m32) builds (64 bit is not supported). FPC, FCL, LCL et al are all built against the same SDK. Compilation works just but linking fails as shown above.

I've tried various combination of compilation switches but nothing seems to allow the link to succeed.

Does anyone have a clue why this might be failing? I seems like I'm on the brink of success if only I can work out why these errors are occurring.

The most obvious thought is that not all objects were built against the same revision of the SDK but I can confirm they are. The missing command codes are (from MacOSX10.6.sdk/usr/include/mach-o/loader.h):

#define LC_THREAD 0x4 /* thread */
#define LC_UNIXTHREAD 0x5 /* unix thread (includes a stack) */ #define LC_LOADFVMLIB 0x6 /* load a specified fixed VM shared library */ #define LC_IDFVMLIB 0x7 /* fixed VM shared library identification */

I will give up on this if no one has any ideas and the wiki needs to be updated to report that cross-compilation from Linux to Mac is no longer possible but I'm willing to give it some more work based on pointers anyone can suggest.

Failing that I will revert to a native Mac system but I'd really like to have cross-compilation working if possible.

Any suggestions?

Bruce

What had changed when it stopped working?

This suggests that you are using a linker that is too old. Are you certain that the used i386-darwin-ld is the one you built from cctools-809? (compile with -Cn and look at the generated ppas.sh)

The most obvious thought is that not all objects were built against the same revision of the SDK but I can confirm they are.

That has no influence anyway. Objects are not really built against an SDK, only libraries and applications are. The SDK only affects the linking in case of Pascal (in case of C/C++, it also affects the compilation because of the used headers).

Jonas

I had to upgrade from Debian Sneeze to Wheezy (for other reasons) and the previously built odcctools linker (derived from the older cctools-758) required libraries no longer available in Wheezy which required that I rebuild it from source but the long dead odcctools source was no longer available so I rebuilt from Apple's upstream cctools-809 with the new patches.

This suggests that you are using a linker that is too old.

Should be okay, cctool-809 is 10.6 aware (the
get_macosx_deployment_target() function in the linker reports 10.6 when run).

Are you certain that the used i386-darwin-ld is the one you built from cctools-809?

Yep, I already checked this.

ppas.sh reports /usr/local/opt/cctools/bin/i386-darwin-ld which is correct.

The linker is built with this script (working in a repository I created):

#!/bin/bash

# Compilation parameters, adjust as required...

export TARGET=i386-darwin # OSX target (i386-darwin or x86_64-darwin) export SYSROOT=/usr/local/opt/osx/MacOSX10.6.sdk # OSX SDK root export CCTOOLS="809" # OSX cctools version (must be a patched for linux) export PREFIX=/usr/local/opt/cctools # build host installation directory

cd cctools # working repository

# Checkout revision and patch

hg update -C cctools-$CCTOOLS
hg -R $(hg root)/.hg/patches update -C cctools-$CCTOOLS hg qpush --all

# configure and build

autoconf && chmod +x configure
CFLAGS="-m32 -D__DARWIN_UNIX03" LDFLAGS="-m32" ./configure \ --prefix=$PREFIX \
--target=$TARGET \
--with-sysroot=$SYSROOT \
&& make && make install

# cleanup

hg update -C
hg qpop --all
hg clean

Thanks, understood. It's linking the application that presents the problem.

I've noticed that all errors except these two:

i386-darwin-ld:
MacOSX10.6.sdk/System/Library/Frameworks/Carbon.framework/Carbon load command 4 unknown cmd field
i386-darwin-ld:
MacOSX10.6.sdk/System/Library/Frameworks/OpenGL.framework/OpenGL load command 5 unknown cmd field

disappear IF I enable debug symbols when compiling. Don't know if this is a clue and it does not appear to matter which type of debug info I enable.

Bruce.

Any other thoughts as to what I should do or information I can provide to help diagnose this further? It would be a shame to loose the ability to cross compile to Mac. Bruce.