search

Gcenx / macOS_Wine_builds

Official Winehq macOS Packages
482 stars 24 forks source link

bad CPU type in executable: wine #3

Closed kencu closed 3 years ago

kencu commented 4 years ago

This is with the 5.11 Wine-Staging:

/Applications/Wine Staging.app/Contents/Resources/start/bin/winehelp: line 41: /Applications/Wine Staging.app/Contents/Resources/wine/bin/wine: Bad CPU type in executable
 Welcome to .

 In order to start a program:
   .exe: wine program.exe
   .msi: wine msiexec /i program.msi

 If you want to configure wine:
   wine winecfg

 To get information about app compatibility:
   appdb Program Name

% wine winecfg
zsh: bad CPU type in executable: wine

I guess your build machine must have a newer processor than this system I'm running.

Gcenx commented 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

kencu commented 3 years ago

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.

Gcenx commented 3 years ago

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

Gcenx commented 3 years ago

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)

kencu commented 3 years ago

heh -- now i just have to spend a month doing it all :>

Gcenx commented 3 years ago

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

Gcenx commented 3 years ago

xar is already done as a patch

Gcenx commented 3 years ago

@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

Gcenx commented 3 years ago

@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

Gcenx commented 3 years ago

@kencu I'm sure you'll notice but you might be interested in https://github.com/macports/macports-base/pull/213

kencu commented 3 years ago

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.

Gcenx commented 3 years ago

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

lpla commented 3 years ago

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?

Gcenx commented 3 years ago

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

kencu commented 3 years ago

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!

Gcenx commented 3 years ago

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

kencu commented 3 years ago

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.

Gcenx commented 3 years ago

Thanks @kencu I’ll see if I’m able to find a distinct error then open a bug report.

Gcenx commented 3 years ago

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

kencu commented 3 years ago

looks like assembly is enabled for all but arm64 at present. There is a PR to enable arm64 assembly.

Gcenx commented 3 years ago

@kencu needed to add another new dependency for the upcoming wine-6.2 jxrlib, I’m sure that’s not the Macports way but it works.

The makefile is useless due to no install target & doesn’t produce dylibs that are expected by almost everything on macOS including wine lol.