i686-w64-mingw32-winpthreads and x86_64-w64-mingw32-winpthreads : linker does not accept syslibroot

[eviltwinskippy (Sean Woods)]

When installing the mingw-w64 port, I ran across failures in the following dependencies:

Both i686-w64-mingw32-winpthreads and x86_64-w64-mingw32-winpthreads crashes on compile preventing mingw-w64. i686-w64-mingw32-gcc, and x86_64-w64-mingw32-gcc from installing.

The errors in both i686-w64-mingw32-winpthreads and x86_64-w64-mingw32-winpthreads are similar:

--->  Building i686-w64-mingw32-winpthreads
Error: Failed to build i686-w64-mingw32-winpthreads: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_cross_mingw-w64/i686-w64-mingw32-winpthreads/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port mingw-w64 failed

[eviltwinskippy (Sean Woods)]

Compile Log

[eviltwinskippy (Sean Woods)]

Results of make

[kencu (Ken)]

Haven't seen this error before. I guess this linker does not like -syslibroot:

info:build libtool: link: /opt/local/bin/i686-w64-mingw32-gcc -shared  src/.libs/libwinpthread_la-barrier.o src/.libs/libwinpthread_la-cond.o src/.libs/libwinpthread_la-misc.o src/.libs/libwinpthread_la-mutex.o src/.libs/libwinpthread_la-rwlock.o src/.libs/libwinpthread_la-spinlock.o src/.libs/libwinpthread_la-thread.o src/.libs/libwinpthread_la-ref.o src/.libs/libwinpthread_la-sem.o src/.libs/libwinpthread_la-sched.o src/.libs/libwinpthread_la-clock.o src/.libs/libwinpthread_la-nanosleep.o src/.libs/version.o   -L./fakelib -L/opt/local/lib  -Os -no-pthread -Wl,-headerpad_max_install_names -Wl,-syslibroot -Wl,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk   -o .libs/libwinpthread-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libwinpthread.dll.a
info:build /opt/local/lib/gcc/i686-w64-mingw32/8.2.0/../../../../i686-w64-mingw32/bin/ld: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk: file not recognized: Is a directory

[kencu (Ken)]

Now I think that if the command lines tools are installed at "/" then MacPorts doesn't pass in the isysroot and the syslibroot to the build system.

So for the OP, if you don't already have the command line tools installed in "/", you might try installing them, and see if that solves your build issue.

[eviltwinskippy (Sean Woods)]

Already tried that.

xcode-select -p

/Applications/Xcode.app/Contents/Developer

xcode-select --install

xcode-select: error: command line tools are already installed, use "Software Update" to install updates

[eviltwinskippy (Sean Woods)]

And for grins I also went ahead and closed everything, restarted my computer, performed an sudo port sync, sudo port upgrade outdated, and retried sudo port install mingw-w64.

It still fails at the same spot.

[mojca (Mojca Miklavec)]

I suspect this is specific to > 10.13 and the way how location of files changed on the OS.

I'll need more time investigating this, but -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk sounds wrong in any case. First of all, I would not be surprised if the linker used for cross-compiler doesn't support -syslibroot, but more importantly, the headers needed for cross-compiler are definitely not present in MacOSX10.14.sdk. I would start with figuring out how that -syslibroot got to the command line in the first place, and try to figure out if I can disable / remove that flag from the Portfile.

