wine cannot be built against the 10.14 SDK

[IComplainInComments]

Edit: for anyone who wants to install wine on Mojave, see 56991#comment:70

Simple enough too see what the issue is from the log below. The built cannot move into the directory, after cleaning the port, same thing happens. After running the command again without any cleaning, it reports with "object already exists"; Object being the files.

This is happening on MacOS Mojave build: 18A365a

--->  Fetching archive for wine-devel
--->  Attempting to fetch wine-devel-3.13_0+universal+x11.darwin_18.x86_64.tbz2 from https://packages.macports.org/wine-devel
--->  Attempting to fetch wine-devel-3.13_0+universal+x11.darwin_18.x86_64.tbz2 from http://ywg.ca.packages.macports.org/mirror/macports/packages/wine-devel
--->  Attempting to fetch wine-devel-3.13_0+universal+x11.darwin_18.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/wine-devel
--->  Fetching distfiles for wine-devel
--->  Verifying checksums for wine-devel
--->  Extracting wine-devel
--->  Applying patches to wine-devel
--->  Configuring wine-devel
--->  Building wine-devel
--->  Staging wine-devel into destroot
Error: Failed to destroot wine-devel: error renaming "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_x11_wine-devel/wine-devel/work/destroot/opt/local/bin/wine": no such file or directory
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_x11_wine-devel/wine-devel/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port wine-devel failed

[ryandesign (Ryan Carsten Schmidt)]

You shouldn't disclose information about pre-release versions of macOS in a public place, such as in this issue tracker; see wiki:FAQ#prerelease.

I'm not sure how you even got this far with wine, since wine requires itself and its dependencies to be built universal, which it was my understanding is not possible to do on Mojave. See ​https://lists.macports.org/pipermail/macports-dev/2018-June/039071.html.

[IComplainInComments]

Not disclosing anything thats already publicly known.

And WINE has its dependencies built already, just actually installing the wine-devel in the output above.

[mf2k (Frank Schima)]

32-bit is deprecated in Mojave. Like OpenGL, that means that it will still be in Mojave. After that, it will be removed.

[kode54 (Christopher Snowhill)]

Adding this in, now that Mojave is coming out in less than a week, and Xcode 10 is released to all users, even High Sierra users. Xcode 10 does not support 32 bit compilation at all.

I had this same result trying to install wine-devel on Mojave. Everything 64-bit compiles, and there's a wine64 executable in the staging directory. Just no 32 bit stuff at all.

Looks like we're down to waiting on whatever Codeweavers has in mind for supporting 32 bit code on an all 64 bit system, since they claimed they were working on something for that. Are they still scraping along back at Wine 2.8?

[kencu (Ken)]

I have tested Xcode 10 on 10.13.

I have found that 32 bit projects can be built with Xcode 10 against the command-line tools on 10.13 (configure.sdkroot "/") or against a copy of the MacOSX.10.13.sdk if you move one over from Xcode 9. (configure.sdkroot /path/to/MacOSX.10.13.sdk).

I'm not running Mojave yet, so I can't confirm whether the MacOSX.10.13.sdk works there.

[ryandesign (Ryan Carsten Schmidt)]

In 8331367de9a70be2cd942635fc262c50163c52c4/macports-ports (master):

wine*: Prevent installation on Mojave and later

See: #56991
See: ​https://lists.macports.org/pipermail/macports-users/2018-September/045704.html

Also update similar blocks for big-endian systems and for Tiger to
clear out the dependencies, archives_sites, distfiles.

[mf2k (Frank Schima)]

The new ​version 18 of Wine CrossOver is out with support for Mojave.

[kencu (Ken)]

If anyone has any serious interest in how Wine can be installed on Mojave, just ask. It is possible, with 15 minutes worth of effort.

[ivanschou]

The portable tarballs provide by Wine works fine on Mojave with no effort (​https://dl.winehq.org/wine-builds/macosx/download.html), but we're still waiting for a solution that allows Wine to be managed by MacPorts. It may require an upstream change in Wine to incorporate the changes that the CrossOver team have developed.

[ryandesign (Ryan Carsten Schmidt)]

Ken, if it is something we can incorporate into the Portfile, please describe it here.

[kencu (Ken)]

I'm sorry I haven't been back to this ticket for a while. I've been asked how I did this.

MacPorts has the capability to build ports against a given SDK version, and using a given deployment target. It is not used much, so there are a couple of ports that need some help with it, but the steps were simple.

see 56991#comment:70 for the up-to-date instructions.

[kencu (Ken)]

No longer relevant.

[kencu (Ken)]

a small portfile overlay of minor fixes required to plumb the -isysroot everywhere it is needed

[kencu (Ken)]

Here <​https://github.com/kencu/macports-ports/commits/universalfixes> is a branch of MP with the universal fixes to Portfiles that I've found to date. Some of these fixes may or may not make it into the MacPorts repo over time.

The top commit will be the rebased fixes based on the last time I've looked at it; I'll update it from time to time.

[Gcenx]

Thank you Ken for the information and the patched Ports repository I know i'm not the only one who will find this useful

Using the following caused db48 failed with an error of ld not knowing what -isysroot

@@ -893,14 +893,13 @@
                 append_to_environment_value configure $env_var -isysroot${configure.sdkroot}
             }
             append_to_environment_value configure "LDFLAGS" -Wl,-syslibroot,${configure.sdkroot}
+            append_to_environment_value configure "LDFLAGS" -Wc,-isysroot,${configure.sdkroot}
+            append_to_environment_value configure "LDFLAGS" -Wl,-w
         }

Instead I did the following

@@ -893,14 +893,12 @@
                 append_to_environment_value configure $env_var -isysroot${configure.sdkroot}
             }
             append_to_environment_value configure "LDFLAGS" -Wl,-syslibroot,${configure.sdkroot}
+            append_to_environment_value configure "LDFLAGS" -Wl,-w
         }

Doing the above instead db48 now compiles correctly.

I used this for the following ports, libGLU, lcms2, cario, cmake

if {${configure.sdkroot} ne ""} {
configure.cc-append   -isysroot${configure.sdkroot}
configure.cxx-append  -isysroot${configure.sdkroot}
configure.ldflags-append -w
}

The ports I installed were wine requirements listed within wine-devel plus libsdl2 and mpg123 at the moment, I still have more ports to install for current wine requirements, plus building FAudio from source since macports doesn't currently have a port for it (I'm aware of an open request for that)

[kencu (Ken)]

Edit-no longer relevant.

[kencu (Ken)]

Edit - no longer relevant.

[kencu (Ken)]

see : 57612

[kencu (Ken)]

Edit - no longer relevant.

[Gcenx]

So I see our options as;;

• updating libtool within db48
• forcing our version of libtool over the version included within db48
• or lastly stripping "LDFLAGS" -Wc,-isysroot,${configure.sdkroot} as without that the port does build.

[Gcenx]

Basically can’t we just use configure.ldflags-delete and have that remove the offending flag.

Not near my system but I would assume;

if {${configure.sdkroot} ne ""} {
configure.ldflags-delete -Wc,-isysroot${configure.sdkroot}
}

Should cover it?

[kencu (Ken)]

I wonder if just setting SDKROOT in portconfigure.tcl might work better...

