Closed kencu closed 3 years ago
I was precisely injecting -w but that’s far from ideal, a wrapper script adding -w installed into PATH would cause even more issues.
Around 2 months back I’d removed all but two wrapper scripts from phoenicis-winebuild, the remaining two are just to fake i386-apple-darwin17-gcc and x86_64-apple-darwin17-gcc, now setting --host x86_64-apple-darwin17 is all that needs to be set since osxcross then injects includes/headers/frameworks.
I’d look into getting the Portfile to support building using Xcode llvm just without LTO but I’m assuming that’s another edge case
I don't know why you'd say adding -w
to the existing ld64_xcode wrapper script would be so bad, but of course that's up to you.
If you're going to use ld64 +llvmNN you might as well use LTO, as it is just sitting there waiting to be used anyway. Otherwise just build ld64 without LLVM (and without LTO) and you're in the same position.
And why you find it so bad to install llvm-9.0 I'm not sure either; that just works, no more hiccups. I'm going to make ld64 default to llvm-10 soon on suitable systems, and llvm-11 is rc2 that will be coming shortly as well.
Adding -w to the ld64-Xcode script would mean no more linker warnings, cario/cario-devel only builds i386 on Mojave with -w being passed dbus it’s not the i386 warning that’s causing the issue but something with the configure checks and the version of binutils shipping within XCode10+
The idea was to have a recent enough version of ld64 that doesn’t add the i386 linker warnings but still supports newer SDKs, having LTO or not didn’t really matter in my case.
I know it seems strange but I’d prefer to not install llvm/clang into the environment if at all possible since I have XCode toolchains configured with each llvm version needed include CodeWeavers-llvm-8.0.0
There I believe I opened all required tickets to cover everything properly bar Apple LLVM/Clang to support Apple silicon from current Intel systems.
ld64-latest, libtapi, cctools and xar (swap a fork)
heh -- now i just have to spend a month doing it all :>
It might take you a while but it will be the macports way, now if did updated those it would lightly only work on a couple of configurations
xar is already done as a patch
@kencu I tried the WIP Portfile you provided for libtapi and had the issue you mentioned in the commit, patching that didn’t resolve it.
Hell even using apple-libtapi repository didn’t resolve the issue, so it looks like the workarounds used within build.sh is required to get it compiling.
Not had chance to test that yet with CrossOver-20-Beta1 being available
@kencu i didn’t directly cc for this but since it’s related gcc-10.2.0 maybe you might have some input https://trac.macports.org/ticket/61251
@kencu I'm sure you'll notice but you might be interested in https://github.com/macports/macports-base/pull/213
well isn't that neat...who knew they would still have the i386 bits in those headers?
I will be interested to see if macports will allow this in at this point, but for those of us interested, it's indeed useful.
I thought everyone know about this but Macports dropped 32Bit anyway as the SDK didn’t support it anymore (without patching)
I don’t think it will be accepted at least in its current form but maybe another Macports member will implement it in a more Macports friendly manner
Would it make sense to replace /Applications/Wine\ Stable.app/Contents/Resources/wine/bin/wine
and /Applications/Wine\ Stable.app/Contents/Resources/wine/bin/wine-preloader
binaries with the 64-bit equivalent now that it is not possible to run 32-bit .exe files in Catalina/Big Sur? This would avoid issues when opening 64-bit .exe files from Finder and related scrips or apps like winehelp
in modern macOS versions without 32-bit support.
I guess that a separate package should be done for this as older macOS versions still work with the current wine install. Am I too naive?
The packages are built to be replacements for the now depreciated Winehq packages.
The packages contain both wine and wine64 binaries there’s also no 64Bit equivalent of wine outside of crossover based sources aka wine32on64 (must be that exact name)
The scripts could be tweaked more if needed.
The binary wrapper that launches Terminal and allows launches via Finder could be modified more or edit the plist.info to use a 32Bit version below Catalina and use a 64Bit binary when above.
As for 32Bit exe files you can can run those by using my wine-crossover package available from my brew tap gcenx/wine
I have been using the wine crossover package on Catalina since you released it, and it seems to work fine to run 32bit apps.
The one I really wanted was LTSpiceVII, and that has a 32bit installer it appears.
And -- again -- thanks for this!
@kencu I recently found something weird bug with gmp
when built as +universal the i386 slice is working just fine but the x86_64 slice doesn't work. Yet a the i386 slice on it's own isn't and issue and the macports provided x86_64 one also works just fine?
This was tested with MacOSX10.13.sdk and also "/" both produced the same results.
I manually run lipo on the single arch builds of gmp and the resulting merged dylib both slices work correctly.
Universal building is a bit tricky, and with something like gmp where there is a lot of assembly, the chances for an error are higher. If you get to the point where it is a distinct error, please open a ticket and we can work through what is going on.
Thanks @kencu I’ll see if I’m able to find a distinct error then open a bug report.
@kencu for my purposes I can say I’ve resolved this. As I need to use the same dylibs across multiple systems forcing core2 and having assembly disabled resolved the issue I was having, need to retest if this also works with assembly enabled as I need these to also function under Rosetta2.
Are the prebuilt x86_64 gmp packages (Intel) built with assembly enabled?, I know it used core2 on the buildbot and the prebuilt package worked no issue under Rosetta2.
looks like assembly is enabled for all but arm64 at present. There is a PR to enable arm64 assembly.
This is with the 5.11 Wine-Staging:
I guess your build machine must have a newer processor than this system I'm running.