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.

[kencu]

Right.... OK, let me see about that.

Found Pkg-config: NO
Found CMake: NO
Run-time dependency gobject-2.0 found: NO (tried pkgconfig, framework and cmake)

[Gcenx]

but be careful adding too many "fixes" to your ports as you may have to undo them all shortly...

Once I’m aware a workaround is no longer required I remove them

[Gcenx]

I believe your referring to https://trac.macports.org/ticket/51516 yeah I’m hopeful once this happens I won’t need to deal with workarounds for downloading distfiles

[kencu]

If you like, just reinstall macports from source, specifying a new curl, right on top of the existing macports. It takes three or four minutes.

If you have a separate curl somewhere, use it, otherwise you can self-reference if you stay a bit careful. Assuming you have installed curl in /opt/local, do this to configure macports:

configure --with-curlprefix=/opt/local
make
sudo make install

I install curl into a macports installed in /opt/bootstrap and reference that, but that's 'cause I'm paranoid :>

[kencu]

It looks like meson, when cross-building, will not just search the path for pkg-config. It wants it to be specified in the environment. I added this to the graphene portfile:

configure.env-append PKG_CONFIG=${prefix}/bin/pkg-config

and that made graphene happy:

Using 'PKG_CONFIG' from environment with value: '/opt/local/bin/pkg-config'
Found pkg-config: /opt/local/bin/pkg-config (0.29.2)
Run-time dependency gobject-2.0 found: YES 2.58.3

1. How to handle this in the general case, rather than adding that spec to every portfile?
2. What other binaries might need the same treatment? Stay tuned!

[kencu]

Just for laughs, meson seems perfectly happy finding other binaries in the PATH:

Build-time dependency gobject-introspection-1.0 found: YES 1.60.2
Program g_ir_scanner found: YES (/opt/local/bin/g-ir-scanner)
Program g_ir_compiler found: YES (/opt/local/bin/g-ir-compiler)
Build targets in project: 3

[Gcenx]

@kencu I used your instructions on some VMs without issue but for some users they struggled so workarounds lol.

While you can do that for each Portfile I instead modified the meson portgroup to required pkgconfig and meson crossfile now includes pkgconfig the prefix is resolved when installed check macports-wine to see what I did

[Gcenx]

@kencu I assumed macports-base already handled PATH....?

[kencu]

The crossfile doesn't need touching. I don't think. I didn't touch it.

Just meson wants PKG_CONFIG spec'd when cross building.

[kencu]

base sets PATH -- but meson seems to ignore for the specific search when looking for pkg-config when cross-building.

Which makes sense.

[Gcenx]

Not really most cross environments will search PATH but look for tools for the specified target, so for darwin it will be searching for all tools appended with darwin

[kencu]

I'm trying to imagine if there is some port that wants to set it's own PKG_CONFIG (like some cross-building compiler) to something other than the default one, that builds with meson, and would be messed up if we overwrote that in the meson PG.

That's a stretch.

There are dozens of ports that build with meson that don't use pkg-config though. How will it work when we spec a pkg-config in the environment that doesn't actually exist? That is ugly programming, but likely no problem in the end, I guess. That is EXACTLY the kind of stuff the MacPorts admins detest though, and for good reason.

[kencu]

meson is clearly not searching the PATH for pkg-config when cross building, otherwise it would have found it without the spec.

[Gcenx]

Can the meson portgroup handle passing PATH when using cross file?

[kencu]

OK - I see what you mean -- maybe meson is searching the path for some kind of frankenstein binary named i386-pkg-config-darwin

meson. new birthing build systems can be such a PITA.

[kencu]

Can the meson portgroup handle passing PATH when using cross file?

base is already setting the PATH correctly, eg. above:

Program g_ir_scanner found: YES (/opt/local/bin/g-ir-scanner)
Program g_ir_compiler found: YES (/opt/local/bin/g-ir-compiler)

but not for pkg-config.

[Gcenx]

I meant some more correct way to have it detect pkg-config, I didn’t try making the pkg-config wrappers but that might work

[kencu]

It's easier to set this:

configure.env-append PKG_CONFIG=${prefix}/bin/pkg-config

than to start adding wrappers for everything.

[kencu]

If wrappers would even work (we have no idea if they would or not). But even if they did, I wouldn't use that.

We'll just add PKG_CONFIG to the env, along with all the other things we already add.

[kencu]

