| Summary: | media-libs/libsdl[libcaca] abi_x86_32 tries to link 64-bit libraries | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | admin |
| Component: | Current packages | Assignee: | Gentoo Games <games> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | admin, azamat.hackimov, ionen, sam |
| Priority: | Normal | Keywords: | PATCH |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=826930 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build log for x86_32
config log for x86_32 Temporary patch. |
||
|
Description
admin
2021-06-11 02:14:54 UTC
Created attachment 715203 [details]
build log for x86_32
Created attachment 715206 [details]
config log for x86_32
This describes the issues with --libdir and where EXTRA_LDFLAGS is using −L/usr/lib64 instead of −L/usr/lib
I've found a bit more info, disabling aalib the global useflag worked, this is due because instead of having the linker trying to add the symbols, it should skip it, if not it exits emerge. I just checked the config log a bit more, it seems that -laa gets replaced with //usr/lib64/libaa.so, I'm not sure that is the right behavior, I think it should stay -laa, and I'm not even sure what is causing this. Can't reproduce, tried same USE (including abi_x86_32 and aalib) but it builds fine, and own my own line I see: -lasound -lm -ldl -laudio -laa -L/usr/lib64 -lcaca -lpthread -m32 I am a bit concerned by the -L/usr/lib64 being there though, not that I see any with double // in my logs and it still built fine. By any chances, did you recently do a profile migration (from 17.0)? Incomplete migration is often the cause of issues with abi_x86_32. Also, the -L/usr/lib64 is coming from libcaca rather than libsdl Seems this is used as-is: $ caca-config --libs -L/usr/lib64 -lcaca Goes away with USE="-libcaca", not that it fails for me either way so I assume there's something more going on. There's also: $ aalib-config --libs -L/usr/lib64 -Wl,-rpath,/usr/lib -laa -lm -lncurses -ltinfo But I don't see that rpath used in my log, so perhaps it doesn't use that one. (In reply to Ionen Wolkens from comment #5) > Can't reproduce, tried same USE (including abi_x86_32 and aalib) but it > builds fine, and own my own line I see: > -lasound -lm -ldl -laudio -laa -L/usr/lib64 -lcaca -lpthread -m32 > > I am a bit concerned by the -L/usr/lib64 being there though, not that I see > any with double // in my logs and it still built fine. > > By any chances, did you recently do a profile migration (from 17.0)? > Incomplete migration is often the cause of issues with abi_x86_32. Yeah it's like it gets replaced with for some reasons. I did not do a profile migration, my system is new fresh, using default/linux/amd64/17.1/hardened. (In reply to Ionen Wolkens from comment #6) > Also, the -L/usr/lib64 is coming from libcaca rather than libsdl > > Seems this is used as-is: > $ caca-config --libs > -L/usr/lib64 -lcaca > > Goes away with USE="-libcaca", not that it fails for me either way so I > assume there's something more going on. > > There's also: > $ aalib-config --libs > -L/usr/lib64 -Wl,-rpath,/usr/lib -laa -lm -lncurses -ltinfo > > But I don't see that rpath used in my log, so perhaps it doesn't use that > one. I have tried to disable libcaca, it compiles. It just doesn't work when enabling both aalib and libcaca. The interesting thing is when I disable libcaca, the lib being linked with is //usr/lib/libaa.so. (... -laudio //usr/lib/libaa.so -lslang -lm -lX11 -lpthread ... ), when I disable aalib, it throws me first: -Wl,--as-needed -lasound -lm -ldl -laudio -L/usr/lib64 -lcaca -lpthread -m32 -Wl,-O1 -Wl,-soname -Wl,libSDL-1.2.so.0 -o build/.libs/libSDL-1.2.so.0.11.5 Where -L/usr/lib64 -lcaca is in fact caca-config --libs Then /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib64/libasound.so when searching for -lasound /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib64/libm.so when searching for -lm /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib64/libm.a when searching for -lm /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib64/libdl.so when searching for -ldl /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib64/libdl.a when searching for -ldl /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib64/libaudio.so when searching for -laudio /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib64/libaudio.a when searching for -laudio /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib64/libcaca.so when searching for -lcaca /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib64/libcaca.a when searching for -lcaca /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib64/libpthread.so when searching for -lpthread /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib64/libpthread.a when searching for -lpthread /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib64/libc.so when searching for -lc /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib64/libc.a when searching for -lc Something is definitely wrong.. It feels like that -laa is being translated into libaa.so: -L/usr/lib64 -Wl,-rpath,/usr/lib -laa -lm -lX11 -lslang Becomes somehow: //usr/lib/libaa.so -lslang -lm -lX11 -lpthread For $ caca-config --libs -L/usr/lib64 -lcaca But for $ aalib-config --libs -L/usr/lib64 -Wl,-rpath,/usr/lib -laa -lm -lX11 -lslang Maybe my RPATH is set somehow, but even if it was set, it should not be possible because of --disable-rpath. How to know if that variable being used? Also is it possible to have your build/config logs? Specially everything in: /var/tmp/portage/media-libs/libsdl-1.2.15_p20210224/ with using FEATURES="keepwork" so it doesn't get removed after being installed? Thank you. By the way, on my side, I get this issue on my both machines, laptop and desktop. So if that works for you it means that I did somehow the same error on my both machines, where I don't really know what it could be. Also, the 32 bit library, by following dependencies, is being asked from wine-staging with those useflags: app-emulation/wine-staging staging capi custom-cflags dos faudio gcrypt gecko gssapi gstreamer mingw mono netapi opencl osmesa perl pcap pipelight prelink realtime run-exes samba sdl staging themes udev unwind usb vkd3d vulkan where gst-plugins-meta is being asked aswell. etc... I'm suspecting now a problem with libtool not interpreting arguments correctly for some reasons. Created attachment 715635 [details, diff]
Temporary patch.
This is a temporary/workaround patch for the issue I have, though it is probably not the proper one, I think the issue relies on libtool replacing /usr/lib by /usr/lib64 because it sees -L/usr/lib64 inside the EXTRA_LDFLAGS, so it replaces everything else by /usr/lib64, I'll investigate more once I have time but this works for me.
*** Bug 823890 has been marked as a duplicate of this bug. *** Haven't looked closely but note the duplicate bug #823890 has a patch as well (using PKG_CHECK_MODULES). On a side-note, I am still not able to reproduce USE="libcaca abi_x86_32" builds fine for me. Not to say there isn't something going on here. Can you retry with 1.2.64 version please? Thanks |
