On Dec 22, 2018, at 14:35, Ryan Schmidt wrote:
> On Dec 22, 2018, at 08:41, Gijs Vermeulen wrote:
>
>> I'm having issues with wine-devel since upgrading from 3.18 to 4.0rc2.
>> When I run wine --help it works, but running anything else yields
>> "/opt/local/lib/../bin/wine: could not load binary"
>> My machine is a 2015 MacBook Pro running macOS High Sierra (fully updated).
>> I have tried completely removing macports and installing everything again
>> from scratch.
>>
>> I was wondering if anyone else has experienced this issue.
>
> Yes, I see that too.
>
> I guess this change from 4.0-rc1 might be related:
>
> https://www.winehq.org/announce/4.0-rc1
>
>> What's new in this release (see below for details):
>> - Preloader implemented on mac OS.
>
> I don't know anything else about the problem yet and I don't know what the
> "preloader" is. You might check if it's already been reported in the wine
> issue tracker. It's possible it has to do with the way we have moved the wine
> executable in order to use a wrapper script, in which case it's our bug, not
> theirs.
Well it definitely involves the preloader -- the "could not load binary"
message is in loader/preloader_mac.c -- and it's definitely to do with our
wrapper script, because the preloader is trying to load
/opt/local/lib/../bin/wine, a.k.a. /opt/local/bin/wine, expecting that to be
the wine program, but that's our wrapper script.
So one solution is to tell the preloader where the real binary is. I think I
would do that by overriding argv[0] in the middle of preloader_exec() in
libs/wine/config.c.
Another possible solution is to remove our wrapper -- I don't remember why it
exists. When I first added the wine port 12 years ago, I said there were "font
issues", but I don't remember what I meant by that:
https://trac.macports.org/ticket/11779#comment:2
I apparently fixed it by adding the wrapper script:
https://github.com/macports/macports-ports/commit/88d79d741bf86b96ce4fd23386d05b0f90001867
