[Bug math/26052] New: Wine position issues with recent glibc versions and gcc 10

[Bug math/26052] New: Wine position issues with recent glibc versions and gcc 10

[lilydjwg at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26052

            Bug ID: 26052
           Summary: Wine position issues with recent glibc versions and
                    gcc 10
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: math
          Assignee: unassigned at sourceware dot org
          Reporter: lilydjwg at gmail dot com
  Target Milestone: ---

I really confused and don't know where this bug should belong, but I report
here since I can get good results by replacing with an old version of glibc.

Combinations that work:

* 2.31 tarball + gcc 9.3.0
* Arch Linux built lib32-glibc 2.31-2 (compiled with gcc 9.3.0)

Combinations that have this issue:

* 2.31 tarball + gcc 10.1.0
* Arch Linux built lib32-glibc 2.31-3 & 2.31-4
* glibc-2.31 tag + both gcc versions
* master (415d0b0b3f1649d688f18c34bcfb16ad72e337ce) + both gcc versions

OS is Arch Linux and I didn't change compile options from Arch Linux's
PKGBUILD. There is also a bz20338.patch. I also tested with various wine
versions, mainly 5.6 but it happens with 5.8, 5.9 too.

It only happens with 32-bit applications (WINEARCH=win32).

My window manager is Awesome 3.5.9 and this issue doesn't happen with latest
KDE inside KVM shipped by Arch Linux. Nor do I hear anybody else having this
problem with other window managers.

The issue is that, when I run "WINEARCH=win32 wine regedit", wine shows the
window at the top part of my desktop, with only one pixsel height. Wine also
puts its initializing window in the upper rather than centered. It even puts a
window for another application to a negative Y cooardinary.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/26052] Wine position issues with recent glibc versions and gcc 10

[lilydjwg at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26052

--- Comment #1 from lilydjwg at gmail dot com ---
Sorry I intended to read "What to put in a new report" but didn't.

It's 32-bit library on x86_64 linux.

./configure --host=i686-pc-linux-gnu --libdir=/usr/lib32
--libexecdir=/usr/lib32 --prefix=/usr --with-headers=/usr/include
--with-bugurl=https://bugs.archlinux.org/ --enable-add-ons --enable-bind-now
--enable-cet --enable-lock-elision --enable-multi-arch
--enable-stack-protector=strong --enable-stackguard-randomization
--enable-static-pie --enable-systemtap --disable-profile --disable-werror

export CC="gcc -m32 -mstackrealign"
export CXX="g++ -m32 -mstackrealign"

build kernel: 5.6.12-arch1-1; host kernel: 5.4.42 with cjktty and uksm patches.

GNU ld (GNU Binutils) 2.34.0.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/26052] Wine position issues with recent glibc versions and gcc 10

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26052

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from Carlos O'Donell <carlos at redhat dot com> ---
I appreciate the bug report, but this isn't enough information to pin-point the
issue, a distribution has a lot of moving parts. Before we can act on a report
like this we need a much narrower reproducer. To get hat narrow reproducer we
rely on distribution maintainers, like those working in the Arch Linux project
to supply those details.

I suggest you start with your distribution built binaries and interact with the
Arch Linux maintainers and change one piece of software at a time and make sure
that the result is exactly as you expect. When you find a failure you need to
narrow it down to an exact component and an exact change.

We, the glibc maintainres, need more reduced examples where behaviour change is
clearly restricted to the component in question e.g. glibc, or even gcc, and
ld, which we deal with on a daily basis and which are part of the GNU
Toolchain.

I suggest opening a bug with Arch Linux, but make sure you start by using all
of their components and make sure you can reproduce the issue only with a small
change.

I'm marking this bug RESOLVED/INVALID.

-- 
You are receiving this mail because:
You are on the CC list for the bug.