I would imagine that other cross-compilers would be bitten by similar issues? (OK, the compiler itself apparently gets compiled just fine, it's further additions that have troubles. It could also be that the cross-compiler PortGroup in fact disables some bits and pieces which I forgot to disable in `mingw-w64.)

[ryandesign (Ryan Carsten Schmidt)]

Replying to mojca:

I suspect this is specific to > 10.13 and the way how location of files changed on the OS.

It's specific to using an SDK. 10.14 is the first macOS version on which we use an SDK by default, because 10.14 is the first OS on which the command line tools don't provide /usr/include. (There is a secret pkg you can install to get /usr/include on 10.14, but we don't want users to have to do that.) If you're on an older system, you can probably reproduce the error by forcing MacPorts to use an SDK, for example by setting configure.sdkroot.

I'll need more time investigating this, but -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk sounds wrong in any case.

It is intentional that MacPorts sets these flags.

First of all, I would not be surprised if the linker used for cross-compiler doesn't support -syslibroot,

This I do not know. But I would expect support for this has been in compilers for a long time, since macOS has used this feature for a long time. (Didn't Mac OS X 10.1 already use it?)

but more importantly, the headers needed for cross-compiler are definitely not present in MacOSX10.14.sdk.

Are you claiming that files that are present in / are not present in the SDK? Because that's all that using an SDK means: for every system file that would ordinarily be looked for in /, look for it in the SDK instead. Files that are not system files—for example, files located in directories specified by -I and -L—are not affected; they're still looked for in the locations specified by those flags.

I would start with figuring out how that -syslibroot got to the command line in the first place, and try to figure out if I can disable / remove that flag from the Portfile.

You could clear configure.sdkroot. I expect doing this will cause the build to fail because it will no longer be able to find the system headers which are located in the SDK.

I would imagine that other cross-compilers would be bitten by similar issues? (OK, the compiler itself apparently gets compiled just fine, it's further additions that have troubles. It could also be that the cross-compiler PortGroup in fact disables some bits and pieces which I forgot to disable in `mingw-w64.)

[mojca (Mojca Miklavec)]

Replying to ryandesign:

Replying to mojca:

I suspect this is specific to > 10.13 and the way how location of files changed on the OS.

It's specific to using an SDK. 10.14 is the first macOS version on which we use an SDK by default, because 10.14 is the first OS on which the command line tools don't provide /usr/include. (There is a secret pkg you can install to get /usr/include on 10.14, but we don't want users to have to do that.) If you're on an older system, you can probably reproduce the error by forcing MacPorts to use an SDK, for example by setting configure.sdkroot.

I'll need more time investigating this, but -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk sounds wrong in any case.

It is intentional that MacPorts sets these flags.

I didn't want to imply that it's wrong in general, but it looks wrong (to me at least) for this port.

First of all, I would not be surprised if the linker used for cross-compiler doesn't support -syslibroot,

This I do not know. But I would expect support for this has been in compilers for a long time, since macOS has used this feature for a long time. (Didn't Mac OS X 10.1 already use it?)

Even if this was part of OS X 10.1, this doesn't say anything about upstream gcc using the same convention, like upstream gcc never really supported the -arch flag (they added this support much much later than Apple, but only to build a single arch).

I have a somewhat hard time trying to find some search engine result of syslibroot that's unrelated to macOS / iOS / Darwin / ...

but more importantly, the headers needed for cross-compiler are definitely not present in MacOSX10.14.sdk.

Are you claiming that files that are present in / are not present in the SDK?

Headers currently present under $prefix/x86_64-w64-mingw32/include should not be present in the MacOSX10.14.sdk.

I would start with figuring out how that -syslibroot got to the command line in the first place, and try to figure out if I can disable / remove that flag from the Portfile.

You could clear configure.sdkroot. I expect doing this will cause the build to fail because it will no longer be able to find the system headers which are located in the SDK.

I would really hope that it doesn't need any files located in that SDK. If anything, it should use files from $prefix/x86_64-w64-mingw32/include rather than macOS headers.

I would be grateful if someone was willing to try if putting just

configure.sdkroot

to the Portfile solves the issue on 10.14.

[eviltwinskippy (Sean Woods)]

I can confirm that adding configure.sdkroot to the Portfile fixes builds on 10.14

[eviltwinskippy (Sean Woods)]

To which I mean that yes, I added that directive, and yes, the port compiled and installed properly.

[mojca (Mojca Miklavec)]

Thank you very much for the confirmation, I'll add this change to ​https://github.com/macports/macports-ports/pull/2891 then.

I would like to upgrade to MinGW 6.0.0 as well (and do both changes at the same time), but apparently I'm now stuck with another bug with circular dependencies.

[mojca (Mojca Miklavec)]

In d03013b0490de83621eca1483a6bd058341a9951/macports-ports (master):

mingw-w64: update to 6.0.0

• Update to 6.0.0
• Clear configure.sdkroot variable to allow builds on 10.14

Closes: #57448