| Summary: | Compile started failing with GCC 10.0 | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Tom Callaway <tcallawa> |
| Component: | build | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | ego.cordatus, icculus |
| Version: | 2.0.10 | Keywords: | target-2.0.12 |
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Attachments: |
build log from Fedora buildsystem
SDL_assert.o preprocessor output |
||
|
Description
Tom Callaway
2020-01-23 14:36:03 UTC
Created attachment 4171 [details]
build log from Fedora buildsystem
(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. 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 Created attachment 4172 [details]
SDL_assert.o preprocessor output
(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. 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. This feels more and more like a GCC bug to me than an SDL2 bug, but I'm not an expert... (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. 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. (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. 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. Confirmed, this resolves the issue with gcc10. Thanks! |