<div dir="ltr">I might have a cleaner solution for you.<div><br></div><div>Copy the following;</div><div>Xcode9.4.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain<br><br>Rename XcodeDefault.xctoolchain > Xcode9.xctoolchain<br><br>Open ToolchainsInfo.plist<br>Remove the current contents and add the following;<br>CompatibilityVersion        Number        2<br>DisplayName                   String            Xcode 9.4.1</div><div>Bundle identifier               String            Xcode9.toolchain<br><br>Now move to ~/Library/Developer/Toolchains/<br><br>The toolchain is now visible within Xcode, it can also be used by setting;<br>export TOOLCHAINS="Xcode9.toolchain"<br><br>Just need to set SDKROOT as appropriate.</div></div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 21, 2021 at 7:46 PM Brendan Shanks <<a href="mailto:bshanks@codeweavers.com" target="_blank">bshanks@codeweavers.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>True, looks like even Xcode 13.1 RC is still able to build for i386 with the 10.13 SDK. For CrossOver though we build an i386 .app, which requires xcodebuild, etc.</div><div>I would also prefer to stick with the toolchain that Apple tested/supported for i386 (and that we’ve already been using).</div></div><div style="overflow-wrap: break-word;"><div><br><blockquote type="cite"><div>On Oct 21, 2021, at 2:27 PM, Dean Greer <<a href="mailto:gcenx83@gmail.com" target="_blank">gcenx83@gmail.com</a>> wrote:</div><br><div><div dir="auto">I’m still not getting why your using Xcode9 in this manner when. XCode10/11/12 compiled 32Bit wine without issue as long as SDKROOT is set to MacOSX10.13.SDK</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 21, 2021 at 5:22 PM Brendan Shanks <<a href="mailto:bshanks@codeweavers.com" target="_blank">bshanks@codeweavers.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> On Oct 21, 2021, at 12:35 PM, Alexandre Julliard <<a href="mailto:julliard@winehq.org" target="_blank">julliard@winehq.org</a>> wrote:<br>
> <br>
> Brendan Shanks <<a href="mailto:bshanks@codeweavers.com" target="_blank">bshanks@codeweavers.com</a>> writes:<br>
> <br>
>> With the toolchain working, building i386 with it is now a cross-compile.<br>
>> Apple does not prefix the commands with the host triplet though<br>
>> (i.e. 'i386-apple-darwin'), which Wine seems to expect for cross-compiling.<br>
>> <br>
>> Specifically, configure adds "-b <host triplet>" to TARGETFLAGS, causing<br>
>> winebuild to search for commands like ld and nm prefixed with that host<br>
>> triplet, which fails.<br>
>> <br>
>> This is a patch which only sets that TARGETFLAGS when the host triplet<br>
>> appears in $CC. I'm open to a different approach to fixing this though.<br>
> <br>
> It seems to me that this should be done the same way we do it on Linux:<br>
> if we are on an x86_64 host and --enable-win64 is not specified, we add<br>
> -m32 and set host_cpu=i386. Passing --host is not required in this<br>
> configuration.<br>
<br>
Thanks Alexandre, that does work correctly and without any changes needed. This patch can be disregarded.<br>
<br>
For a WOW64 build, running configure like this works:<br>
<br>
DEVELOPER_DIR="/Applications/Xcode9.app" \<br>
SDKROOT="/Applications/Xcode9.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk" \<br>
../configure --with-wine64=<path to wine64 build><br>
<br>
Or for a standalone 32-bit build:<br>
<br>
DEVELOPER_DIR="/Applications/Xcode9.app" \<br>
SDKROOT="/Applications/Xcode9.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk" \<br>
../configure --with-wine-tools=<path to wine64 build><br>
<br>
Brendan<br>
<br>
<br>
</blockquote></div></div>
</div></blockquote></div><br></div></blockquote></div></div>