| Summary: | dev-libs/libaio: libaio.so link fails when using various compiler settings due to use of -nostdlib -nostartfiles | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Marek Paśnikowski <mail> |
| Component: | [OLD] Library | Assignee: | Göktürk Yüksek <gokturk> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | alexander, gokturk, proxy-maint, vapier |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| URL: | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764509 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Complete failed build log.
emerge --info |
||
|
Description
Marek Paśnikowski
2015-08-22 09:02:38 UTC
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 |
