[MacPorts] #57448: i686-w64-mingw32-winpthreads and x86_64-w64-mingw32-winpthreads : linker does not accept syslibroot

[MacPorts]

#57448: i686-w64-mingw32-winpthreads and  x86_64-w64-mingw32-winpthreads : linker
does not accept syslibroot
-------------------------------------------------+-------------------------
  Reporter:  eviltwinskippy                      |      Owner:  mojca
      Type:  defect                              |     Status:  assigned
  Priority:  Normal                              |  Milestone:
 Component:  ports                               |    Version:  2.5.4
Resolution:                                      |   Keywords:  mingw
      Port:  i686-w64-mingw32-winpthreads        |  mingw-w64
  x86_64-w64-mingw32-winpthreads                 |
-------------------------------------------------+-------------------------

Comment (by mojca):

 Replying to [comment:9 ryandesign]:
 > Replying to [comment:8 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/57448#comment:10>
MacPorts <https://www.macports.org/>
Ports system for macOS