bad CPU type in executable: wine

[kencu]

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]

I’m building on my mid 2014 13in MacBook Pro

I don’t believe that’s the issue here, your running macOS Catalina right?

[kencu]

yes, on a mid 2012 MacbookPro at the moment.

[kencu]

oh duh, I probably have to call wine64 instead of wine, don't I? if that is all it is, sorry, blond moment....

[Gcenx]

Yeah you need to call wine64 over wine on Catalina.

Unless you use my wine-crossover build that includes a wine wrapper that launches wine32on64 when running Catalina and above.

[kencu]

thanks. I did want that, but had some trouble spotting it. I have it now.

You know a lot about wine!

[kencu]

that wine-crossover did it for me. The application I wanted (LTSpice) I guess has a 32bit installer. Now it works just great, and thanks ! See -- what goes around, comes around -- I helped a bit, now you helped me :>

BTW, I was seeing this:

% wine
./wine: line 29: /wine32on64: No such file or directory
./wine: line 29: exec: /wine32on64: cannot execute: No such file or directory

and I looked at the script, and added this:

export WINESKINPATH="/Applications/Wine Crossover.app/Contents/Resources/wine/bin"

and after that it works for me. No doubt I did something else wrong somehow to cause me to need to do that, but at any rate, perfectly running wine on Catalina now.

[Gcenx]

I could have sworn I’d uploaded the fixed version that does this already.

I probably only uploaded the fixed strip for Wineskin but not the cask...

I wonder if it’s time to look into handling the CodeWeavers version of llvm/clang-8 and updating the wine-crossover Portfile so it can be built directly using the Portfile.

[kencu]

I am the maintainer of llvm/clang on MacPorts, if that is of any help to you :>

[Gcenx]

Yep I didn't upload a fixed version, the fixed Script was only within the newer Wineskin wrapper I'm working on. I'll uploaded it once compressed since it also includes DYLD_FALLBACK_LIBRARY_PATH to avoid some dylibs not being found still.

I am the maintainer of llvm/clang on MacPorts, if that is of any help to you :>

I've considered it, the version of llvm/clang-8 from CodeWeavers isn't an entire compiler suite. However I had asked qparis to create a fully working version for Cross-Compiling, he provided a patch set to he did apply to the debian llvm/clang-8 the patch can be found Here

I was considering just making an individual Port that would build the custom llvm/clang-8 and name them differently then the mp versions, as the only real use for this custom llvm/clang-8 currently is compiling wine(64/32on64)

[kencu]

There are other examples of this too. This port installs a special version of clang/llvm for it's own use with a custom configuration. It's probably a good example for you. https://github.com/macports/macports-ports/blob/master/lang/ispc/Portfile

[kencu]