[Gcenx]

It might work.

But then also wouldn’t you also need to add in an exception for ld to not have the issue flag passed? Doing it that way might save needing to patch any other ports that exhibit a similar issue later.

[kencu (Ken)]

Edit - no longer relevant.

[kencu (Ken)]

Edit - no longer relevant with macports 2.6.1

[Gcenx]

So some kinda portover will still be required then, unless macports has another way to add the needed variable globally regardless of it using configure or not.

Currently rebuilding my ports using your port overlay github, only change from your updated information is I used my own wine-devel Portfile since it's slightly updated, as the current one is missing rather a lot of requirements for since the introduction of sdl2 in Wine-3.3.

I also had to add a symlink to the 10.13SDK within /Library/Developer/CommandLineTools/SDKs/ or the building fails.

[kencu (Ken)]

Edit - no longer relevant with macports 2.6.1

[kencu (Ken)]

Now to see if I can get brave enough to try this with MP 2.6 ....

[Gcenx]

Lucky I didn’t far into my build, cleaned up and started over. Used your patch along with the other required edit. Maybe you could also just add in the 10.13 force/sdk changes into the diff also since that would then be all required changes within a single diff?

Side note; I don’t remember the correct command to only install a ports required dependancies and having trouble finding the correct command again. So I’m installing wine-devel just to call all the ports I wanted to test

[kencu (Ken)]

Edit - no longer relevant with macports 2.6.1

[Gcenx]

Nice, so the new version of macports will be even simpler to patch, or maybe it can get upstreamed?

I'll be happy to upload the wine-devel but it's honestly not finished just yet, all I've done for now is add in additional libs, removed MoltenVK since macports installs an ancient version, made sure gnutls is always uses (Wine-3.13+) sdl2 (wine-3.3+ controller support) and mpg123 (mp3 playback) Still need to add in gsm, mingw-w64, unwind and the required patch for Wine-Devel-4.16. And update mono version as required.

Edit: Once the above is done the last Major requirement would be FAudio and a variant that adds ffmpeg with wma support since wine uses FAudio for bascily all audio decoding for a while now........

[kencu (Ken)]

Edit - no longer relevant with macports 2.6.1

[Gcenx]

Replying to kencu:

Replying to Gcenx:

I'll be happy to upload the wine-devel but it's honestly not finished just yet,

OK, well share if you dare -- that's how things move quickly around here.

Edit: Once the above is done the last Major requirement would be FAudio and a variant that adds ffmpeg with wma support since wine uses FAudio for bascily all audio decoding for a while now........

Always a possibility, if someone sees a reason for it...

​https://github.com/Gcenx/macports-wine-devel

• checksums are not updated!
• I enabled the additional ports include build deps
• added a required patch to compile wine-devel-4.16
• updated mono version
• always use gnutls (its needed for tls/ssl/other encryption types now since wine-3.13 on macOS)
• libunwind should be used but could be bypassed if needed using --without-unwind only used for wine64 (currently added wine-4.15)
• changed the max version allowed to compile wine moved to 10.14 (bad idea but for now I needed)

My offline version doesn't have everything enabled as my system is slow as hell

As for FAudio port I know a wine developer had made the request when it become a requirement so since wine-4.3

[kencu (Ken)]

thanks! You seem very helpful! I hope we should see you around here more...

[Gcenx]

Replying to kencu:

thanks! You seem very helpful! I hope we should see you around here more...

Thank you. I might be if time allows focused towards wine related Ports

I've updated the wine-devel Portfile some more

• updated checksums
• updated sizes
• reused the MoltenVK --without/--with section for unwind
• I've guessed and updated the required patch according to the current patches

[kencu (Ken)]

I couldn't find a port request ticket for FAudio so I opened one 59075

[Gcenx]

Replying to kencu:

I couldn't find a port request ticket for FAudio so I opened one 59075

Strange, I'll check with the developer once I see them online.

I commented giving some information, we already build it from source within phoenicis-winebuild but as it's cross-compiling for macOS on Linux I'm not sure how useful the example would be

EDIT; Updated wine-devel some more, corrected the sdk patch, but libgsm fails so I just disabled on my end and mingw-w64 failed due to +universal flag being passed, also flicker patch fails to apply I just disabled that for the moment

[kencu (Ken)]

libvpx does it's own internal macOS SDK selecting and does not respect the $SDKROOT env var, and so would need some surgery to obey -- nothing is perfect. Some other ports probably will do the same thing. That's why integrating stuff like this is never as simple as it seems to be.

[Gcenx]

It's weird wine-devel is failing to compile from within macports, yet using my external script using macports for includes/dylibs/etc works just fine.

I keep seeing the following being spammed like crazy thought the main.log before it finally just fails

:info:build clang: error: SDK ""/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk"" cannot be located
:info:build ld: error: SDK ""/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk"" cannot be located
:info:build nm: error: SDK ""/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk"" cannot be located
:info:build ar: error: SDK ""/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk"" cannot be located
:info:build SDK ""/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk"" cannot be located

This happens regardless of the SDK being a symlink or a copy added into the location.

[kencu (Ken)]

If you're now using MacPorts 2.6, those look like the errors you would see if you were still using the MacPorts 2.5.4 version of quoting. See the two slightly different patches above.

[Gcenx]

Replying to kencu:

If you're now using MacPorts 2.6, those look like the errors you would see if you were still using the MacPorts 2.5.4 version of quoting. See the two slightly different patches above.

Still on 2.5.4 at the moment, I didn’t notice 2.6 was officially released I’ll update add the patch and try again.

[kencu (Ken)]

I thought I would see what people think of the idea <​https://github.com/macports/macports-base/pull/147>.

Silencing the linker warnings with -Wl,-w in base will be impossible to sell, quite rightly, so I won't try that. Perhaps we can do that in the ports that fail due to the warnings -- IIRC,they were the cmake builds, but that was a long while ago now.

[Gcenx]

Replying to kencu:

I thought I would see what people think of the idea <​https://github.com/macports/macports-base/pull/147>.

Silencing the linker warnings with -Wl,-w in base will be impossible to sell, quite rightly, so I won't try that. Perhaps we can do that in the ports that fail due to the warnings -- IIRC,they were the cmake builds, but that was a long while ago now.

I agree silencing ld isn't good, if the rest can get upstreamed that will be good still.

Only port I'm still having issues with that I tested currently is libgsm..... instantly fails, so that's disabled within my updated wine-devel Portfile still need to add in FAudio just didn't updated my port db at the moment as i'm still tweaking wine-devel Not sure if my change for mingw-w64 is correct but passing it +universal makes it freak out....

[kencu (Ken)]

Replying to Gcenx:

Only port I'm still having issues with that I tested currently is libgsm..... instantly fails,

fixed in [314d3697cf40e8918955d1478f14d09a3f6de48e/macports-ports]

[Gcenx]

While waiting on the mingw-w64 issue to be resolved I added some additional ports into my wine-devel and got stuck on gstreamer1-gst-plugins-good the part that failed was libvpx the remaining ports after this were taglib twolame wavpack