The way meson searches for pkg-config is specified here https://github.com/mesonbuild/meson/blob/847d652c4ef179bbf94c0e322dc3277858fcf08c/mesonbuild/dependencies/base.py#L557

[Gcenx]

Once a more correct way is within macports-ports I’ll remove the while working janky workaround.

Yeah I’d avoid wrappers when possible, it gets annoying after a while to maintain them

[kencu]

Opened: https://trac.macports.org/ticket/60987 to get some feedback before we decide whether to fix this in base, the meson PG, or in each portfile individually.

Thanks again for noticing! You're really helping me kick the tires here, by pushing MacPorts to it's limits!

[Gcenx]

@kencu i think you might be interested in this https://github.com/tpoechtrager/apple-libtapi

This repository is used by https://github.com/tpoechtrager/osxcross and constantly tried to support the latest SDK versions.

According to the repository it should be possible to build libtapi on MacOSX10.9

[kencu]

I'm the maintainer of libtapi on macports, and fixed it back to 10.6. could probably do 10.4 and 10.5 too, but no need as yet.

This lets the very latest ld64 run on 10.6 up...!

[Gcenx]

Ah it seems I’d misread the comments within ld64, it’s not that macports can’t build the newer tapi it’s that some Xcode versions can’t...

[kencu]

libtapi needs a fairly new clang to build, but I worked all that out I thought. It gets green lights across the oard https://ports.macports.org/port/libtapi/summary.

Is there something specific you're hoping to do with libtapi or ld64 that I can help you with?

[Gcenx]

The last time I’d attempted to build using the MacOSX10.13.sdk on 10.8/10.9 it failed to read the tapi v3 stubs so I needed to fallback to MacOSX10.11.sdk instead.

I’d guessed the prebuilt copy of tapi was outdated as for 10.8/10.9 testing I avoid building clang from source due to it being a VM

[kencu]

there is a bootstrapping issue with ld64 that presently needs a manual step to overcome.

on many systems you can't build ld64-latest directly with the system xcode.

You have to install the newest ld64 that the os can build (different for each)' then install clang-9.0 and cctools, and then you must manually upgrade ld64 to ld64-latest. It takes 15 seconds.

I'd love to automate this, and have some ideas. We have an open ticket somewhere about this issue.

[Gcenx]

Yeah I’ve seen numerous open issues that seem like they could have been resolved long ago.

I’d rather avoid as many manual steps as possible to avoid user error when possible (that’s what most of the modifications on macports-wine is all about, same for the Winehq packages here and the brew tap)

[kencu]

I’d rather avoid as many manual steps as possible to avoid user error when possible (that’s what most of the modifications on macports-wine is all about, same for the Winehq packages here and the brew tap)

Me too. If you can think of a robust way to bootstrap ld64 all the way to ld64 latest while obeying MacPorts rules and regulations in the process, I'm all ears.

[Gcenx]

Me too. If you can think of a robust way to bootstrap ld64 all the way to ld64 latest while obeying MacPorts rules and regulations in the process, I'm all ears.

I’ll look up the ticket and see what I make of the current discussion.

[Gcenx]

@kencu I haven’t found the ticket your referring to, but I have noticed some odd behavior within ld64/ld64-latest it’s requiring macports-clang9 this is rather a heavy requirement when it’s possible to build tapi/ctools/ld64 with clang3.9+ outside of macports, I wanted to ask before opening a ticket

[kencu]

our libtapi is set to require the same, clang-3.9+ and xcode clang > 800.

https://github.com/macports/macports-ports/blob/8ce58421375ec75b929bc222ac9ea7193bd1c952/devel/libtapi/Portfile#L67

macports compiler defaulting does not call for the least capable compiler that can work, though. If the system compilers are incapable, it goes to clang 9 first (as it should).

[kencu]

even if you set libtapi to build with clang-5.0 (oldest we have that can do it) you're no further ahead.

what is needed is an automatic stepping stone, where a throwaway ld64 is used temporarily to build ld64-latest. The problem is that macports is not wired up that way, and ld64 is wired into all the compilers directly.

Possibly I could disable one of them like clang-5.0 to use the ld64 that is the best the os can make, and the use that to build ld64-latest, and then wire to into later clangs...that won't be accepted well though.

Maybe I could use a custom build of clang and ld64 to generate libtapi and ld64-latest...

But--these are all moving targets, and what builds libtapi today may not build the next version of libtapi tomorrow, and that's a lot of work for a collapsing house of cards...

[Gcenx]