BTW -- this is just fantastic. The version of LTSpice that runs under wine is from last week, and works superbly well. It even accesses all the files I made with the Mac version, opens, runs them, and saves them back into my (icloud-sync'd) drive without the slightest bit of me having to force it to do anything.

Wonderful. I know wine is responsible for a lot of this, but your packaging is great, and makes it all work and without you doing it, we'd be nowhere.

[Gcenx]

I’m glad you’ve found the package(s) useful

The packaging was partly based on Winehqs app bundle, but I’d opted to follow KISS over forcing XQuartz onto people like the old Winehq packages that were missing key dependencies.

The wine wrapper was added due to KISS and ensuring winetricks is compatible over forcing a patched version like I did prior.

Side Note;\ Before working on the needed custom llvm/clang-8 Portfile I’ve tackled another useful one that can’t be added to macports-ports directly sadly, the macOSX.sdk that Ryan was creating that needed Xcode to be pre-downloaded.

Instead I’ve opted to directly download the SDKs from another location then symlink them into /Library/Developer/CommandLineTools/SDKs/

For the custom llvm/clang-8 I don’t know if that could be accepted into macports-ports so I might just make a Portfile that downloads a pre-built Xcode Toolchain package instead

[kencu]

I asked Ryan about it -- he says he has made up his own port for the modified clang/llvm toolchain but not released it yet.

[Gcenx]

Did he mention why he didn’t publish it somewhere as I’ve had to help a number of people compiling it along with compiling wine32on64

[kencu]

I think just finishing it up with his wine update he has planned, and will roll it all out together.

[Gcenx]

@kencu question does libtapi support tapi-tbd-v3 currently as I only see tapi-tbd-v2 listed

[kencu]

It does, I believe. I used the latest available https://opensource.apple.com/source/tapi/ when I put the port together.

[Gcenx]

I know osxcross definitely does but haven’t required it on macports as of yet but might for some other Portfiles I’ve been working on.

The only notable one will be wine-staging definitely no longer compiles using the 10.8 SDK and lower but I can simply resolve that with my version of the MacOSX.sdk Portfile (10.4u>10.15)

I figure what’s taking Ryan so long with updating the wine-* ports, he’d be better waiting on CrossOver-20 as adapting the current wine32on64 patches isn’t worth the effort.

[Gcenx]

I have a weirder question, is is possible to for e a Portfile to skip the linker checks?

[kencu]

We can probably make it do most anything if motivated enough. Show me the exact thing you need to do and I'll see what comes to mind.

And one back -- I have patched wine 4.04 to run on 10.6.8 just because, but I need to compile a new "mono" for it as the one I can download generates errors. Is that hard to do?

[Gcenx]

On installation of the older macOSX.sdk files macports does its usual checking for linker errors then causes macports to wrongly believe the SDK is damaged.

Honestly wine-mono has been mostly useless until very recently, but compiling it shouldn’t be an issue https://github.com/madewokherd/wine-mono just need the usual mono tools and mingw to compile it.\ I’d recommend skipping wine-mono and instead just installing dotnet45 using winetricks.

I’ve not done much testing of Wine on pre-10.9 systems due to the tls requirements being higher now meaning access GitHub is more annoying, but I’d assume we could still build the latest versions by using a newer SDK might be required.

[kencu]

Making an SDK-driven build use a different linker than the one in the SDK is hard unless the build system allows a method for overriding parts like "LD". There is an SDK-overlay method for Apple SDKs that I have not fully sorted out with MacPorts builds as yet.

For practical purposes, for one-off builds, I will often just symlink the tool I want into the SDK and then put the old one back later.

[Gcenx]

Seems I’m not explaining clearly.

When installing a Portfile, it goes through multiple stages, downloading distfile, checksums, extraction, configure, build, destroot.

After the above is completed macports then checks all installed dylibs to ensure they are linked correctly, the problem is the dylib files provided in older SDK files want to check system locations instead of the SDKROOT that’s expected.

Let’s say;\ MacOSX10.12.sdk/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/AMDil_r700.dylib\ Is expecting to find a dylibs within the SDK that’s no precent in current versions of macOS but is contained within the SDK files, macports will freak

If needed I can provide terminal output to better explain the issue.

[kencu]

Oh, I see. Yes, MacPorts will run all the executables and dylibs to check linkages after installing the port. These libraries need to be installed in the system.

During the build, the build system sets the "root" to the SDK, eg "MacOSX10.12.sdk" . The links generated during the build are relative to that root, in your case "/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/AMDil_r700.dylib".

But on installation, there needs to be an actual library at "/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/AMDil_r700.dylib" for the installed software to find it's links in. It can't be in the SDK at that point, it has to be really there in the root "/" somewhere.

That's not really a macports thing (although you can turn off that link check if you want by manipulating this variable in macports.conf:

revupgrade_autorun
Controls whether the rev-upgrade action will be run automatically after upgrading ports.

Default: yes

or by passing a flag to port - "--no-rev-upgrade" I think it is.

But -- why? The software you are installing is broken if it fails rev-upgrade, and won't run -- it will just error out with a message that the library is not found.

[kencu]

you probably know about install_name_tool, that lets you manipulate these links. I sometimes have to do that to force things around if needed, eg this bit of hackery https://github.com/kencu/TigerPorts/blob/cfc9cda936af95b333e36c6ad5abc48769d86e91/lang/llvm-7.0/Portfile#L742.

[Gcenx]

--no-rev-upgrade allowed the MacOSX10.10.sdk and lower to install without macports complaining but that’s not ideal. I was hoping there was some other hidden option that could be added to the Portfile to skip this check, but I guess this wasn’t exactly something that was considered before.

As these are actual MacOSX.sdk files install_name_tool is out of the question else the resulting compilation using the installed SDK will result in a broken compile.

It looks like the lowest version that can be used then would be MacOSX10.11.sdk by just removing the mentioned AMDil_r700.dylib as that’s not even a real dylib but something else that’s used in the system by ATI graphics cards. (I did try turning it into a tbd stub)

This means MacOSX10.11.sdk is the lowest SDK that can be installed using a Portfile

I guess I can just have wine-staging install and use the MacOSX10.11.sdk (along with ld64 ect) and set the min version low enough it shouldn’t be an issue.

[kencu]

It is unlikely MacPorts will ever allow Portfiles to set no-rev-upgrade as they would install broken software. It's only useful for devs.

install_name_tool is your fix, if it is fixable at all. I would still need to see the actual problem you're having rather than this discussion, but consider:

You build your software against the MacOSX10.12.sdk and it links against some dylib. You install it and that dylib doesn't exist in the system you've installed to. It's totally broken and useless, and will error out when you run it. You have to come up with a different method.

If the dylib you're linking against doesn't exist in the system you're installing to, you need a different solution -- don't use that dylib, use a similar one in a different place, install your own and link against that, blah blah blah. But linking against an SDK and expecting that dylib to be the one that is used in the end in a non-starter. Most of the dylibs in the current SDKs have no object code in them anyway -- they are just text files with the names of routines -- that is what TAPI is all about, as you likely know.

[Gcenx]

Maybe I’m not explaining this well enough.

We can currently use MacOSX10.13.sdk and compile software to run on 10.6 (as long as we provide libraries that macOS would be missing)

For example the wine-crossover you installed was compiled on my Mojave system using the MacOSX10.13.sdk for all libraries (macports +patches) and a modified MacOSX10.14.sdk that allows i386 target (wine respects dark mode on Mojave)

[Gcenx]

That wine-crossover build also works on OSX10.9 it could also work on lower versions but with the recent tls requirements I’d skipped going below 10.9 for the moment.

[kencu]

Maybe I’m not explaining this well enough.

I think if you need me to help any deeper I'd need to see the exact problem, agreed:)

Re: TLS -- if the software can build against gnutls or openssl or similar, all is good; if it can only use the Apple Security framework, Apple TLS, etc, then you're hosed. Most unix-y things do use gnutls with a switch if asked...thank goodness.

[Gcenx]

I've committed what's currently working. (MacOSX10.10 and lower were stripped)

Seems I'm unable to compile wine-5.13 using the MacOSX10.9.sdk due to missing symbols, also attempted to use the MacOSX10.13.sdk and failed due to ld64 not supporting TAPIv3 only TAPIv2.\ Compiling using MacOSX10.11.sdk on 10.9 fails something with the linker not finding the SDK provided files it looked like.

The current minimum SDK that could compile wine now was MacOSX10.10.sdk with the additional workaround I'd added to disable the Metal header detection

[kencu]

make sure that you're using the right ld64, of course.

you want to install ld64-latest and then set up the symlinks to use it.

and then you might need to force your build to use macports' ld64 instead of the ld in the SDK, which sometimes takes some extra work.

[kencu]

macports ld64-latest with our current libtapi supports tapi v3 https://opensource.apple.com/source/tapi/tapi-1000.10.8/include/tapi/Core/TextStub_v3.h.auto.html.

[Gcenx]

Ah so ld64-latest is what I’ll be needing then, I was thinking it’s weird that osxcross supported TAPIv3 but macports didn’t.

Did a little digging for what wine-devel-5.13 seems to want and it seems your legacysupport should cover the requirement(s) I've currently encountered issues with.

As the compile is running from within a VM this might take a while to confirm but it’s gotten past the previous issues already so fingers crossed

[kencu]

And you're convincing me about what I already felt was the case -- we have to simplify our ld64 port. People should get a clear message about how to use it, and obviously we are failing in that regard. This one is on us.

[Gcenx]

Well I have some news on using legacysupport, it allowed wine to compile, but it doesn’t work somehow the wine-preloader mapping got screwed up.

I’ll check your example from before for forcing macports ld64 to hopefully allow compiling without needing to patch wine heavily.

Still need to test building using a 10.10 VM to see if it does build natively as it did build on Mojave using the 10.10 SDK when setting the Metal header check to disabled

[kencu]

I know nothing about wine preloader, but FYI I added an option to legacysupport to link in the library statically; it's possible you might find that works better for some purposes: https://github.com/macports/macports-ports/blob/8147397edb6d30c44d172b3e1233b732eaf059f6/_resources/port1.0/group/legacysupport-1.1.tcl#L32

[Gcenx]

I’ll give the newer legacysupport another go, but using a newer SDK has been the recommended way to compile wine for a while, MacOSX10.11.sdk is the minimum and MacOSX10.13.sdk is recommended.

wine-preloader handles memory mapping to avoid restricted addresses, macOS has a number of addresses restricted that windows would commonly use.

I’ve successfully compiled wine-devel 5.13 by forcing macports to use MacOSX10.11.sdk by modifying the macports.config file, but I’m a little stumped on how I should be handling this directly within the Portfile.

Edit; I’m assuming configure.sdkroot should be used

[Gcenx]

This took longer then I’d have liked due to running within a VM.

OSX 10.9 and above will are now compiling wine-devel-5.13.

With the need to workaround the the newer tls requirements I didn’t really get to do much testing within the 10.7 VM, it compiles and launches winecfg/wine explorer but macdriver doesn’t work with recent wine versions within a VM meaning testing is very limited

[Gcenx]

@kencu could you please check your able to compile graphene from source and it installs /opt/local/include/graphene-1.0/graphene-gobject.has I just rebuilt my environment and this header was not precent causing gstreamer1-gst-plugins-base to fail

I believe the recent changes to meson caused this issue as I rebuilt my environment last month using my overlay without issue

[Gcenx]

I believe the ObjectiveC part of the compile never happens, I believe the crossfile need to have the following section added for this to work;

[binaries]
objc = '-target'

I’ll confirm this once I’m done with work

[kencu]

I was hoping to leave all the binaries out of the crossfiles -- as we then get into a real mess of compiler specs.

Maybe your build is failing for the other 102,000 reasons builds fail :>

If I have to add the binaries spec, it will have to be custom-written for each build using MacPorts selected compiler for that build, as a second layered crossfile into the build dir. That is a total UGH.

[Gcenx]

I kept digging since the above comments and I believe it’s just that meson when using the crossfile isn’t detecting objc binary or env variable.

It seems when meson is in cross mode it skips the usual check it makes to see if the compiler supports ObjectiveC, maybe placing a symlink to the selected compiler during build or setting some env will resolve the issue without needing to add additional items into the crossfiles

[Gcenx]

@kencu after doing multiple builds and looking over while running multiple graphene +universal builds using verbose I can see the problem, after swapping to using crossfiles meson no longer finds anything.

Usually graphene needs both g-ir-scanner & g-ir-compiler, but using a crossfile these binaries are no longer found, this also includes cmake, pkgconfig or any other binary it wants.

I did managed to get graphene working again at least by adding only one section

[binaries]
pkgconfig = '/opt/local/bin/pkg-config'

With only pkgconfig added graphene found both g-ir-scanner & g-ir-compiler meaning the compile now includes the needed support plus the additional header.

[kencu]

Thanks for finding this and sorting this out. I will reproduce, and then open a ticket and see what the best way forward here might be. The meson PortGroup could write a custom binary crossfile for each build based on the current portfile specs -- it layers on top of the machine ones already there -- I was just hoping that we wouldn't have to do that. But perhaps it's inevitable .The qt5 portgroup already does something like this so there are models to follow. Thanks again!

[Gcenx]

@kencu this particular one took me a while to notice since graphene was built before the meson changes.

I’ve added the workaround to macports-wine along with some others (cario|cario-devel suppress i386 linker warnings for 10.13 and greater)

I believe most of the workarounds are at least clean enough now bar the FAudio one, I’m using curl to workaround GitHub a TLS requirements with an additional checksum section, I’d like to instead grab the same archive that GitHub group gets so another checksum section is unneeded.

[kencu]

If the TLS issue is with macports downloading things, we wouldn't put individual fixes into each port for that. We just build macports against a newer curl instead. There is a macports configure arg for that, and then everything works.

I'm still updating the 10.13 universal system to see what's up with graphene at the moment ..

[kencu]

graphene builds +universal for me with the current meson and current crossfiles without any modifications. graphene-build-universal.txt.zip

[kencu]

must be something else going on with your setup, but be careful adding too many "fixes" to your ports as you may have to undo them all shortly...

[Gcenx]

@kencu it will build without error however now try to build gstreamer1-gst-plugin-base and it will fail due to a missing header graphene-gobject.h