The other I want to add will be gstreamer1-gst-plugins-bad behind a variant, I'm sure that will have some failure points on this setup along with ffmpeg last I checked goes and compiles llvm/clang that's then used to compiled ffmpeg (no idea why when I've compiled it with XCode9 previously before Proton removed macOS support)

[kencu (Ken)]

the libvpx fix is 56991#comment:51 above.

[Gcenx]

Your correct sorry about that, I was rushing to work at the time.

I hope another way can be found so doesn’t need to be edited later I’m guessing it’s possible if the changes you proposed get upstreamed?

[kencu (Ken)]

even more fun and games... with this same setup, you can install, say the 10.7 SDK, set your macports.conf setting like so:

macosx_deployment_target     10.7
macosx_sdk_version           10.7

and presto. You're building (on Mojave) against the 10.7 SDK easy as pie. WAYY easier than a VM to fix some issue.

/usr/bin/clang -DHAVE_CONFIG_H -I. -I./src   -I/opt/universalnew/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.7.sdk  -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.7.sdk -arch x86_64 -arch i386 -D_THREAD_SAFE -pthread  -Wall -Wextra -Wformat=2 -Wno-format-nonliteral -Wshadow -Wpointer-arith -Wcast-qual -Wmissing-prototypes -Wno-missing-braces -std=gnu89 -D_GNU_SOURCE -c -o src/zfile.o src/zfile.c
src/decompress.c:52:31: warning: cast from 'const void *' to 'unsigned char *' drops const qualifier [-Wcast-qual]
    stream.next_in = (Bytef *)buf;
                              ^
1 warning generated.
src/decompress.c:52:31: warning: cast from 'const void *' to 'unsigned char *' drops const qualifier [-Wcast-qual]
    stream.next_in = (Bytef *)buf;
                              ^
1 warning generated.
/usr/bin/clang  -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.7.sdk -arch x86_64 -arch i386 -D_THREAD_SAFE -pthread  -Wall -Wextra -Wformat=2 -Wno-format-nonliteral -Wshadow -Wpointer-arith -Wcast-qual -Wmissing-prototypes -Wno-missing-braces -std=gnu89 -D_GNU_SOURCE  -L/opt/universalnew/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX10.7.sdk -Wl,-w -arch x86_64 -arch i386 -o ag src/ignore.o src/log.o src/options.o src/print.o src/print_w32.o src/scandir.o src/search.o src/lang.o src/util.o src/decompress.o src/main.o src/zfile.o -L/opt/universalnew/lib -lpcre -L/opt/universalnew/lib -llzma   -lz  
make[1]: Entering directory `/opt/universalnew/var/macports/build/_opt_universalnew_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_the_silver_searcher/the_silver_searcher/work/the_silver_searcher-2.2.0'
make[1]: `ag' is up to date.

[kencu (Ken)]

Just a few things.

1. All our bazillion Portfile tests for ${os.version} would have to be changed to ${configure.macosx_deployment_target} or ${configure.macosx_sdk_version} instead to work properly...
2. Be very careful not to overwrite your libc++.dylb! I'm pretty sure that SIP won't let you anyway.
3. Installing against any MacPorts-installed library in the ${prefix} will work fine, but I wonder if there is any way to install software that links against (and uses) another version of libc++.dylib? That would be useful for a whole bunch of reasons, not the least of which would be building against the modified libc++ I made for 10.6.8...

Always fun to make this system run circles...

[Gcenx]

In reguards to libvpx if configure.sdkroot is a global variable why not instead use that like so

@@ -882,7 +854,7 @@
       fi
       ;;
     x86*-darwin*)
-      osx_sdk_dir="$(show_darwin_sdk_path macosx)"
+      osx_sdk_dir="$(configure.sdkroot)"
       if [ -d "${osx_sdk_dir}" ]; then
         add_cflags  "-isysroot ${osx_sdk_dir}"
         add_ldflags "-isysroot ${osx_sdk_dir}"

I updated patch-build-make-configure.sh.diff adding the above and then install the port without issue.

bash-3.2# port -s install libvpx
--->  Computing dependencies for libvpx
--->  Fetching distfiles for libvpx
--->  Verifying checksums for libvpx
--->  Extracting libvpx
--->  Applying patches to libvpx
--->  Configuring libvpx
--->  Building libvpx
--->  Staging libvpx into destroot
--->  Installing libvpx @1.8.1_0
--->  Activating libvpx @1.8.1_0
--->  Cleaning libvpx
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.

Done without the +universal hack, so this would also work as an upstream change.

Also built using +universal hack

bash-3.2# port install libvpx +universal
--->  Computing dependencies for libvpx
--->  Fetching archive for libvpx
--->  Attempting to fetch libvpx-1.8.1_0+universal.darwin_18.i386-x86_64.tbz2 from https://packages.macports.org/libvpx
--->  Attempting to fetch libvpx-1.8.1_0+universal.darwin_18.i386-x86_64.tbz2 from http://ywg.ca.packages.macports.org/mirror/macports/packages/libvpx
--->  Attempting to fetch libvpx-1.8.1_0+universal.darwin_18.i386-x86_64.tbz2 from http://aus.us.packages.macports.org/macports/packages/libvpx
--->  Fetching distfiles for libvpx
--->  Verifying checksums for libvpx
--->  Extracting libvpx
--->  Applying patches to libvpx
--->  Configuring libvpx
--->  Building libvpx
setting build SDKROOT to /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
setting build SDKROOT to /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
setting build SDKROOT to /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
setting build SDKROOT to /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
setting build SDKROOT to /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
setting build SDKROOT to /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
setting build SDKROOT to /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
setting build SDKROOT to /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
setting build SDKROOT to /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
setting build SDKROOT to /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
--->  Staging libvpx into destroot
setting destroot SDKROOT to /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
setting destroot SDKROOT to /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
--->  Installing libvpx @1.8.1_0+universal
--->  Activating libvpx @1.8.1_0+universal
--->  Cleaning libvpx
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.

Replying to kencu:

Just a few things.

1. All our bazillion Portfile tests for ${os.version} would have to be changed to ${configure.macosx_deployment_target} or ${configure.macosx_sdk_version} instead to work properly...
2. Be very careful not to overwrite your libc++.dylb! I'm pretty sure that SIP won't let you anyway.
3. Installing against any MacPorts-installed library in the ${prefix} will work fine, but I wonder if there is any way to install software that links against (and uses) another version of libc++.dylib? That would be useful for a whole bunch of reasons, not the least of which would be building against the modified libc++ I made for 10.6.8...

Always fun to make this system run circles...

That would be a lot of work, but sounds fun. Also I'm sure if anyone is messing with this they already have SIP disabled.

[Gcenx]

Changed "patch-build-make-configure.sh.diff" works with and without +universal hack

[mf2k (Frank Schima)]

I'm following along hoping to get wine working on Mojave and beyond. I tried updating the wine portfile to build with this patchfile but fails to apply. Maybe I'm doing something wrong though.