What I’m trying to do is install ld64-latest without requiring macport-clang unless it’s required to build it.

I believe the issue is the way I’m intending to use ld64 is out of scope of macports

[kencu]

any system that comes with xcode clang 900+ can do it. That is what MacPorts ld64 port is already set up to do, though, so you don't have to do any work to make that happen.

We use ld64_xcode where that is newer than ld64-latest.

Maybe better to tell me exactly what your problem is?

[kencu]

actually, it needs xcode clang >801 .

[Gcenx]

The issue in having is I want to install ld64-latest without macport-clang-9 also being installed.

The idea being when I’m running my build let I’ll force ld64-latest so there are no irritating i386 warnings displayed

[kencu]

I getcha. The logic to decide that is https://github.com/macports/macports-ports/blob/b0aafd8b14d38d040ebf92787cedeb29543e9aa2/devel/ld64/Portfile#L227.

Your system wants to use ld64_xcode, and that is generating the error you mention? That only happens if you are running darwin15, or have xcode 11+ installed, for reasons explained in the portfile at that link area.

You can change it though. It's easy to force that ld64 Portfile to install ld64-latest on all systems.

[Gcenx]

For some reason this section seems to be getting called https://github.com/macports/macports-ports/blob/b0aafd8b14d38d040ebf92787cedeb29543e9aa2/devel/ld64/Portfile#L308

So that’s forcing +llvm90 on my system when I’d guess that shouldn’t be the case

[kencu]

Well, we do have ld64-latest set to build with llvm90 by default, as it's the practical newest llvm.

How is that bothering you? The way this is supposed to work is that you, on 10.14, ask for "ld64".

The logic sorts out that ld64 for you should be ld64-latest +llvm90.

And your xcode toolchain builds llvm90, and then ld64-latest using it, and sets that to be your default.

Unless you purposefully try to override the variants, or (here is a gotcha sometimes), unless you're upgrading from some older setup and the variants want to propagate on you.

[Gcenx]

That’s the thing I want ld64-latest without +llvm90

Other then the Xcode provided version of llvm the other custom one I require is already bundled within an XCode toolchain

[kencu]

For that then, you'd have to make up your own custom version of ld64, something like ld64-latest +llvm_xcode, which we don't (and won't) offer, and then change this line:

https://github.com/macports/macports-ports/blob/b0aafd8b14d38d040ebf92787cedeb29543e9aa2/devel/ld64/Portfile#L471

to point to the llvm-config in xcode somewhere that you want to use.

[Gcenx]

I was more hoping something like ld64-latest -llvm90 could be called then overriding the Portfile.

Guess I need to look into an alternative approach for this one.

For the moment the osxcross version of ld should be enough

[kencu]

that is built against xcode's llvm? I'd be surprised if so -- it is a linux thing primarily, and I think it also builds against it's own installed llvm.

[Gcenx]

Yes it’s built against Xcode-llvm osxcross does support the setup.

I’d setup osxcross precisely on macOS to speed up my development on phoenicis-winebuild.

Since I have macports installed and patched to build +universal i now symlink to my real macports install.

To make my life easier thrown together osxcross Portfile that disabled building the dependencies and instead uses the versions from macports like libtapi

[Gcenx]

Also no by default osxcross doesn’t built its own compiler unless you request it to build llvm or gcc

By default the system clang is used with wrapper binaries that inject sdkroot to clang and by setting the correct host setting it will default to using the osxcross binary wrapper for everything (ld isn’t a wrapper)

[Gcenx]

osxcross when built using Xcode ld doesn’t support LTO (not ideal)

I really don’t want to mess with ld64 or related ports and having macports-clang installed won’t be beneficial (I have any needed llvm/clang version as Xcode toolchains)

The only alternative is can think of is patching all relevant sources and attempting to build an XCode toolchain and fix rpaths to be relative if needed

[kencu]

I'm sorry about that -- the ld64 port uses llvm-config to get it's configuration from; I don't think there is a similar thing installed with xcode. It is probably possible to hack into the port to make it build against the llvm installed with xcode, but -- too much work for me.

You know you don't need the entire clang toolchain for ld64 to work; just llvm, any version (defaults to 9.0) so that ld64 can do the LTO.

If all you are trying to do is suppress the ld64 warning, perhaps you might consider a tiny wrapper shell script that adds -w to the link line and then calls the xcode one. There are lots of simple examples of how that would work.

[kencu]

In fact, you might just hack the existing ld64-xcode script to make it do that ;>