https://bugs.winehq.org/show_bug.cgi?id=51051
Bug ID: 51051 Summary: wine-staging 6.7 64 bit build fails in Ubuntu 21.04 Product: Wine-staging Version: 6.7 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: dimesio@earthlink.net CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: ---
Created attachment 69913 --> https://bugs.winehq.org/attachment.cgi?id=69913 Ubuntu 21.04 build failure log
All other builds succeeded, but the Ubuntu 21.04 x86_64 staging build fails in wine64-preloader. Attaching log from the OBS.
https://bugs.winehq.org/show_bug.cgi?id=51051
Ker noa blue-t@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |blue-t@web.de
https://bugs.winehq.org/show_bug.cgi?id=51051
--- Comment #1 from Zebediah Figura z.figura12@gmail.com --- What version of gcc is this?
It looks like it's choking on the declaration of e.g. cptable950; we declare it as "extern union cptable" and define it as "const struct dbcs_table". I don't know whether that's valid C.
I also have no idea why this would only fail for wine-staging, there shouldn't be any code affecting that.
https://bugs.winehq.org/show_bug.cgi?id=51051
--- Comment #2 from Rosanne DiMesio dimesio@earthlink.net --- I found the problem: beginning with 21.04, Ubuntu has started enabling LTO by default on 64 bit builds, but apparently not on 32 bit. That explains why 32 bit wine-staging built, but not why the wine-devel packages weren't affected. My experience with LTO in Fedora and openSUSE is all Wine builds fail when it is turned on.
Disabling LTO in the rules file enabled the wine-staging package to build, so my immediate problem is solved. However, I am wondering whether this is something Wine can or should disable in configure, as it does with other problematic settings. More and more distros are going that way--Fedora and openSUSE have already enabled it by default, and it looks like Debian is may be doing it for bookworm.
https://bugs.winehq.org/show_bug.cgi?id=51051
--- Comment #3 from Zebediah Figura z.figura12@gmail.com --- Sorry, but I incorrectly read the log. The LTO thing is a warning, not fatal. What is fatal is this:
[ 314s] /usr/bin/ld: /tmp/wine64-preloader.OWmPvo.ltrans0.ltrans.o: in function `_start': [ 314s] <artificial>:(.text+0x12): undefined reference to `thread_data' [ 314s] /usr/bin/ld: <artificial>:(.text+0x2a): undefined reference to `wld_start'
Unfortunately I still have no idea why wine-staging would affect this; we don't have any patches that touch the loader.
https://bugs.winehq.org/show_bug.cgi?id=51051
--- Comment #4 from Zebediah Figura z.figura12@gmail.com --- I can trigger the same error compiling preloader.c with -flto=auto in upstream Wine.
https://bugs.winehq.org/show_bug.cgi?id=51051
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |-unknown Product|Wine-staging |Wine Summary|wine-staging 6.7 64 bit |Build fails when LTO is |build fails in Ubuntu 21.04 |enabled Version|6.7 |unspecified
--- Comment #5 from Rosanne DiMesio dimesio@earthlink.net --- I think I know why the wine-devel package builds weren't affected. According to https://wiki.ubuntu.com/ToolChain/LTO, they've created an LTO exclusion list of packages that testing has shown won't build with LTO enabled. It's installed in package lto-disabled-list, which the OBS log shows as being preinstalled to the build environment (probably pulled in as a dependency of dpkg, as it's not explicitly preinstalled by the OBS). My guess is that "wine" made the exclusion list, but "wine-staging" didn't.
https://bugs.winehq.org/show_bug.cgi?id=51051
--- Comment #6 from Rosanne DiMesio dimesio@earthlink.net --- So I've changed the the summary and product to reflect the general problem with LTO. I'm not sure what to do with this bug from this point. Is it Invalid, NOTOURBUG, or something Wine should disable in configure?
https://bugs.winehq.org/show_bug.cgi?id=51051
Sveinar Søpler cybermax@dexter.no changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cybermax@dexter.no
--- Comment #7 from Sveinar Søpler cybermax@dexter.no --- @Rosanne wine amd64 arm64 wine-development amd64 arm64
is listed in /usr/share/lto-disabled-list/lto-disabled-list
Currently wine is at 5.0.3-3 and wine-development is at 5.6-2. There is no wine-staging package being built from Ubuntu, so i venture a guess and say that there is not a huge chance you will get wine-staging added to this exceptionlist upstream.
I read a discussion on the debian mailing list where they considered dropping the wine-development package altogether as there is no maintainer willing to keep the biweekly release cycle up to date. https://lists.debian.org/debian-wine/2020/09/msg00007.html https://lists.debian.org/debian-wine/2021/03/msg00010.html https://www.mail-archive.com/debian-bugs-rc@lists.debian.org/msg592858.html
There is no talk about building -staging, so i think that is pretty much out of the question atm, so even if someone steps up and starts maintaining wine (and possibly wine-development), wine-staging would probably not be added to the LTO exception list any time soon.
https://bugs.winehq.org/show_bug.cgi?id=51051
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzhang@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=51051
--- Comment #8 from Zebediah Figura z.figura12@gmail.com --- (In reply to Rosanne DiMesio from comment #6)
So I've changed the the summary and product to reflect the general problem with LTO. I'm not sure what to do with this bug from this point. Is it Invalid, NOTOURBUG, or something Wine should disable in configure?
My guess is it's a gcc bug, but I'm not sure yet. I spent a bit of time trying to make a minimal reproducer, but wasn't successful yet.
https://bugs.winehq.org/show_bug.cgi?id=51051
--- Comment #9 from Sveinar Søpler cybermax@dexter.no --- (In reply to Zebediah Figura from comment #8)
(In reply to Rosanne DiMesio from comment #6)
So I've changed the the summary and product to reflect the general problem with LTO. I'm not sure what to do with this bug from this point. Is it Invalid, NOTOURBUG, or something Wine should disable in configure?
My guess is it's a gcc bug, but I'm not sure yet. I spent a bit of time trying to make a minimal reproducer, but wasn't successful yet.
I wonder if Gentoo uses CLANG maybe to build with LTO support?
Bob Wya seems to be on top of stuff come Gentoo.. Maybe some insight to be had? :)
https://bugs.winehq.org/show_bug.cgi?id=51051
--- Comment #10 from Rafał Mużyło galtgendo@o2.pl --- Unless ebuild enforces it differently (my reading of the build says it's not the case here), portage will use whatever compiler is set as default unless the user has custom settings for the package.
So, for most people on Gentoo, unless they've set 'mingw' useflag and/or set their default compiler to clang, it's still non-PE build with gcc. LTO is an explicit user's choice, as nothing about it is in the ebuild.
https://bugs.winehq.org/show_bug.cgi?id=51051
--- Comment #11 from Zebediah Figura z.figura12@gmail.com --- Please abstain from discussion of topics not relevant to this bug report; in particular wine does not distribute gentoo packages or build scripts.
https://bugs.winehq.org/show_bug.cgi?id=51051
--- Comment #12 from Sveinar Søpler cybermax@dexter.no --- (In reply to Zebediah Figura from comment #11)
Please abstain from discussion of topics not relevant to this bug report; in particular wine does not distribute gentoo packages or build scripts.
Since the claim was that "My guess is it's a gcc bug", i thought it would be on-topic to see if other compilers would work with LTO, since afaik *buntu distro's has not been able to do that the last few years with GCC.
https://bugs.winehq.org/show_bug.cgi?id=51051
--- Comment #13 from Sveinar Søpler cybermax@dexter.no --- @Zebediah Figura I haven't spent too much fiddling with this, but i have tried to build with -flto both with gcc-10.3 and clang-10 to no avail. So afaik atm i cannot conclude that wine is able to be built with -flto.. atleast not on ubuntu.
@Rosanne DiMesio Did you try to do a standalone build on hirsute? outside of debbuild i mean?
Cos i just did a regular wine-staging (6.8) build with: configure --enable-win64 make -j4
It built without issues. Same for the 32-bit build
I basically followed the https://wiki.winehq.org/Building_Biarch_Wine_On_Ubuntu recipe, except i built 32-bit with "PKG_CONFIG_PATH="/usr/lib/i386-linux-gnu/pkgconfig" instead of using LCX. (The only package that needs "switching" is libgcrypt20-dev that is no mulilib installable).
If the debbuild "default" is the only thing that causes -flto to be used, do wine's configure even need to consider that? I mean since it is debbuild that is actually running configure with the -flto flag, and it does not happen if you run "plain" configure. I am fairly sure if i post a builderror due to me setting some optimization flags would come back to "Have you tried to compile by just running configure?". (Cos -march=native, -O3++ is various optimization flags not always working stellar on wine for various reasons)
Thoughts?
https://bugs.winehq.org/show_bug.cgi?id=51051
--- Comment #14 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to Sveinar Søpler from comment #13)
Did you try to do a standalone build on hirsute? outside of debbuild i mean?
I only build the packages on the OBS, and for myself, making that work is all I am concerned about. As I said in comment #2, I have accomplished that by disabling LTO in the rules file, so my problem is solved. The reason I asked about configure is because this has been done in the past for other problematic distro package-building defaults that were also easily handled by changes to the build scripts (e.g., fortify, fcf-protection). That's for the developers to decide.
This is definitely not an issue unique to hirsute, because LTO has to be disabled to build Fedora and openSUSE packages.
https://bugs.winehq.org/show_bug.cgi?id=51051
--- Comment #15 from Sveinar Søpler cybermax@dexter.no --- (In reply to Rosanne DiMesio from comment #14)
(In reply to Sveinar Søpler from comment #13)
Did you try to do a standalone build on hirsute? outside of debbuild i mean?
I only build the packages on the OBS, and for myself, making that work is all I am concerned about. As I said in comment #2, I have accomplished that by disabling LTO in the rules file, so my problem is solved. The reason I asked about configure is because this has been done in the past for other problematic distro package-building defaults that were also easily handled by changes to the build scripts (e.g., fortify, fcf-protection). That's for the developers to decide.
This is definitely not an issue unique to hirsute, because LTO has to be disabled to build Fedora and openSUSE packages.
But is not that the "normal way" to build distro packages? Distro-spesific customizations when building packages?
If a regular configure && make build of wine would not work - as i would venture a guess is the case for fcf-protection maybe - i would agree, but it seems to be the "package building software" that is causing this -flto flag usage (and the need for LTO exclusion list, since that would not work when building it yourself anyway).
If you actually had to specify -fno-lto to configure when building manually on 21.04 (or others), i can see that being an issue, and possibly in need of settings in configure.
https://bugs.winehq.org/show_bug.cgi?id=51051
--- Comment #16 from Artem S. Tashkinov aros@gmx.com --- Could be a duplicate of bug 41712.
https://bugs.winehq.org/show_bug.cgi?id=51051
Neko-san nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus@protonmail.ch
-
WineHQ Bugzilla