[fpc-pascal] Linker fails cross compiling from Linux to Mac.

[Bruce Tulloch]

On Tue, Jan 8, 2013 at 9:04 PM, Jonas Maebe <jonas.maebe at elis.ugent.be> wrote:
>
> On 08 Jan 2013, at 10:49, Bruce Tulloch wrote:
>
> I had a working Debian Squeeze to Mac OSX Snow Leopard cross-
>
> What had changed when it stopped working?

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

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

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.