Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compile started failing with GCC 10.0 #3520

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 0 comments
Closed

Compile started failing with GCC 10.0 #3520

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: 2.0.10
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2020-01-23 14:36:03 +0000, Tom Callaway wrote:

As first reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1794183

SDL 2.0.10 no longer compiles in Fedora Rawhide with the update to gcc 10.

The issue seems to be in the handling of wayland symbols.

Specifically, lots and lots of error messages like this at link time:

/usr/bin/ld: build/.libs/SDL_evdev_kbd.o:(.bss+0x10): multiple definition of WAYLAND_wl_proxy_get_user_data'; build/.libs/SDL.o:(.bss+0x0): first defined here /usr/bin/ld: build/.libs/SDL_evdev_kbd.o:(.bss+0x18): multiple definition of WAYLAND_wl_proxy_set_user_data'; build/.libs/SDL.o:(.bss+0x8): first defined here
/usr/bin/ld: build/.libs/SDL_evdev_kbd.o:(.bss+0x20): multiple definition of WAYLAND_wl_proxy_add_listener'; build/.libs/SDL.o:(.bss+0x10): first defined here /usr/bin/ld: build/.libs/SDL_evdev_kbd.o:(.bss+0x28): multiple definition of WAYLAND_wl_proxy_destroy'; build/.libs/SDL.o:(.bss+0x18): first defined here
/usr/bin/ld: build/.libs/SDL_evdev_kbd.o:(.bss+0x30): multiple definition of WAYLAND_wl_proxy_marshal_constructor_versioned'; build/.libs/SDL.o:(.bss+0x20): first defined here /usr/bin/ld: build/.libs/SDL_evdev_kbd.o:(.bss+0x38): multiple definition of WAYLAND_wl_proxy_marshal_constructor'; build/.libs/SDL.o:(.bss+0x28): first defined here
/usr/bin/ld: build/.libs/SDL_evdev_kbd.o:(.bss+0x40): multiple definition of WAYLAND_wl_proxy_create'; build/.libs/SDL.o:(.bss+0x30): first defined here /usr/bin/ld: build/.libs/SDL_evdev_kbd.o:(.bss+0x48): multiple definition of WAYLAND_wl_proxy_marshal'; build/.libs/SDL.o:(.bss+0x38): first defined here

I did try switching the wayland-scanner code calls to wayland-scanner private-code, but that does not change the result.

On 2020-01-23 14:37:02 +0000, Tom Callaway wrote:

Created attachment 4171
build log from Fedora buildsystem

On 2020-01-23 14:44:08 +0000, Ryan C. Gordon wrote:

(In reply to Tom Callaway from comment # 1)

Created attachment 4171 [details]
build log from Fedora buildsystem

Would it be difficult to grab the preprocessor output from one of those compiles? I'll dig into this if you can't easily grab that, but it would be useful to see what GCC is seeing here.

("make V=1" will show you the actual command lines we are otherwise hiding.)

--ryan.

On 2020-01-23 15:27:56 +0000, Tom Callaway wrote:

Sure. Here's what I did:

[spot@dhcp1-155 SDL2-2.0.10]$ gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -DUSING_GENERATED_CONFIG_H -Iinclude -I/home/spot/git/SDL2/SDL2-2.0.10/include -idirafter /home/spot/git/SDL2/SDL2-2.0.10/src/video/khronos -mmmx -m3dnow -msse -Wall -fno-strict-aliasing -fvisibility=hidden -Wdeclaration-after-statement -Werror=declaration-after-statement -D_REENTRANT -I/usr/include/libdrm -Igen -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/ibus-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -I/usr/include/libmount -I/usr/include/blkid -D_REENTRANT -DHAVE_LINUX_VERSION_H -c /home/spot/git/SDL2/SDL2-2.0.10/src/SDL_assert.c -fPIC -DPIC -E &> SDL_assert.o.pp

On 2020-01-23 15:28:27 +0000, Tom Callaway wrote:

Created attachment 4172
SDL_assert.o preprocessor output

On 2020-01-23 17:19:37 +0000, Ryan C. Gordon wrote:

(In reply to Tom Callaway from comment # 4)

Created attachment 4172 [details]
SDL_assert.o preprocessor output

Ok, so this doesn't appear to be a GCC issue.

On my machine, with Wayland 1.17.0, /usr/include/wayland-client-core.h has this:

void *wl_proxy_get_user_data(struct wl_proxy *proxy);

The preprocessor output has this (with preprocessor gunk removed)...

void *(*WAYLAND_wl_proxy_get_user_data)(struct wl_proxy *proxy);

So this changed from an external function to a non-static symbol that is part of any compilation unit that includes this header. :/

I assume Rawhide has a bleeding edge equivalent of that header, which is the likely culprit.

Alternately, maybe SDL is including a header that nothing was ever intended to include and we should fix that if so, but I think the next stop is to ping the Wayland team. I'll close this bug for now, but if they say it's SDL's fault, please reopen!

--ryan.

On 2020-01-23 17:30:32 +0000, Tom Callaway wrote:

I thought that might be the case too, but our wayland headers are at stock 1.17.0 and have been for some time.

We successfully built SDL2 against those headers without this issue, it only cropped up with gcc 10.

I confirmed that the wayland header define in rawhide matches your system.

On 2020-01-23 17:31:28 +0000, Tom Callaway wrote:

This feels more and more like a GCC bug to me than an SDL2 bug, but I'm not an expert...

On 2020-01-23 17:36:26 +0000, Ryan C. Gordon wrote:

(In reply to Tom Callaway from comment # 7)

This feels more and more like a GCC bug to me than an SDL2 bug, but I'm not
an expert...

Wait, this is a possible culprit in
src/video/wayland/SDL_waylanddyn.h ...

#define wl_proxy_get_user_data (*WAYLAND_wl_proxy_get_user_data)

So this might be some unfortunate header tapdance on our end, as we appear to have redefined the symbol to something that is syntactically correct but totally different in that system header.

I'll dig in on my end.

--ryan.

On 2020-01-23 18:33:31 +0000, Tom Callaway wrote:

I found this in the GCC10 notes:

https://gcc.gnu.org/gcc-10/porting_to.html#common

It might be causing what we're seeing here.

On 2020-01-23 19:01:44 +0000, Ryan C. Gordon wrote:

(In reply to Tom Callaway from comment # 9)

I found this in the GCC10 notes:

https://gcc.gnu.org/gcc-10/porting_to.html#common

It might be causing what we're seeing here.

Okay, that's surprising to me that GCC 10's new behavior wasn't always the default, but it pretty much confirms that this is an SDL bug and we just never noticed it before.

I'll fix this in SDL.

Thanks for taking the time to research this!

--ryan.

On 2020-02-11 04:50:13 +0000, Ryan C. Gordon wrote:

This is fixed now in https://hg.libsdl.org/SDL/rev/02c8da593c73 ...I haven't tried GCC 10, but I built with -fno-common in the CFLAGS, and it fixed this same list of errors.

--ryan.

On 2020-02-11 13:42:48 +0000, Tom Callaway wrote:

Confirmed, this resolves the issue with gcc10. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant