Opened 5 years ago

Closed 5 years ago

#57448 closed defect (fixed)

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

Reported by: eviltwinskippy (Sean Woods) Owned by: mojca (Mojca Miklavec)
Priority: Normal Milestone:
Component: ports Version: 2.5.4
Keywords: Cc: libsystem-ethan
Port: i686-w64-mingw32-winpthreads x86_64-w64-mingw32-winpthreads

Description (last modified by jmroot (Joshua Root))

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

Attachments (2)

main.log (183.6 KB) - added by eviltwinskippy (Sean Woods) 5 years ago.
Compile Log
build.log (2.4 KB) - added by eviltwinskippy (Sean Woods) 5 years ago.
Results of make

Download all attachments as: .zip

Change History (17)

Changed 5 years ago by eviltwinskippy (Sean Woods)

Attachment: main.log added

Compile Log

Changed 5 years ago by eviltwinskippy (Sean Woods)

Attachment: build.log added

Results of make

comment:1 Changed 5 years ago by libsystem-ethan

Cc: libsystem-ethan added

comment:2 Changed 5 years ago by jmroot (Joshua Root)

Description: modified (diff)
Owner: set to mojca
Port: i686-w64-mingw32-winpthreads x86_64-w64-mingw32-winpthreads added; mingw-w64 removed
Priority: HighNormal
Status: newassigned

comment:3 Changed 5 years ago by 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

comment:4 Changed 5 years ago by kencu (Ken)

Summary: i686-w64-mingw32-winpthreads and x86_64-w64-mingw32-winpthreads fail to compilei686-w64-mingw32-winpthreads and x86_64-w64-mingw32-winpthreads : linker does not accept syslibroot

comment:5 Changed 5 years ago by 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.

comment:6 Changed 5 years ago by 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

comment:7 Changed 5 years ago by 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.

comment:8 Changed 5 years ago by 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.)

comment:9 in reply to:  8 ; Changed 5 years ago by 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.)

comment:10 in reply to:  9 Changed 5 years ago by 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.

comment:11 Changed 5 years ago by eviltwinskippy (Sean Woods)

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

comment:12 Changed 5 years ago by eviltwinskippy (Sean Woods)

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

comment:13 Changed 5 years ago by 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.

comment:14 Changed 5 years ago by mf2k (Frank Schima)

Keywords: mingw mingw-w64 removed

comment:15 Changed 5 years ago by mojca (Mojca Miklavec)

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.