Set -no_weak_imports linker flag for Xcode 8 on OS X 10.11

[achivetta]

See #2674 for some background, but the gist of it is this:

When building on OS X 10.11 with Xcode 8 against the macOS 10.12 SDK, you'll see the symbols added in macOS 10.12 e.g. clock_gettime and getentropy. This will cause many autoconf using projects to enable code that uses them. The built products will then fail with dynamic linker errors at runtime because the symbols aren't available on the 10.11 host system.

Xcode 8 beta 4 adds a new linker flag -no_weak_imports that will cause the linker to:

• fail to link if the link would be a leak link. (This happens when you use the Apple-supplied headers and they indicate the symbol was added after your current deployment target.)
• respect (new in Beta 4) $ld$weak$ symbols that indicate the OS version the symbol was added in, failing if it is newer than the supplied OS.

Homebrew should consider adding -Wl,-no_weak_imports to the LDFLAGS by default to enable this behavior, since it's almost always the desired behavior when building to run locally. Or, at least, it should be adopted those formula not currently building correctly in the Xcode 8 + 10.11 configuration. (e.g. xz and python)

[MikeMcQuaid]

Could you note this in #1957? Would be interested in @mistydemeo and @DomT4's opinions, too.

[DomT4]

It sounds perfectly sane to me, but I'll defer to @mistydemeo who is far more comfortable with compilers than I am if Misty has a differing opinion.

[mistydemeo]

I think this is a good idea, I'd like to apply this when Xcode 8 or later is installed (regardless of OS version).

[MikeMcQuaid]

Makes sense to me too 👍. Probably worth doing in both stdenv and superenv.

[AmirIHz]

Homebrew should consider adding -Wl,-no_weak_imports to the CFLAGS by default

Shouldn't it be added to LDFLAGS?

[achivetta]

@AmirIHz Yes, I believe you are correct there. I've updated the problem description accordingly.

[AmirIHz]

@achivetta 👍

[MikeMcQuaid]

Implemented in Homebrew/brew#721. Thanks for the clearly phrased issue, @achivetta, made it easy to implement.

[DomT4]

Breaks go on 10.12. Have reported upstream: golang/go#16770

[ylatuya]

I can't comment in the original issue #2674, so I'll do it here.

As a side note for those digging into the issue, the main problem is that Apple is incorrectly using their own availabilty checks. For example in time.h, clock_gettime is defined this way:

__CLOCK_AVAILABILITY
int clock_gettime(clockid_t __clock_id, struct timespec *__tp);

While it should be defined this way:

__CLOCK_AVAILABILITY int clock_gettime(clockid_t __clock_id, struct timespec *__tp);

In the second case, the compiller correctly undefines the clock_gettime function when using -macosx-version-min=10.7 whith a lower version than 10.12 and all configure checks would fail as expected.

[achivetta]

@ylatuya I'm not sure I follow. You are saying having a new line after the availability attribute before the return type causes issues for you? Or is there some other difference I'm not seeing?

In either case, availability checks have never undefined the symbols — they just cause the import to be a weak link. (Hence the need for the -no_weak_link option.)

[ylatuya]

@achivetta For one moment I though it was just an issue with the attribute position, but it's not... I was testing too many things at the same time. I now understand how the availability attributes work, sorry for the noise

[MikeMcQuaid]

I can't comment in the original issue #2674, so I'll do it here.

A general note that if we lock issues like that it's because people are posting stuff that's not relevant to Homebrew on them and, kindly, that's not an invitation to post the same elsewhere. Thanks!

[ePirat]

@achivetta I am facing a similar problem using the 10.12 SDK to compile VLC and its dependencies. I tried your suggestion adding -Wl,-no_weak_imports but that has no effect on the checks done by autotools ./configure.
Compiling one of the test programs it uses for the AC_CHECK_FUNCS checks, using the -no_weak_imports option still succeeds.

This is how I compiled it:

xcrun cc -mmacosx-version-min=10.7 -Wl,-no_weak_imports -Wl,-macosx_version_min,10.7 conftest.c -o conftest

Because it succeeds, the tests are all ok but later on, when the actual program is linked, it fails due to the -no_weak_imports option.

Right now as a workaround I just continue using the 10.11 SDK, spent a whole day trying different suggestions, none of them working.

[achivetta]

@ePirat Does it work if you pass 10.11?

If so, this is expected: the -no_weak_imports option was intended to resolve issues building open source software for use on your own machine so we only added hints for one release back, since that's as far back as Xcode goes. (By hints I mean the $ld$weak$ symbols that hint to the linker to force weak-linkage when autoconf uses its own function declaration instead of the one from the SDK.)

If not, then there's some other bug you are hitting: please file a radar and let me know the number. It's absolutely intended that the autoconf check fails when targeting 10.11. (Edit: Also, please try 10.11 plus moving aside usr/lib/system/libsystem_c.tbd in your SDK.)

[ePirat]

@achivetta Why would it not work with 10.7 as target, given that 10.7 is even older than 10.11?
It's afaik not possible (?) to set a different target just for the tests and not the actual program itself, so this would not help me much as I need to target 10.7 and not 10.11.

Anyway I tried compiling the test program targeting 10.11:

xcrun cc -mmacosx-version-min=10.11 -Wl,-no_weak_imports -Wl,-macosx_version_min,10.11 conftest.c -o conftest

and it still succeeded.

When moving away libsystem_c.tbd it failed:

$ xcrun cc -mmacosx-version-min=10.11 -Wl,-no_weak_imports -Wl,-macosx_version_min,10.11 conftest.c -o conftest
Undefined symbols for architecture x86_64:
  "_mkostemp", referenced from:
      _main in conftest-4bebc0.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[MikeMcQuaid]

@ePirat Your issue seems unrelated to Homebrew so please discuss it elsewhere, thanks.

[ePirat]

@MikeMcQuaid Sure. It affects many packages in Homebrew that are autotools-based and use such tests, so I thought I would bring up that problem here, but you are right that it's not really related to Homebrew and I will continue this elsewhere, sorry.

[MikeMcQuaid]

@ePirat That's ok, thanks for the apology ❤️