[sdl2] Build failure on macOS

[njakob]

Host Environment

• OS: macOS 11.6.6 (macos-11 on GitHub actions)
• Compiler: GNU 10.3.0 / AppleClang 13.0.0.13000029

To Reproduce
A minimal setup could be found in the following repository.

• Working setup with 14e7bb4 (vcpkg 2022.05.10)
• Working setup with 0cf5b43 (just before [sdl2] update to 2.0.22 #24694)
• Failing setup with 5e7cbdc (including [sdl2] update to 2.0.22 #24694)

Failure logs

  Undefined symbols for architecture x86_64:
    "___isPlatformVersionAtLeast", referenced from:
        _IOS_JoystickInit in libSDL2.a(SDL_mfijoystick.m.o)
  ld: symbol(s) not found for architecture x86_64

Additional context

First of all, the issue described in this report does not appear when AppleClang (default compiler) is exclusively used. Therefore, it's possible that I'm not configuring something properly in the setup I'm describing below.

The issue happens when g++ (GNU 10.3.0) is used along with AppleClang (13.0.0.13000029) for the sdl2 port. This setup is required as AppleClang does not have the best support for c++20 features as other compilers. In my case, I'm building projects that include new language functionalities (e.g. concepts) and this fails when AppleClang is used.

Therefore, after playing around for a while, I managed to have a working setup where AppleClang is only used for a specific port and a custom toolchain file. Besides, g++ is used through CC and CXX environment variables for other cases.

This has been working very well until #24694. After the update to the commit providing this change, the linking error reported in the log section appeared.

Finally, the port got another update through #25022 which does not change anything to the reported error.

[LilyWangLL]

Thanks for posting this issue. I couldn't reproduce this issue locally, because my machine doesn't meet the conditions of this issue. I found there is a upstream PR fix architecture x86_64, could you help test the upstream PR: libsdl-org/SDL#5578. You could use --editable install sdl2, then modify the source files according to the upstream PR, then use --editable install sdl2 again.

[njakob]

Thank you for your answer @LilyWangLL!

Isn't libsdl-org/SDL#5578 only about adding different environments on CI builds?

Besides, let me ask you a different question then. Using GCC on MacOS is currently throwing errors when handling ObjectiveC code (see https://github.com/njakob/vcpkg-sdl2-report/tree/try-fix-2), would it rather be possible to keep the same compiler (GCC) end to end? Is it expected to use AppleClang for compiling the sdl2 ports?

I'm asking the question since compiling with AppleClang the whole project is working (see https://github.com/njakob/vcpkg-sdl2-report/tree/clang-only). Therefore, it might rather be related to my toolchain "hack" in order to use a wider range of C++20 features.

[njakob]

Since you mentioned good practices regarding ports respecting users' toolchains, should it be expected to use AppleClang while using SDL port @BillyONeal?

[BillyONeal]

Since you mentioned good practices regarding ports respecting users' toolchains, should it be expected to use AppleClang while using SDL port @BillyONeal?

Triplets need to be able to override the toolchain in use, but we aren't magic. If you build with a mishmash of implementations there's no guarantee that that's going to produce something reasonable.

[njakob]

My question was targeted toward the requirement of compiling the SDL2 port with AppleClang on macOS and ignoring the compiler provided by the toolchain/environment variables. Is this expected? @BillyONeal

At the moment, if a different compiler is provided (e.g. GCC), this will generate errors due to the ObjectiveC code.

Should then consider that the port would always need to be compiled with AppleClang and report to SDL2 the linking issue when using different compilers?

[BillyONeal]

My question was targeted toward the requirement of compiling the SDL2 port with AppleClang on macOS and ignoring the compiler provided by the toolchain/environment variables. Is this expected? @BillyONeal

Ports are not allowed to do that. Sometimes we miss attempts to do that in review. That doesn't make it OK.

At the moment, if a different compiler is provided (e.g. GCC), this will generate errors due to the ObjectiveC code.

That's OK. The requirement isn't that every port builds with every compiler ever. The requirement is that the port listens to what the user asked for. (Although, to be listed in our curated registry, it must build with the compilers we use for curation)

Should then consider that the port would always need to be compiled with AppleClang and report to SDL2 the linking issue when using different compilers?

Every project under the sun is not responsible for a few people who are extremely opinionated about the compiler that they use. Different compilers have different ABIs. Libraries cannot in general work around that situation. This is one of the big reasons we refuse to allow individual ports to control which tools are used.

[LilyWangLL]

Thanks for posting this issue. Please reopen this issue if this is still a problem for you.