Keep 32-bit build support on Mojave
Rainer Müller
raimue at macports.org
Wed Oct 24 22:30:30 UTC 2018
On 2018-10-24 23:53, Joshua Root wrote:
> On 2018-10-2 08:50 , Joshua Root wrote:
>> Second, I'm not sure about changing the SDK only some of the time, or
>> not changing the deployment target. We've always recommended changing
>> the deployment target for an entire installation globally if it's going
>> to be changed, and Apple only supports using a deployment target <= the
>> SDK being used. If it was only the i386 slices that were built against a
>> different SDK, that would be different, but the x86_64 slices of
>> universal builds will also be built against a different SDK than
>> non-universal x86_64 ports. A non-universal port built against the 10.14
>> SDK could thus end up linked with a universal port built against the
>> 10.13 SDK.
>
> What if instead of using the 10.13 SDK, we create a port for a universal
> 10.14 SDK? The only thing preventing the 10.14 SDK from being used for
> universal builds is the .tbd files, which list only x86_64 for the
> architectures of all the libs. They are YAML I believe, or certainly
> some form of plain text, and so can easily be edited.
If I remember correctly, the way it works on older macOS versions is
that ld is invoked with a -syslibroot argument pointing to the SDK,
which causes ld to search in that path, where it finds the .tbd, before
even looking in the regular paths for .dylib files.
Is this still the case on 10.14 or is this now hardcoded in ld itself?
Something like this to get things started:
echo '#!/bin/sh'$'\n''echo "$@"'$'\n''exit 1' > ld
chmod +x ld
clang -fuse-ld=$PWD/ld -o foo foo.c
Maybe we could use a wrapper for ld that ignores that argument or
replace all -lfoo references with absolute paths to libfoo.dylib?
Rainer
More information about the macports-dev
mailing list