sys-fs/udev-210 ignores CFLAGS during compilation of some files. This problem is absent in sys-fs/udev-208. * QA Notice: Files built without respecting CFLAGS have been detected * Please include the following list of files in your report: * /usr/lib64/libgudev-1.0.so.0.2.0 * /lib64/libudev.so.1.4.0
I also use CFLAGS="-frecord-gcc-switches" to catch pkgs not respecting flags, and I'm not seeing this problem. So, you'll have to provide more information.
Please show output of: portageq envvar -v CFLAGS CXXFLAGS FFLAGS FCFLAGS
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #2) > Please show output of: > portageq envvar -v CFLAGS CXXFLAGS FFLAGS FCFLAGS $ portageq envvar -v CFLAGS CXXFLAGS FFLAGS FCFLAGS CFLAGS="-O2 -pipe -march=native -frecord-gcc-switches" CXXFLAGS="-O2 -pipe -march=native -frecord-gcc-switches" FFLAGS="-O2 -pipe" FCFLAGS="-O2 -pipe"
reproduced by fixing -frecord-gcc-switches to be in every *FLAGS like required
Post the complete build.log and point out the part where CFLAGS aren't used. I suspect it's the QA check itself which is broken since I can't find anything wrong in my build.log
Created attachment 371376 [details] build.log.xz (was too large for plain text) Here is my build.log, showing these in the end: * QA Notice: Files built without respecting CFLAGS have been detected * Please include the following list of files in your report: * /lib64/libudev.so.1.4.0 * /usr/lib64/libgudev-1.0.so.0.2.0 * /usr/lib32/libudev.so.1.4.0 However I can't see anywhere in the log the flags being ignored. Is the QA check broken? I'm using gcc-4.8.x.
Maybe it's because -210 appends '-flto' by default... I'll check that. But do we want it to auto-enable LTO when it's available?
(In reply to Michał Górny from comment #7) > But do we want it to auto-enable LTO when it's available? Is there any reason not to?
configure.ac of systemd checks if compiler supports -lfto, like it checks for eg. -Wl,--as-needed and only adds it when it's supported we all know global lto is currently a dead end so is it really wrong for packages that know they support lto, use it? maybe the portage's check should just be ignored if lto is detected?
CC toolchain@ for comment
I don't have a problem with packages using compiler features like this. Just like some packages use potentially unsafe flags because they've been designed to work with them. I think packages are free to test for and use whatever compiler features they find useful - as long as upstream addresses any bugs that they might uncover of course. There's a lot of precedent for this. LTO does wipe out the .GCC.command.line sections in those libraries. But I don't know of any way to tell if a binary was built with LTO after the fact, so I'm not sure how we would detect it.
Well, I was more wondering if -flto doesn't go in line with -On options that we expect user to control himself. AFAIU -flto also goes with some memory overhead but I don't think that'd be important in this case.
Ok, I've got an argument against -flto: I've set distcc to make compilations faster. Now that systemd implicitly adds -flto, all the workload ends up on my local machine anyway...
(In reply to Michał Górny from comment #13) > Ok, I've got an argument against -flto: I've set distcc to make compilations > faster. Now that systemd implicitly adds -flto, all the workload ends up on > my local machine anyway... Darn! If I remember correctly it was NOT okay to test $FEATURES from .ebuild, so we can't even do anything like... has distcc ${FEATURES} && sed -i -e '-flto' configure{,.ac} ...but I see many ebuilds like eg. media-tv/mythtv doing just that: media-tv/mythtv/mythtv-0.25.3_p20130101.ebuild: has distcc ${FEATURES} || myconf="${myconf} --disable-distcc" But the generated binaries without -lfto are different from those of built with -flto, so while removing -flto makes the compilation faster for distcc case, it potentially makes the application (systemd, udev, ...) slower?
I meant 'has distcc ${FEATURES} && sed -i -e 's:-flto::' configure{,.ac}' of course. Sorry. Typing error.
I don't understand, and sorry for my ignorance, why doesn't -flto work with distcc? My googling foo failed me.
LTO moves the optimization step (which is quite CPU-heavy) from compilation to linking step. Since distcc does linking locally, this means that all the heaviest effort will be done only locally. In my case, this doubles the build time for really minor benefit. A low-end computer will be hurt even more. The solution is to leave '-flto' as user choice for CFLAGS. If I want LTO, I enable LTO. I don't want some random build system to decide that I want LTO much like I don't want random build systems to override my -O because they think it'd be better for me to get more optimization when I want to debug stuff.
All good reasons. It also completely scrambles debug info. I'm actually prefer to see it stripped out but i didn't want to be the bad guy this time.
(In reply to Ryan Hill from comment #18) > All good reasons. It also completely scrambles debug info. I'm actually > prefer to see it stripped out but i didn't want to be the bad guy this time. OK. This is now disabled in both sys-apps/systemd (by mgorny) and sys-fs/udev (by me). But the package manager's QA check is still broken and should be fixed, so leaving bug open.