:info:patch --->  Applying patch-build-make-configure.sh.diff
:debug:patch Environment: 
:debug:patch CC_PRINT_OPTIONS='YES'
:debug:patch CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports_macports-ports_x11_wine/wine/work/.CC_PRINT_OPTIONS'
:debug:patch CPATH='/opt/local/include'
:debug:patch DEVELOPER_DIR='/Library/Developer/CommandLineTools'
:debug:patch LIBRARY_PATH='/opt/local/lib'
:debug:patch MACOSX_DEPLOYMENT_TARGET='10.14'
:info:patch Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports_macports-ports_x11_wine/wine/work/wine-3.0.4" && /usr/bin/patch -p0 < '/opt/local/var/macports/sources/github.com/macports/macports-ports/x11/wine/files/patch-build-make-configure.sh.diff'
:debug:patch system:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports_macports-ports_x11_wine/wine/work/wine-3.0.4" && /usr/bin/patch -p0 < '/opt/local/var/macports/sources/github.com/macports/macports-ports/x11/wine/files/patch-build-make-configure.sh.diff'
:info:patch can't find file to patch at input line 3
:info:patch Perhaps you used the wrong -p or --strip option?
:info:patch The text leading up to this was:
:info:patch --------------------------
:info:patch |--- build/make/configure.sh.orig	2019-09-25 18:56:09.000000000 -0400
:info:patch |+++ build/make/configure.sh	2019-09-25 18:44:14.000000000 -0400
:info:patch --------------------------
:info:patch File to patch: 
:info:patch Skip this patch? [y] 
:info:patch Skipping patch.
:info:patch 3 out of 3 hunks ignored

[kencu (Ken)]

That patch is for libvpx -- I guess we were not totally clear on that.

Also, once you get it going, his updated wine-devel <​https://github.com/Gcenx/macports-wine-devel> is right up to the minute.

[mf2k (Frank Schima)]

Oh yeah, I see now that I totally missed that. Thank you!

[Gcenx]

@mf2k as @kencu mentioned the patch I added for for libvpx as it won’t build without the patch being changed. My bad for not adding a comment before explaining that but I can’t go back and edit it now unfortunately. Also before using the linked wine-devel install mingw-w64 or it will fail.

@kencu you think is possible to replace the current upstreamed patch with the version I provided? Won’t break anything and more conforms to macports standards. It also means that forcing an SDK as were doing will also work.

[kencu (Ken)]

Replying to Gcenx:

@kencu you think is possible to replace the current upstreamed patch with the version I provided?

Probably. The port maintainer will look at what the benefit is, and how many systems might break unexpectedly. You'd be surprised at the unexpected wreckage we see all the time from patches that seem to work fine on several systems :>

I would probably have to build it on every system to show him it works.

And then there's be the question about the next version of libvpx, and will anything be different. So, although it seems pretty trivial, in the end there is always a certain amount of pushback for these reasons.

[Gcenx]

Replying to kencu:

Replying to Gcenx:

@kencu you think is possible to replace the current upstreamed patch with the version I provided?

Probably. The port maintainer will look at what the benefit is, and how many systems might break unexpectedly. You'd be surprised at the unexpected wreckage we see all the time from patches that seem to work fine on several systems :>

I would probably have to build it on every system to show him it works.

And then there's be the question about the next version of libvpx, and will anything be different. So, although it seems pretty trivial, in the end there is always a certain amount of pushback for these reasons.

I’m honestly asking because of what you explained, I stuck to the macports guidelines for Portfile’s with the patch changing the original files way of selecting the SDK to the macports recommenced way. Though I do see some gaps within the examples causing the ticket I opened for mingw-w64.

I uploaded the remade .diff as a just incase it can’t be accepted for some reason it’s at least available, it’s easy enough to swap out the original patch with the one I uploaded.

[kencu (Ken)]

Condensed instructions, for anyone who wants to try this.

1. build a new installation of MacPorts from source in /opt/universal.
2. modify macports.conf like this:

   macosx_deployment_target     10.13
   macosx_sdk_version           10.13
   

3. add the MacOS10.13.sdk here:

   /Library/Developer/CommandLineTools/SDKs/MacOS10.13.sdk
   

And that is pretty much it.

If you would like to try Gcenx's very up-to-date wine port it's here: <​https://github.com/Gcenx/macports-wine/>.

[Gcenx]

The patch was for libvpx not libpx

[kencu (Ken)]

Thanks! proofreading is essential!

[Gcenx]

No problem, I don't proofread my own posts half the time due to being on my phone most of the time.

Also might want to explain the libvpx diff is a replacement for the original, it’s not a patch to update the current one (I guess I could make one to do that if needed)

But I wouldn't recommend installing the SDK directly into /Library/Developer/CommandLineTools/SDKs/ a better location would be the old /Developer/SDKs if it doesn't exist make it and store all SDK versions within that location then symlink them into /Library/Developer/CommandLineTools/SDKs/

I keep MacOSX10.8.sdk to MacOSX10.14.sdk there and just made a symlink for MacOSX10.15.sdk since that won't be final for quite some time. Doing this I'm able to change CommandLineTool's version if needed without losing an SDK

[Gcenx]

I’ve updated the wine-devel Portfile more, now includes using gstreamer1-gst-plugins-good along with gstreamer1-gst-libav and added gstreamer1-gst-plugins-bad behind the +ffmpeg variant.

I’m not sure if gstreamer1-gst-plugins-bad failing is related to using the +universal hack on Mojave or an upstream issue.

Since wine-devel seems mostly correct now I’ll get wine and wine-crossover updated next those should be quicker.

[Gcenx]

Well libass doesn't want to build

:info:build ld: illegal text-relocation to 'words_tile16' in x86/.libs/rasterizer.o from '_ass_fill_halfplane_tile16_sse2' in x86/.libs/rasterizer.o for architecture i386
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)
:info:build make[2]: *** [libass.la] Error 1

The previous command to suppress the issue no longer functions on XCode10, I seen it was recommended to use XCode9 so I did sudo xcode-select --switch /Applications/Xcode_9.4.1.app as that's its name on my system but then I get the following error

bash-3.2# yes | port install wine-devel +universal +x11 -pulseaudio +ffmpeg
Error: The installed version of Xcode (9.4.1) is too old to use on the installed OS version. Version 10.0 or later is recommended on macOS 10.14.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port wine-devel failed

Edited portutil.tcl to allow the usage of XCode9 again to see if it helps

[kencu (Ken)]

I don't think it's an xcode thing. It's a 32bit ABI thing. The usual fix is to add -read_only_relocs suppress to the LD flags for the 32 bit build, but it doesn't always work so easily. That is something you might have to dig in on.

[kencu (Ken)]

having said that libass does build universal, at least sometimes, eg

  libass @0.14.0_0+universal (active) platform='darwin 10' archs='i386 x86_64' date='2019-04-04T14:34:14-0700'

[Gcenx]

Edit - No longer relevant libass was fixed upstream

[mf2k (Frank Schima)]

Replying to kencu:

5. add the MacOS10.13.sdk here:

   /Library/Developer/CommandLineTools/SDKs/MacOS10.13.sdk
   

How do I get this? I'm attempting this on Catalina.

[kencu (Ken)]

I think it's not possible on Catalina -- AFAIK, the i386 libs are gone in Catalina.

[Gcenx]

Not possible, macOS Catalina removes all 32Bit support. You will need to downgrade or wait on CrossOver 19 source to be released, CrossOver19 if the Catalina support changes aren’t stripped will require a custom version of clang to compile the source for 32Bit support.

