Announcement

Collapse
No announcement yet.

Wine 4.12.1 Released To Fix Broken 64-Bit Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • muncrief
    replied
    Originally posted by timofonic View Post

    Where do you store your PKGBUILD files? Do you have a GitHub account? Is your own custom Wine in a public place?
    No, I don't create package build files. I've moved around to so many Linux distros over the decades that I've learned to keep everything generic. They wouldn't help much for users of Arch or their derivatives anyway because Arch is setup to only run one version of Wine at a time, so you need something like my Wine Manager to use them. Of course most people use something like PlayOnLinux anyway, which I found to be an ugly behemoth. Thus all the years of work on my own system.

    For example, when I want to create a bottle for something here's the simple command I execute:

    winemgr create -ver /opt/wine-staging-4.11 -submenu Games -b games64.wine

    This creates a bottle named "games64.wine" in the Wine Manager bottle directory with a submenu of "Games" using wine staging 4.11

    To make the bottle visible in the menu I execute the following command:

    winemgr xdg -op on -b games64.wine.

    After this the bottles programs appear under Wine->Programs->Games. So if I install Steam in the bottle it appears as Wine->Programs->Games->Steam. To remove it from the menu I execute the above command with "-op off" instead of "-op on"

    If I want to change the bottles wine version, submenu, etc. I execute the "change" command. For example, to change the above bottle to use wine 4.9 with a submenu of "Mommy" I would execute the following command:

    winemgr change -ver /opt/wine-staging-4.9 -submenu Mommy -b games64.wine

    Wine Manager also supports nested submenus. So to have the bottle appear in "Games->Something Deeper" I would execute:

    winemgr change -submenu "Games:Something Deeper" -b games64.wine

    It's all very simple, clean, and versatile. Which is the only way I will voluntarily do anything. I have a deep distaste for clumsiness and inefficiency.

    Generically compiling is fairly simple as well, though it's not yet integrated into Wine Manager so the steps must be executed by hand. For example, following is the full sequence for compiling wine staging 4.12.1. Note that I also compile a custom version of wineasio for each wine version but to keep things simpler it's not included here:

    WINE_PREF="wine-staging"
    WINE_CVER="4.12.1"
    WINE_PREF_CVER="$WINE_PREF-$WINE_CVER"
    PKG_DIR=~/working/wine/$WINE_PREF_CVER

    cd ~/working/wine
    mkdir $PKG_DIR

    cd ~/working/wine/git/wine
    git pull
    git checkout tags/wine-$WINE_CVER
    GIT_WORK_TREE=$PKG_DIR git checkout -f

    cd ~/working/wine/git/wine-staging
    git pull
    git checkout tags/v$WINE_CVER
    GIT_WORK_TREE=$PKG_DIR git checkout -f

    cd $PKG_DIR
    "$PKG_DIR"/patches/patchinstall.sh DESTDIR="$(pwd)" --all

    export CFLAGS="${CFLAGS/-fno-plt/}"
    export LDFLAGS="${LDFLAGS/,-z,now/}"
    sed 's|OpenCL/opencl.h|CL/opencl.h|g' -i configure*

    cd ~/working/wine
    mkdir $WINE_PREF_CVER-build64
    cd $WINE_PREF_CVER-build64

    "$PKG_DIR"/configure --prefix=/opt/$WINE_PREF_CVER --libdir=/opt/$WINE_PREF_CVER/lib --with-x --with-gstreamer --enable-win64
    make -j6

    cd ~/working/wine
    export PKG_CONFIG_PATH="/usr/lib32/pkgconfig"
    mkdir $WINE_PREF_CVER-build32
    cd $WINE_PREF_CVER-build32

    "$PKG_DIR"/configure --prefix=/opt/$WINE_PREF_CVER --with-x --with-gstreamer --libdir=/opt/$WINE_PREF_CVER/lib32 --with-wine64=../$WINE_PREF_CVER-build64
    make -j6

    cd ~/working/wine/$WINE_PREF_CVER-build32
    sudo make install
    cd ~/working/wine/$WINE_PREF_CVER-build64
    sudo make install
    Last edited by muncrief; 08 July 2019, 02:59 PM.

    Leave a comment:


  • timofonic
    replied
    Originally posted by muncrief View Post

    No, this was a serious bug in wineboot. I run Manjaro and compile my own custom wine so I can run different versions at the same time. Most people can't do that, but I've developed my own custom Wine Manager over many years and am in the unique position of being able to compile, run, and compare many different wine versions simultaneously.

    Lately I even did a major rewrite of my Wine Manager and virtualized the ~/.config, ~/.local/share, and ~/Desktop directories so I can turn the XDG on and off for individual bottles, complete with dynamically created submenus, allowing menu entries to be organized, combined, and turned on and off on the fly.
    Where do you store your PKGBUILD files? Do you have a GitHub account? Is your own custom Wine in a public place?

    Leave a comment:


  • muncrief
    replied
    Originally posted by tildearrow View Post

    More like caused by an APT/Debian packaging flaw. Sometimes a simple conflict can put the system in a "confused" state, and to get out you have to uninstall a lot of essential packages. This happened to me once when uninstalling the KXStudio repos. I almost wiped my system by accident.
    No, this was a serious bug in wineboot. I run Manjaro and compile my own custom wine so I can run different versions at the same time. Most people can't do that, but I've developed my own custom Wine Manager over many years and am in the unique position of being able to compile, run, and compare many different wine versions simultaneously.

    Lately I even did a major rewrite of my Wine Manager and virtualized the ~/.config, ~/.local/share, and ~/Desktop directories so I can turn the XDG on and off for individual bottles, complete with dynamically created submenus, allowing menu entries to be organized, combined, and turned on and off on the fly.

    Leave a comment:


  • muncrief
    replied
    Originally posted by tildearrow View Post
    Also, are bottles and prefixes the same thing?
    Yes they are.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by tildearrow View Post

    More like caused by an APT/Debian packaging flaw. Sometimes a simple conflict can put the system in a "confused" state, and to get out you have to uninstall a lot of essential packages. This happened to me once when uninstalling the KXStudio repos. I almost wiped my system by accident.
    Yeah I've seen this in Ubuntu/debian too. Part of the reason I migrated to a saner distro, where you can't just press y to (or let auto-updates) bork the whole system and leave only console.

    Leave a comment:


  • tildearrow
    replied
    Also, are bottles and prefixes the same thing?

    Leave a comment:


  • tildearrow
    replied
    Originally posted by muncrief View Post
    Even Ubuntu put out packages that wiped out people's installations.
    More like caused by an APT/Debian packaging flaw. Sometimes a simple conflict can put the system in a "confused" state, and to get out you have to uninstall a lot of essential packages. This happened to me once when uninstalling the KXStudio repos. I almost wiped my system by accident.

    Leave a comment:


  • muncrief
    replied
    Okay, I compiled 4.12.1 and it seems to work fine. I don't have time to do a lot of tests but I fired up a few games and my KXStudio based Reaper/Electra 2/EZdrummer music studio and everything worked. Note that I use Manjaro so I can't use the official KXStudio, instead I use AUR compiled versions of Claudia, etc. But it seems to track the official KXStudio fairly well.

    In any case the bottle destroying wineboot bug is definitely gone.

    Leave a comment:


  • dEnigma
    replied
    Good thing the update hasn't landed yet in Solus ^^
    (just left a comment on the update in the pipes so we immediately use 4.12.1 instead)

    Leave a comment:


  • muncrief
    replied
    Yes, I was quite shocked when it happened. 4.12 doesn't just crash, it completely corrupts the bottle so it can't be used any longer and has to be destroyed.

    In any case, since I custom compile my own wine, and just finished completely revamping my custom Wine Manager two days ago, I spent about 5 hours yesterday trying to figure out what the heck went wrong. I tried recompiling other versions to make sure my environment wasn't somehow responsible, and then thought there must be some new compilation option or options that I was unaware of. But nope, this was just an astounding bug that literally caused wineboot to destroy bottles the instant it was run.

    Many years ago wine bugs that destroyed bottles were fairly common, so I always used to create a test bottle when trying a new version. I should probably start doing that again. The most amazing thing though is that no one, from any distro it seems, tested the new wine. Even Ubuntu put out packages that wiped out people's installations. I can't blame Ubuntu though, since I've gone back to Manjaro and did it all to myself
    Last edited by muncrief; 07 July 2019, 05:37 PM.

    Leave a comment:

Working...
X