The library fails to compile with 32-bit ABI enabled on an AMD64 system. If I switch the flag off for this package only, it compiles correctly. Reproducible: Always Steps to Reproduce: 1. Enable ABI_X86="32" for the package. Actual Results: The compilation fails. Expected Results: Compilation succeeds. make[1]: Entering directory '/var/tmp/portage/dev-libs/libaio-0.3.110/work/libaio-0.3.110-abi_x86_32.x86/src' x86_64-pc-linux-gnu-gcc [...snip out successfully compiled files...] x86_64-pc-linux-gnu-gcc -m32 -shared -march=k8-sse3 -mmmx -m3dnow -msse -msse2 -msse3 -mcx16 -msahf -mprfchw -mfxsr --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=k8 -fstack-protector-strong -O3 -pipe -nostdlib -nostartfiles -Wall -I. -fPIC -Wl,--version-script=libaio.map -Wl,-soname=libaio.so.1 -o libaio.so.1.0.1 io_queue_init.os io_queue_release.os io_queue_wait.os io_queue_run.os io_getevents.os io_submit.os io_cancel.os io_setup.os io_destroy.os raw_syscall.os compat-0_1.os -Wl,-O1 -Wl,--as-needed io_queue_run.os: In function `io_queue_run': io_queue_run.c:(.text+0x8a): undefined reference to `__stack_chk_fail_local' io_getevents.os: In function `__io_getevents_0_4': io_getevents.c:(.text+0x51): undefined reference to `__stack_chk_fail_local' compat-0_1.os: In function `compat0_1_io_cancel': compat-0_1.c:(.text+0x4a): undefined reference to `__stack_chk_fail_local' compat-0_1.os: In function `compat0_1_io_queue_wait': compat-0_1.c:(.text+0xdd): undefined reference to `__stack_chk_fail_local' compat-0_1.os: In function `compat0_1_io_getevents': compat-0_1.c:(.text+0x17d): undefined reference to `__stack_chk_fail_local' collect2: error: ld returned 1 exit status Makefile:55: recipe for target 'libaio.so.1.0.1' failed make[1]: *** [libaio.so.1.0.1] Error 1 make[1]: Leaving directory '/var/tmp/portage/dev-libs/libaio-0.3.110/work/libaio-0.3.110-abi_x86_32.x86/src' Makefile:15: recipe for target 'all' failed make: *** [all] Error 2
Attach full build log.
Created attachment 409910 [details] Complete failed build log. As requested, I attach hereby the build log of the failed emerge.
OK, 'emerge --info' might help too.
Created attachment 409956 [details] emerge --info Should I always post the build log and emerge info when reporting a compilation fail, no matter what I think about usefulness of this information? I am still not fully aware of the good practices in this bugzilla.
(In reply to Marek Paśnikowski from comment #4) > Created attachment 409956 [details] > emerge --info > > Should I always post the build log and emerge info when reporting a > compilation fail, no matter what I think about usefulness of this > information? I am still not fully aware of the good practices in this > bugzilla. It's especially useful in compilation errors as it lets us see the compiler configuration etc.
test email to gokturk
I see that you are compiling with '-O3'. Can you try with '-O2' and see if it helps?
please try upgrading to binutils-2.25.1-r1
I apologise for forgetting to reply to the comment about test of -O2. I am extremely busy right now and made the mistake of reading the email during break at work, so it slipped my mind pretty fast. Anyway I have a day off this next sunday, so I will post the result then. But I doubt this will have any effect as I actually kept rebuilding the @world from -O0 to -O1 to -O3 during the span of last couple of months; It never had compiled successfully with with the 32 ABI. As for binutils is concerned I have the newest keyworded version installed: 2.25.1-r1 But I just realised that it may have been updated after my last test of libaio, so I will give it a go this Sunday.
I am a bit late because I got a new laptop and got busy with with making design decisions for the new system. One of those decision was to go with simple march=native instead of output of "gcc -march=native -E -v - </dev/null 2>&1 | grep cc1" that I found in the CFLAGS wiki page. Now that I took a look apparently I also had decided to remove some of the switches. I think this the trigger, from the same page: "Note that the -mno-XXX options should not be used globally as they will cause build failures for some packages." Anyway, just now I decided to change the big string back to the simple "-march=native" and got a positive result. It builds on both -O2 and -O3 level. So it seems that even though I tried to avoid it, I managed to "rice" my system just a little bit and libaio was the victim here. You have my apologies for that.
I reproduced this bug after adding '-fstack-protector-strong' to CFLAGS (it also present in attached `emerge --info`). Upgrade to binutils-2.25.1-r1 didn't help.
the libaio.so link uses -nostdlib -nostartfiles which means it does not link in any C library or gcc libs. this in turn causes problems like this. it comes up with SSP, but can probably be seen with other optimizations. not a bug in the toolchain at all. probably easiest thing would be to remove the use of those two flags. upstream does it because they want to be slim/lightweight and minimize ABI dependencies. none of that is really relevant to us.
Pull request submitted: https://github.com/gentoo/gentoo/pull/414
In the tree now: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=208727cd120aff0f241c9ee0a5f033fe6b41987f
