[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 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.

 > 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.)

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