[kencu (Ken)]

Edit - No longer relevant with macports 2.6.1

[Gcenx]

Replying to kencu:

I have some great news, Gcenx! The fix has been accepted into base in a more elegant form, and you and I and anyone else who needs it should be able to count on this for the future [dabf0a7a6043bd3b356f9b99df399159153d8c61/macports-base]

That's awesome!, Might wanna update the instructions again then

I've updated wine, wine-crossover & wine-devel along with pre modified libass and libvpx along with pre-generated PortIndex files.

• wine is now Wine-4.0.2 with a patch to fix the font rendering (additional libs etc)
• wine-crossover Slight updates to make use additional libs like sdl2,gnutls etc, removed the unneeded patches etc
• wine-devel I've added ffmpeg variant for gstreamer1-gst-plugins-bad that also enforced ffmpeg variant for FAudio

Only thing now would be a modified version of MoltenVK that downloads and unpackages the SDK instead of building the ancient version from source.

[christopher-b]

Hi Folks,

First, thanks to all of you for your work on this! I'm following along trying to get wine-devel installed, but I get ​tripped up installing python37. Any idea where I might have gone wrong?

:info:destroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/IOKit.framework/Headers/IOTypes.h:38:10: fatal error: 'IOKit/IOReturn.h' file not found
:info:destroot #include <IOKit/IOReturn.h>
:info:destroot          ^~~~~~~~~~~~~~~~~~

The steps I followed:

• Installed macports from source
• Updated macports.conf and variants.conf as per ​comment 70
• Copied and symlinked MacOS10.13.sdk
• Patched the tcl files (BTW, for anyone else new to this and figuring it out, the files are in /opt/universal/var/macports/sources/rsync.macports.org/macports/release/tarballs/base/src/port1.0, not /opt/universal/libexec/macports/lib/port1.0/)
• Installed ​https://github.com/kencu/macports-ports and ​https://github.com/Gcenx/macports-wine-devel as sources
• Installed mingw-w64 -universal

Any thoughts on the python error? Thanks!

[kencu (Ken)]

Edit - No longer relevant with macports 2.6.1

[kencu (Ken)]

Edit - No longer relevant with macports 2.6.1

[christopher-b]

Replying to kencu:

The correct tcl files to patch are indeed here and not the ones you mentioned:

/opt/universal/libexec/macports/lib/port1.0/

Ah, my mistake. I must have misinterpreted something. I'll edit my original comment so as not to confuse anyone else. I'll give it another go, thanks.

[Gcenx]

Edit - No longer relevant with macports 2.6.1

[Gcenx]

Replying to christopher-b:

Hi Folks,

First, thanks to all of you for your work on this! I'm following along trying to get wine-devel installed, but I get ​tripped up installing python37. Any idea where I might have gone wrong?

:info:destroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/IOKit.framework/Headers/IOTypes.h:38:10: fatal error: 'IOKit/IOReturn.h' file not found
:info:destroot #include <IOKit/IOReturn.h>
:info:destroot          ^~~~~~~~~~~~~~~~~~
Any thoughts on the python error? Thanks!

That does sound weird I also didn’t get that issue even when I was using Ken’s repo, did you grab the 10.13 SDK from XCode9.4.1?

The default install option for wine-devel will be missing gstreamer1-gst-plugins-bad and FAudio won’t have wma support, to installed that you need to use +ffmpeg when installing wine, wine-crossover or wine-devel be warned it will take hours to complete.

Also no MoltenVK support right now as the current Port is ancient, I’m putting together a custom MoltenVK Port that will use the prebuilt SDK instead, that will give support from 10.11 and above.

[Gcenx]

Edit - No longer relevant

[kencu (Ken)]

This part should not needed any longer:

+            append_to_environment_value configure "SDKROOT" ${configure.sdkroot}

if you use the official patch [dabf0a7a6043bd3b356f9b99df399159153d8c61/macports-base] that made it into base.

ncurses builds fine +universal for me with the official base patch.

I will try the others.

[Gcenx]

Here is a simple patch for macports 2.6.1

diff -u /opt/universal/etc/macports/macports.conf.orig /opt/universal/etc/macports/macports.conf
--- /opt/universal/etc/macports/macports.conf.orig	                        2019-09-27 22:22:38.000000000 -0400
+++ /opt/universal/etc/macports/macports.conf	                            2019-09-27 22:22:14.000000000 -0400
@@ -1,6 +1,9 @@
 # MacPorts system-wide configuration file.
 # Commented-out values are defaults unless otherwise noted.
 
+macosx_deployment_target     10.13
+macosx_sdk_version           10.13
+
 # Directory under which MacPorts should install ports. This must be
 # where MacPorts itself is installed.
 prefix              	/opt/universal

[Gcenx]

I’ve added a custom MoltenVK Port that will download and extract the current Vulkan SDK, instead of compiling from source that means El Capitan and above can have Vulkan support within wine64.

• Updated the wine, wine-crossover & wine-devel to take advantage of my custom MoltenVK
• Included an updated FAudio port

Next thing is figuring out how to make a wine-staging port, I think I have an idea now that I’ve gotten my version of MoltenVK done

[kencu (Ken)]

The primary base patch that enables this functionality now is in the new release of MacPorts-2.6.1, so this just became that much easier.

I'm going to go back and find out where exactly I saw the errors that -Wl,-w suppressed, and try to get those into the port directly if I can.

[Gcenx]

Replying to kencu:

The primary base patch that enables this functionality now is in the new release of MacPorts-2.6.1, so this just became that much easier.

I'm going to go back and find out where exactly I saw the errors that -Wl,-w suppressed, and try to get those into the port directly if I can.

The alternative could be if “macosx_sdk_version” is forced -Wl,-w like the patch that made it into base since by default this won’t be required only if someone if forcing an SDK version would it be required

[kencu (Ken)]

The error was in the build of cmake, and it is fixed with a simple addition to the cmake Portfile. So (hopefully) no more addtions to base.

I'm going to put together a simpler guide for people, as this is literally a 5 minute project for those who are interested.

[Gcenx]

Replying to kencu:

The error was in the build of cmake, and it is fixed with a simple addition to the cmake Portfile. So (hopefully) no more addtions to base.

I'm going to put together a simpler guide for people, as this is literally a 5 minute project for those who are interested.

So no more need for -Wl,-w nice, so only other upstream package with an issue would be libvpx due to the fixed SDK selection.

Should I make an enhancement ticket for that?

Also thanks for updating FAudio upstream I'll remove my version now

[kencu (Ken)]

I don't think a ticket will do it -- this is not an easy thing to sell (a hack in a Portfile for a corner case). I'll see what I can get away with. If the cmake port maintainer is interested in doing this, that will help :> For now I put them all here again <​https://github.com/kencu/macports-ports/tree/universalfixes> (but much simpler now, as no base hacking needed - so far).

[Gcenx]

Replying to kencu:

I don't think a ticket will do it -- this is not an easy thing to sell (a hack in a Portfile for a corner case). I'll see what I can get away with. If the cmake port maintainer is interested in doing this, that will help :> For now I put them all here again <​https://github.com/kencu/macports-ports/tree/universalfixes> (but much simpler now, as no base hacking needed - so far).

