[Bug 58580] New: macOS clang: -msabi=ms unrecognized option... causes x86_64-unix/*.a files to be missing. Cannot winegcc cannot link agains libadvapi32 et al

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58580

Bug ID: 58580
           Summary: macOS clang: -msabi=ms unrecognized option... causes
                    x86_64-unix/*.a files to be missing. Cannot winegcc
                    cannot link agains libadvapi32 et al
           Product: Wine
           Version: 10.0
          Hardware: x86-64
                OS: MacOS
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: winelib
          Assignee: [e-mail]
          Reporter: [e-mail]

Created attachment 79102
  --> http://bugs.winehq.org/attachment.cgi?id=79102
the patch for the configure-script that works for me

I had first reported this to macports but I think you should have a look at it
https://trac.macports.org/ticket/72792

Expected Behavior:
I like to continue to use winegcc and wineg++ on macOS x86_64 to compile
winelibs. In fact it worked with wine 9.0.

Actual Behavior:
winegcc says it cannot link against advapi32 and others and infact the files
such as libadvapi32.a are not in lib/x86_64-unix/ anymore.

I think this might be the case since this change:

​https://github.com/wine-mirror/wine/commit/84d8a24af71d#diff-49473dca262eeab...
"Disable non-PE import libraries if compiler support is missing."

The -mabi-ms check is now done even if $PE_ARCHS exist which in my
understanding means we're crosscompiling PE code. The macport compiles with
clang and uses minGW to compile the PE code. But clang does not recognize and
no longer ignores the -mabi=ms option and in that case the configure-script now
sets DLLEXT from its initial value ".so" to "" which seems to cause the *.a
archive files to not being created/installed.

I've patched the configure-script so that DLLEXT is only set to "" in case
$PE_ARCHS is empty analogous to the fact that in that -mabi=ms not being
recognized is not reported as an error.

And I can create winelibs .exe.so and .dll.so just fine and load them from a
client *.exe.

I'd like to still use winegcc and wineg++ and the winelib feature on macOS. Is
this no longer possible? I guess linux using clang might experience the same.

This is my the patch that works for me on wine 10.12 (It's also attached):

https://github.com/matatata/macports-ports/blob/ff459f21995e6b6fceeacd51cea9...

I'd appreaciate if you could take a look and clarify.