search

Gcenx / macports-wine

Updated wine Portfiles for macports
90 stars 11 forks source link

Current known issues #19

Closed Gcenx closed 1 year ago

Gcenx commented 2 years ago

macports-ports issues

Any Port that previously required gettext will now be broken when building in a clean envirement due to https://github.com/macports/macports-ports/commit/fea008a043ad2b96fd1ee872d7b2152de8210614 as the libaries won't be found as those are now installed via gettext-runtime, I'm assuming this should work as gettext-runtime is a requirement of gettext but possibly everything needs to be rev-bumped?

Strangly curl compiles as +universal just fine when all of gettext and sub-ports are installed

Wine-7.0 issues

Gcenx commented 2 years ago

@mascguy I honestly don’t feel like opening multiple tickets for this but after the gettext split being merged a thing that requires the libraries/headers now fail to compile from source in a clean environment.

@gverm mentioned having this issue and I’ve also experienced this issue in both my Mojave and 10.9VM rebuilds as I require +universal builds due to wine.

Gcenx commented 2 years ago

Possible workaround for this overlay.

Adding p5-locale-gettext and adding gettext-runtime as a requirement resolved the issue locally so depending on the outcome of macports-ports that could suffice in the interim since that Port doesn’t seem to change often making it an idea confidante.

mascguy commented 2 years ago

The various Python ports were just updated to use getttext-runtime, so that's one less area to worry about.

As for p5-locale-gettext, that may be tackled soon as well. Alternatively, we can submit a PR for it, to ensure the update is expedited.

mascguy commented 2 years ago

It looks like p5-locale-gettext has no maintainer, so no PR is necessary. Testing the update locally, and will commit soon. (Will also reference this issue in the commit.)

Gcenx commented 2 years ago

@mascguy thanks for updating that one now that most of the affected Ports are fixed in macports-ports I should have less of a hard time testing upstream wine on an actual 10.9 install to see if there regression is only a VM issue or not.

Gcenx commented 2 years ago

@mascguy actually remaining annoyance is macports-base still not being able to make use of the macOS Mojave headers package to allow i386 arch when installed.

I’d opened a PR 223 (originally 212) that was over a year ago now, so lightly needs to be rebased.

Basically as you know macOS Mojave is the last version of macOS to natively support i386 arch but Xcode10 SDK doesn’t include a i386 slice.

However Xcode Command Line Tools 10 for macOS Mojave actually provides a headers package that once installed makes the install root act as an SDK like prior versions of macOS. However it seems no senior Macports member really attempted to verify this even though it’s known (yes the headers package also installed the framework headers). The result gives i386 & x86_64 capable sysroot that almost matches macOS High Sierra in compatibility along with some Mojave only things.

One commercial company who makes use of this has been CodeWeavers who compile there wine(64/32on64) using this as you’ll notice on macOS Mojave “wine” menu bar respects dark mode, I’ve also being doing the same for for official Winehq WIP packages.

As that PR seems to have simply stalled out I’ve been forcing the 10.13.SDK for compiling the required libraries but still compiling when wine packages using macOS Mojave sysroot.

mascguy commented 2 years ago

@mascguy actually remaining annoyance is macports-base still not being able to make use of the macOS Mojave headers package to allow i386 arch when installed.

Basically as you know macOS Mojave is the last version of macOS to natively support i386 arch but Xcode10 SDK doesn’t include a i386 slice.

However Xcode Command Line Tools 10 for macOS Mojave actually provides a headers package that once installed makes the install root act as an SDK like prior versions of macOS. The result gives i386 & x86_64 capable sysroot that almost matches macOS High Sierra in compatibility along with some Mojave only things.

Just curious: If the various macOS SDKs were published as formal ports - and that's something @ryandesign has been working on - would that help in this case? Or is the problem that some components are specifically provided by Xcode CLT - outside of the SDK realm - which would have to be provided as well?

Gcenx commented 2 years ago

Just curious: If the various macOS SDKs were published as formal ports - and that's something @ryandesign has been working on - would that help in this case? Or is the problem that some components are specifically provided by Xcode CLT - outside of the SDK realm - which would have to be provided as well?

@mascguy not really the entire idea to being able to make use of macOS_SDK_headers_for_macOS_10.14.pkg on macOS Mojave is to avoid needing MacOSX10.13.SDK and forcing the 10.13 deployment target as is currently required.

The custom SDK Port ryandesign was working on requires a manual step of providing the required version of Xcode then the relevant SDK would then be extracted this brings its own issues for older versions of mac OS X that are no longer able to connect most modern websites without a newer browser etc.

My SDK Portfile goes the gray route and directly grabs the SDKs from known good sources and only provides select SDK packages that won't flag rev-upgrade.

Gcenx commented 2 years ago

@mascguy just incase you comment here I have noticed Ryan finally started to publish his MacOSX.sdk ports, however I’ll be keeping my own implementation around.

Gcenx commented 2 years ago

@kencu is there any legitimate reason for cctools to require LTO support, it’s that really just need for ld64?

I’m hoping to avoid needing to install an llvm port just for cctools on Mojave to avoid the known as bug.

kencu commented 2 years ago

I haven't tried to build it without llvm in some years on newer systems, to be honest.

I did figure out one time how to run the cctools test suite, but it was non-trivial as I recall.

There is a known "as" bug? I can't recall at present...

Gcenx commented 2 years ago

Well I think it’s an as bug from memory according to your notes, cctools in Xcode11 has a bug that produced broken 32Bit binaries. You’d patched this in macports cctools (also fixed in newer cctools)

So I’m planning to force ether Macports cctools or my own for Mojave and below to avoid this bug.

Gcenx commented 2 years ago

@kencu keep forgetting to click comment sigh

The as bug caused i386 binary headers to be screwed up somehow causing the embedded info.plist to be invalid when using Xcode11 shipped cctools. You’d fixed that with the cctools port and it’s also fixed in later versions.

Still not exactly sure how useful LTO is for cctools but libstuff does pull it in so technically every component of cctools uses LTO somehow.

Seems the mingw-binutils bump might need to get pulled in here, the MoltenVK is also the same but I guess that doesn’t really concern me as I grab GitHub actions generated archives from my fork.

Gcenx commented 2 years ago

Might need to pull in https://github.com/macports/macports-ports/pull/15240

Gcenx commented 2 years ago

Welp @kencu & @mascguy lets see if Ryan takes action for my latest PR modernizing and updating both wine & wine-devel

Gcenx commented 1 year ago

@kencu welp looks like the /opt/bootstrap workaround for curl isn't working..., maybe the new macports bump caused this?

Been trying to rebuild a 10.9 environment and macports fails to download anything from githut/gitlab, clean install into /opt/bootstrap that where curl is installed, then another install into /opt/local using the ---with-curlprefix=/opt/bootstrap still macports can't download.....

Gcenx commented 1 year ago

I’ll retry tonight with the new curl bump but the issue in the logs was it complaining about certs, yet shouldn’t Macports built against libcurl should be using the Macports curl certs…?

Hoping this works with the new bump.

Gcenx commented 1 year ago

Reinstalled OS X Mavericks now theres no issues downloading files using macports libcurl....