I guess libvpx would also fall into a corner case also shame, the change I made was the recommended way to handle SDK selection, but now that the SDK change is within the current base version that should make it more attractive. That's the port I mean for an enhancement ticket. If Ryan also finishes his OSX.SDK port that would be even better, if it also handles editing macports.conf to add in the required macosx_deployment_target & macosx_sdk_version that would make it even more useful.

You can take any of my custom ports and add them into your macports-ports listing if you like.

[kencu (Ken)]

I edited a few of the longer and no-longer-relevant comments above to reduce confusion for anyone who wants to try this.

[Gcenx]

Replying to kencu:

I edited a few of the longer and no-longer-relevant comments above to reduce confusion for anyone who wants to try this.

I’d done the same, I’m sure your aware since I tagged you, you can remove the libvpx patch from your universal branch when you next rebased it.

[akj850]

Ran into some difficulties with the chromaprint port, I can't tell if its related to the universal build or just source problems in the code tree. Has anyone built that successfully?

[Gcenx]

Replying to akj850:

Ran into some difficulties with the chromaprint port, I can't tell if its related to the universal build or just source problems in the code tree. Has anyone built that successfully?

I did a quick look over the Portfile and don't see any potential issue within chromaprint , however I did find an error with libomp and since ffmpeg required clang ports that could have been the issue. My pull-request has been committed so check again later.

[akj850]

Thanks. I did a package update, and got several rebuilds, but libomp was not installed (I did build it without problem). The chromaprint problem persists (perhaps I was too impatient to wait for your updates to roll out?)

Building CXX object src/cmd/CMakeFiles/fpcalc.dir/fpcalc.cpp.o
cd /opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/build/src/cmd && /usr/bin/clang++  -DHAVE_CONFIG_H -D_SCL_SECURE_NO_WARNINGS -D_USE_MATH_DEFINES -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -I/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/build -I/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src -I/opt/local/include  -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -std=c++11 -DNDEBUG -arch x86_64 -arch i386 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.13   -o CMakeFiles/fpcalc.dir/fpcalc.cpp.o -c /opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/cmd/fpcalc.cpp
In file included from /opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/cmd/fpcalc.cpp:7:
/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/audio/ffmpeg_audio_reader.h:117:2: warning: 'av_register_all' is deprecated [-Wdeprecated-declarations]
        av_register_all();
        ^
/opt/local/include/libavformat/avformat.h:2049:1: note: 'av_register_all' has been explicitly marked deprecated here
attribute_deprecated
^
/opt/local/include/libavutil/attributes.h:94:49: note: expanded from macro 'attribute_deprecated'
#    define attribute_deprecated __attribute__((deprecated))
                                                ^
In file included from /opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/cmd/fpcalc.cpp:7:
In file included from /opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/audio/ffmpeg_audio_reader.h:18:
/opt/local/include/libavcodec/avcodec.h:1454:16: warning: 'convergence_duration' is deprecated [-Wdeprecated-declarations]
typedef struct AVPacket {
               ^
/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/audio/ffmpeg_audio_reader.h:123:12: note: in implicit copy assignment operator for 'AVPacket' first required here
        m_packet0 = m_packet;
                  ^
/opt/local/include/libavcodec/avcodec.h:1505:5: note: 'convergence_duration' has been explicitly marked deprecated here
    attribute_deprecated
    ^
/opt/local/include/libavutil/attributes.h:94:49: note: expanded from macro 'attribute_deprecated'
#    define attribute_deprecated __attribute__((deprecated))
                                                ^
In file included from /opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/cmd/fpcalc.cpp:7:
In file included from /opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/audio/ffmpeg_audio_reader.h:18:
/opt/local/include/libavcodec/avcodec.h:1454:16: warning: 'convergence_duration' is deprecated [-Wdeprecated-declarations]
typedef struct AVPacket {
               ^
/opt/local/include/libavcodec/avcodec.h:1505:5: note: 'convergence_duration' has been explicitly marked deprecated here
    attribute_deprecated
    ^
/opt/local/include/libavutil/attributes.h:94:49: note: expanded from macro 'attribute_deprecated'
#    define attribute_deprecated __attribute__((deprecated))
                                                ^
In file included from /opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/cmd/fpcalc.cpp:7:
/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/audio/ffmpeg_audio_reader.h:130:2: warning: 'av_free_packet' is deprecated [-Wdeprecated-declarations]
        av_packet_unref(&m_packet0);
        ^
/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/audio/ffmpeg_audio_reader.h:27:25: note: expanded from macro 'av_packet_unref'
#define av_packet_unref av_free_packet
                        ^
/opt/local/include/libavcodec/avcodec.h:4472:1: note: 'av_free_packet' has been explicitly marked deprecated here
attribute_deprecated
^
/opt/local/include/libavutil/attributes.h:94:49: note: expanded from macro 'attribute_deprecated'
#    define attribute_deprecated __attribute__((deprecated))
                                                ^
In file included from /opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/cmd/fpcalc.cpp:7:
/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/audio/ffmpeg_audio_reader.h:181:55: warning: 'codec' is deprecated [-Wdeprecated-declarations]
        m_codec_ctx = m_format_ctx->streams[m_stream_index]->codec;
                                                             ^
/opt/local/include/libavformat/avformat.h:884:5: note: 'codec' has been explicitly marked deprecated here
    attribute_deprecated
    ^
/opt/local/include/libavutil/attributes.h:94:49: note: expanded from macro 'attribute_deprecated'
#    define attribute_deprecated __attribute__((deprecated))
                                                ^
In file included from /opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/cmd/fpcalc.cpp:7:
/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/audio/ffmpeg_audio_reader.h:194:12: error: use of undeclared identifier 'avcodec_alloc_frame'
        m_frame = av_frame_alloc();
                  ^
/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/audio/ffmpeg_audio_reader.h:31:24: note: expanded from macro 'av_frame_alloc'
#define av_frame_alloc avcodec_alloc_frame
                       ^
/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/audio/ffmpeg_audio_reader.h:232:2: error: use of undeclared identifier 'avcodec_free_frame'; did you mean 'avcodec_get_name'?
        av_frame_free(&m_frame);
        ^~~~~~~~~~~~~
        avcodec_get_name
/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/audio/ffmpeg_audio_reader.h:35:23: note: expanded from macro 'av_frame_free'
#define av_frame_free avcodec_free_frame
                      ^
/opt/local/include/libavcodec/avcodec.h:6175:13: note: 'avcodec_get_name' declared here
const char *avcodec_get_name(enum AVCodecID id);
            ^
In file included from /opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/cmd/fpcalc.cpp:7:
/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/audio/ffmpeg_audio_reader.h:232:16: error: cannot initialize a parameter of type 'enum AVCodecID' with an rvalue of type 'AVFrame **'
        av_frame_free(&m_frame);
                      ^~~~~~~~
/opt/local/include/libavcodec/avcodec.h:6175:45: note: passing argument to parameter 'id' here
const char *avcodec_get_name(enum AVCodecID id);
                                            ^
In file included from /opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/cmd/fpcalc.cpp:7:
/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/audio/ffmpeg_audio_reader.h:274:4: warning: 'av_free_packet' is deprecated [-Wdeprecated-declarations]
                        av_packet_unref(&m_packet0);
                        ^
/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/audio/ffmpeg_audio_reader.h:27:25: note: expanded from macro 'av_packet_unref'
#define av_packet_unref av_free_packet
                        ^
/opt/local/include/libavcodec/avcodec.h:4472:1: note: 'av_free_packet' has been explicitly marked deprecated here
attribute_deprecated
^
/opt/local/include/libavutil/attributes.h:94:49: note: expanded from macro 'attribute_deprecated'
#    define attribute_deprecated __attribute__((deprecated))
                                                ^
In file included from /opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/cmd/fpcalc.cpp:7:
/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/chromaprint-1.4.3/src/audio/ffmpeg_audio_reader.h:297:9: warning: 'avcodec_decode_audio4' is deprecated [-Wdeprecated-declarations]
                ret = avcodec_decode_audio4(m_codec_ctx, m_frame, &m_got_frame, &m_packet);
                      ^
/opt/local/include/libavcodec/avcodec.h:4778:1: note: 'avcodec_decode_audio4' has been explicitly marked deprecated here
attribute_deprecated
^
/opt/local/include/libavutil/attributes.h:94:49: note: expanded from macro 'attribute_deprecated'
#    define attribute_deprecated __attribute__((deprecated))
                                                ^
7 warnings and 3 errors generated.
make[2]: *** [src/cmd/CMakeFiles/fpcalc.dir/fpcalc.cpp.o] Error 1
make[2]: Leaving directory `/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/build'
make[1]: *** [src/cmd/CMakeFiles/fpcalc.dir/all] Error 2
make[1]: Leaving directory `/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/build'
make: *** [all] Error 2
make: Leaving directory `/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/build'
Command failed:  cd "/opt/universal/var/macports/build/_opt_universal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_chromaprint/chromaprint/work/build" && /usr/bin/make -j6 -w all VERBOSE=ON 
Exit code: 2
Error: Failed to build chromaprint: command execution failed

[akj850]

Replying to Gcenx:

Replying to akj850:

Ran into some difficulties with the chromaprint port, I can't tell if its related to the universal build or just source problems in the code tree. Has anyone built that successfully?

I did a quick look over the Portfile and don't see any potential issue within chromaprint , however I did find an error with libomp and since ffmpeg required clang ports that could have been the issue. My pull-request has been committed so check again later.

Sorry for such a basic question, but is it just a selfupdate with an upgrade outdated to pull your changes? Unfortunately, that did not seem to do the trick for me..

[Gcenx]

Replying to akj850:

Sorry for such a basic question, but is it just a selfupdate with an upgrade outdated to pull your changes? Unfortunately, that did not seem to do the trick for me..

That’s correct unless your using kencu’s universal repository then it won't. Kencu’s also not rebased it to head recently probably busy.

I’m not using kencu’s universal repository, instead I setup a local port repository that contains only my custom Portfiles that’s set above the official listing to ensure mine are used, unlike the current instructions I’m still injecting LDFLAGS=-Wl,-w via macports-base when forcing an SDK version.

I’ve looked over the provided log (it’s not a full log) and I see no reason for it fail as it’s just warning about depreciated code, as that port is using gmake and part of the cmake group it could be suffering from the same issue as cmake so you could try editing the chromaprint Portfile and adding

    # suppress a linker warning when building 32bit on Mojave that makes cmake barf
    if {${os.arch} eq "i386" && ${os.major} == 18} {
        configure.env-append "LDFLAGS=-Wl,-w"
    }

Or just configure.env-append "LDFLAGS=-Wl,-w" if the warning are seen as errors one of the two should resolve the issue your having.

[kencu (Ken)]

Indeed it would not be a surprise to find a few other ports that error when ld64 returns a warning...

That's why at first I put it in base, but later popped it out to cmake, in hopes that might be the only one.

I might get Michael to acccept that into cmake, but it's unlikely to be accepted into base.

I'll update the universalfixes overlay today; was just waiting to see where the dust settled w libvpx fallout...

[Gcenx]

Replying to kencu:

Indeed it would not be a surprise to find a few other ports that error when ld64 returns a warning...

That's why at first I put it in base, but later popped it out to cmake, in hopes that might be the only one.

I might get Michael to acccept that into cmake, but it's unlikely to be accepted into base.

I'll update the universalfixes overlay today; was just waiting to see where the dust settled w libvpx fallout...

Maybe -Wno-deprecated-declarations could be accepted into base instead to stop ld64 taking an error as a warning for no reason....

I've attached logs to the pull-request for libvpx, lets see what become of that. I have to fix up MoltenVK a little more before attempting a pull-request on that one, then look into mingw-w64 error so I can then try getting the wine ports updated

[kencu (Ken)]

Replying to Gcenx:

Maybe -Wno-deprecated-declarations could be accepted into base instead to stop ld64 taking an error as a warning for no reason....

If that worked... that is a compiler flag, and the error is coming from the linker. I will admit though, I never tried that, not imagining it could work.

[Gcenx]

Replying to kencu:

If that worked... that is a compiler flag, and the error is coming from the linker. I will admit though, I never tried that, not imagining it could work.

The compiler is passing the warnings on to ld64, or the direct ld/ld64 would be -no-fatal-warnings

-fatal_warnings
Causes the linker to exit with a non-zero value if any warnings were emitted.

[akj850]

Replying to Gcenx:

Replying to kencu:

If that worked... that is a compiler flag, and the error is coming from the linker. I will admit though, I never tried that, not imagining it could work.

The compiler is passing the warnings on to ld64, or the direct ld/ld64 would be -no-fatal-warnings

-fatal_warnings
Causes the linker to exit with a non-zero value if any warnings were emitted.

Thanks for working on this. I'm afraid I haven't had any luck executing your suggestions successfully. I've tried mods to the Portfile to add configure.env-append "LDFLAGS=-Wl,-w" and to add -Wno-deprecated-declarations and then tried to execute the command from the command line directly and got the same 7 warnings and 3 errors.

Do I need to do something to pull down Ken's updated Portfile? I did selfupdate and upgrade outdated...

Thanks much!

[kencu (Ken)]

I updated the universalfixes repo. I'll try building chromaprint and see what happens. I'm very glad you find this useful -- MacPorts is -- TBH -- the most powerful package manager available for macOS. Only something this well engineered could hope to force the OS to do these things. We should all feel very grateful that Apple engineers have launched such a robust product.

[Gcenx]

I’ve updated my wine-devel Portfile to 4.21 and also uploaded a rough wine-staging Portfile, wine, wine-devel & wine-crossover had the new conflict added. MoltenVK is also updated to 1.1.126.0 still unpacking LunarG SDK

I’m not finding much information on how subports function, I want to modify destroot within a subports so I can have MoltenVK and VulkanSDK within a single Portfile.
Yeah macports is great, everyone always says brew... but it screws with system permissions so a security risk and refuses to link some installed items like bison......

[ivanschou]

According to ​https://apple.stackexchange.com/questions/373851/how-to-get-wine-working-on-catalina it's possible to build only the 64-bit support in wine and run 64-bit Windows apps? I thought the 32-bit wine was required for wine to work. Is it possible to get MacPorts to build wine for x86_64 and at least run 64-bit Windows apps?

[ryandesign (Ryan Carsten Schmidt)]

Yes, it is possible to build wine 64-bit only, and then you can run 64-bit Windows software with it.

MacPorts does not offer a way to install wine in this manner. I considered offering this, but did not get around to doing it, because I predicted it would be of limited utility. I am under the impression that much Windows software is still 32-bit only—and if not the software itself, then its installer—but I don't know how accurate my impression is.

In the meantime, Codeweavers have released Crossover 19 which supports 32-bit software in 64-bit mode, and thus supports Catalina. I have not yet looked into updating the wine-crossover port to this version, nor whether doing so would include these improvements so that MacPorts too can offer this on Catalina. If I understand correctly, the corresponding version of wine will be 5. There are already releases candidates of wine 5 out. I will update the wine-devel port to the latest 5.0rc at some point.

[Gcenx]

Replying to ryandesign:

Yes, it is possible to build wine 64-bit only, and then you can run 64-bit Windows software with it.

MacPorts does not offer a way to install wine in this manner. I considered offering this, but did not get around to doing it, because I predicted it would be of limited utility. I am under the impression that much Windows software is still 32-bit only—and if not the software itself, then its installer—but I don't know how accurate my impression is.

In the meantime, Codeweavers have released Crossover 19 which supports 32-bit software in 64-bit mode, and thus supports Catalina. I have not yet looked into updating the wine-crossover port to this version, nor whether doing so would include these improvements so that MacPorts too can offer this on Catalina. If I understand correctly, the corresponding version of wine will be 5. There are already releases candidates of wine 5 out. I will update the wine-devel port to the latest 5.0rc at some point.

I've built CrossOver19 & 19.0.1 with wine32on64 so if you want to ask anything reach out to me. You must build using there custom version of llvm/clang-8 to build wine32on64.

Wine-5.0 released today so no point dealing with any release candidates, still last I checked the mingw-w64 +universal issue still remains, its needed to build wine now along with the other additions of sdl2(controller support Wine-3.4 ish)/gnutls(needed for encryption and tls since wine-3.13)/FAudio etc

As Wine-5.0 is release CodeWeavers will be working on CrossOver-20 then we should see another wine branch with integrated wine32on64 support, so if your aim is Catalin support you might wanna hold off on that.

Updated my own Ports to Wine-5.0

[kencu (Ken)]

Gcenx has taken this simple fix and really run with it over at his wine-macports fork. He has builds and installers for all kinds of wine versions there, all built using this macports setup. The latest seems to be wine 5.9 at present, and runs on Catalina.

Although the whole setup is built with macports, it's currently only available to homebrew users as taps -- which is very sadly ironic, but more power to him anyway!

It's a shame macports users can't access any of the fruits of our labours at present...although there is a package there you can just decompress and install, built with macports, but now independant of it.

[kencu (Ken)]

Replying to Gcenx:

    # suppress a linker warning when building 32bit on Mojave that makes cmake barf
    if {${os.arch} eq "i386" && ${os.major} == 18} {
        configure.env-append "LDFLAGS=-Wl,-w"
    }

by the way, I just got tired of this warning causing errors, so I just stripped it out of ld64-latest so if you select that as your linker, you'll never see that error again.

[ryandesign (Ryan Carsten Schmidt)]

I am working on updating the wine ports. I am not necessarily incorporating all the ideas presented here.

[kencu (Ken)]

Replying to ryandesign:

I am not necessarily incorporating all the ideas presented here.

All the SDKROOT handling fixes I have moved into base, and individual port fixes committed to the tree, so there's nothing here you need to add to the wine port.

[Gcenx]

@kencu unfortunately I’m unable to provide my prebuilt wine packages for macports due to macports running it’s Linker check after installation, as mention on GitHub I’m building wine(64/32ob64) using macOS Mojave +universal and a modified MacOSX10.14.sdk that allows an i386 target.

Let’s say you attempted to install the prebuilt wine packages into 10.9 macports Linker check will cause this to fail due to “missing” system dylibs that will be expected.

The lowest version of macOS that lightly would work with prebuilt packages is 10.11, I could setup a Portfile to unpack the prebuilt wine-* packages into a sub directory and add symlinks/wrapper scripts into ${prefix}/bin

For the forceable future Winehq won’t be providing wine packages as nobody seems to want to take on the burden, since I’m building for Wineskin anyway repackaging the compiles into “Winehq” esk packages makes sense, providing brew casks just makes things simpler for end users (I refuse to provide pkg installers signed with my developers license)

[barracuda156]

Replying to kencu:

Here <​https://github.com/kencu/macports-ports/commits/universalfixes> is a branch of MP with the universal fixes to Portfiles that I've found to date. Some of these fixes may or may not make it into the MacPorts repo over time.

Does it still exist? Even though fixes may not be up to date, they could be useful as examples.

[kencu (Ken)]

nope, gonzoed.

[contextnerror]

Replying to kencu:

Condensed instructions, for anyone who wants to try this.

1. build a new installation of MacPorts from source in /opt/universal.
2. modify macports.conf like this:

   macosx_deployment_target     10.13
   macosx_sdk_version           10.13
   

3. add the MacOS10.13.sdk here:

   /Library/Developer/CommandLineTools/SDKs/MacOS10.13.sdk
   

And that is pretty much it.

If you would like to try Gcenx's very up-to-date wine port it's here: <​https://github.com/Gcenx/macports-wine/>.

I'm having trouble getting this to work. Installed MacOS10.13.sdk through Gcenx's port, edited the conf file, tried to install wine-devel and it's getting stuck at building python310. I'll try and attach logs, hopefully I do it right.

[kencu (Ken)]

looks like the system toolchain no longer provides the i386 bits this build of python expected when forcing i386 on the newer systems:

ld: warning: ignoring file /Library/Developer/CommandLineTools/usr/lib/clang/11.0.0/lib/darwin/libclang_rt.profile_osx.a, missing required architecture i386 in file

We might be able to work around this with various tricks, but to be honest at this point in time I would not bother using the MacPorts wine port any longer as it is really hopelessly out of date, and just go to here: <​​https://github.com/Gcenx/macports-wine/>, and find and download one of the prebuilt versions you find there. It is much newer. It is built with a specially-tweaked version of MacPorts.

If you really really have to build wine because it is a requirement of your company to do so or similar, there are instructions there on how to do it.

[contextnerror]

To clarify: that is exactly what I am currently trying to do. I am trying to build wine following the instructions at that link, using the modified ports, and am running into this problem.

I didn't manage to find any prebuilt versions there, but if they exist it's certainly something I'm willing to look into.

[kencu (Ken)]

they are there, you have to look around a bit. Or ask Gcenx to show them to you. You can also find them by looking at the homebrew formulae, as that is what homebrew installs, so the link to them is in their formulae.

If you are having trouble building that wine with Gcenx's modified macports repo, best to put up an issue there, as MacPorts won't know anything about it.

[kencu (Ken)]

dozens of them here:

​https://github.com/Gcenx/macOS_Wine_builds/releases/

and

​https://github.com/Gcenx/winecx/releases

I personally use the crossover builds