testing environment: - AMD64 - gcc-4.7.2-r1 - sys-cluster/ceph-0.59 - dev-libs/crypto++-5.6.2 If ceph compilation fails with the following symptom or output, try to disable LTO on dev-libs/crypto++, i.e. CFLAGS="-fno-lto" /bin/sh ../libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -Wall -D__CEPH__ -D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_THREAD_SAFE -D__STDC_FORMAT_MACROS -D_GNU_SOURCE -rdynamic -Wtype-limits -Wignored-qualifiers -Winit-self -Wpointer-arith -fno-strict-aliasing -DCEPH_LIBDIR=\"/usr/lib64\" -Wnon-virtual-dtor -Wno-invalid-offsetof -Wstrict-null-sentinel -march=native -pipe -O2 -mfpmath=sse -Wl,--as-needed -march=native -pipe -O2 -mfpmath=sse -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -o ceph-mon ceph_mon-ceph_mon.o ceph_mon-TextTable.o ceph_mon-disabled_heap_profiler.o libmon.a libos.a -laio -lleveldb -lsnappy libglobal.la -lpthread -lm -lcrypto++ -luuid -lrt -lboost_thread-mt -lboost_system-mt -lleveldb -lsnappy libtool: link: x86_64-pc-linux-gnu-g++ -Wall -D__CEPH__ -D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_THREAD_SAFE -D__STDC_FORMAT_MACROS -D_GNU_SOURCE -rdynamic -Wtype-limits -Wignored-qualifiers -Winit-self -Wpointer-arith -fno-strict-aliasing -DCEPH_LIBDIR=\"/usr/lib64\" -Wnon-virtual-dtor -Wno-invalid-offsetof -Wstrict-null-sentinel -march=native -pipe -O2 -mfpmath=sse -march=native -pipe -O2 -mfpmath=sse -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -o ceph-mon ceph_mon-ceph_mon.o ceph_mon-TextTable.o ceph_mon-disabled_heap_profiler.o -Wl,--as-needed libmon.a libos.a -laio ./.libs/libglobal.a -lpthread -lm -lcrypto++ -luuid -lrt -lboost_thread-mt -lboost_system-mt -lleveldb -lsnappy ./.libs/libglobal.a(libcommon_la-Crypto.o):Crypto.cc:function CryptoAES::decrypt(ceph::buffer::ptr const&, ceph::buffer::list const&, ceph::buffer::list&, std::string&) const: error: undefined reference to 'CryptoPP::CBC_Decryption::ResizeBuffers()' collect2: error: ld returned 1 exit status make[3]: *** [ceph-mon] Error 1 make[3]: Leaving directory `/var/tmp/paludis/sys-cluster-ceph-0.59/work/ceph-0.59/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/paludis/sys-cluster-ceph-0.59/work/ceph-0.59/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/paludis/sys-cluster-ceph-0.59/work/ceph-0.59/src' make: *** [all-recursive] Error 1 !!! ERROR in sys-cluster/ceph-0.59::gentoo: !!! In /usr/libexec/paludis/utils/emake at line 30 !!! emake returned error 2 !!! Call stack: !!! * paludis_die_or_error_func (/usr/libexec/paludis/die_functions.bash:67) !!! * main (/usr/libexec/paludis/utils/emake:30) dev-libs/crypto++ alone compiles fine using lto, but some dependent packages will suffer from undefined references in the resulting libcrypto{pp,++}.so libraries. This might be fixable upstream using gcc attributes for a later version of crypto++ .. Greetings Reproducible: Always
> * LTO support is still experimental and unstable > * Any bugs resulting from the use of LTO will not be fixed.
(In reply to comment #1) > > * LTO support is still experimental and unstable > > * Any bugs resulting from the use of LTO will not be fixed. I know this, nevertheless people start to use it. I do not expect the bug being fixed. It's just here to help others running into the same issue. Why not have a tracker bug / goal for this? In it, first comment should hint that depending bugs are not currently fixed. This way you do not need to repeat yourself for each lto-related bug reported, but users can still track their issues. Greetings
(In reply to comment #2) > (In reply to comment #1) > > > * LTO support is still experimental and unstable > > > * Any bugs resulting from the use of LTO will not be fixed. > > I know this, nevertheless people start to use it. I do not expect the bug > being fixed. It's just here to help others running into the same issue. Keeping bugs open would give the impression that bugs would get fixed by us, which is not the case; I don't see how keeping unsolved bugs around will help anyone. > Why not have a tracker bug / goal for this? In it, first comment should > hint that depending bugs are not currently fixed. They can be tracked and resolved upstream; we don't track experimental things we don't support, I don't see why we would want to keep bugs around we can't fix ourselves. > This way you do not need to repeat yourself for each lto-related bug > reported, but users can still track their issues. The effort required makes no difference; whether I repeat myself or block it, the amount of effort stays the same with the use of canned bin messages. > Greetings Greetings, a fellow user running -fLTO -fuse-linker-plugin on gcc 4.8.0.
(In reply to comment #3) > I don't see how keeping unsolved bugs around will help anyone. If you've ever searched this bug tracker for a problem you've had, you /know/ how /any/ bug report helps. > They can be tracked and resolved upstream; we don't track experimental > things we don't support, I don't see why we would want to keep bugs around > we can't fix ourselves. There is tons of stuff in this bug tracker which gentoo can't fix (currently) but is here for the sole purpose of being tracked. FIXABLE is not a needed property of a bug to take part in this bug tracker, it's a wish. As for upstream: You need the bug here to sort out IF it is an distro or upstream issue at all. If the latter is the case, then of course, stalling the bug and waiting for a fix from upstream makes sense, but this is not a reason to not have it here or to not /track/ it here. This bug tracker is also a "knowledge base". As such it may hold very well information about experimental stuff. Gentoo, in it's core, lives on "experimental" stuff. Compiling stuff from source is experimental, the tons of patches, sed commands stuffed into portage indicate this. You'd go for a binary distro if you want to evade this. That being said, I'm fine with you closing these bugs - maybe "WONT FIX" would be better than "RESOLVED" however. Still, I do not see why we should not ease each others lives by having a tracker for currently not-fixed-by-gentoo-devs, lto related stuff. Users may use the lto-tracker just for reference, just to see, what experimental features build and work and which are a reported no-go as of now. It does make a difference to have a filed bug of an issue to identify a problem on or not. E.g.: tons of bugs having "maintainer-wanted" help people with unsupported software, printer drivers or whatever, despite the fact that their attached and proposed ebuilds are not in tree. As such they are unsupported and, considering your scheme, experimental - still they deserve being tracked, do they not? > The effort required makes no difference; whether I repeat myself or block > it, the amount of effort stays the same with the use of canned bin messages. > > Greetings, a fellow user running -fLTO -fuse-linker-plugin on gcc 4.8.0. "look at tracker bug #xx, we do not help with lto currently" serves a better sink for an issue than a provocative "we do not support LTO" when pratically every developer experiments with it, imho. Greetings
(In reply to comment #4) > If you've ever searched this bug tracker for a problem you've had, you > /know/ how /any/ bug report helps. Please give me an /example/ of how /an unsolved LTO/ bug report can help anyone. > There is tons of stuff in this bug tracker which gentoo can't fix > (currently) but is here for the sole purpose of being tracked. FIXABLE is > not a needed property of a bug to take part in this bug tracker, it's a wish. A wish which can't be satisfied, since toolchain doesn't label it supported. > As for upstream: You need the bug here to sort out IF it is an distro or > upstream issue at all. If the latter is the case, then of course, stalling > the bug and waiting for a fix from upstream makes sense, but this is not a > reason to not have it here or to not /track/ it here. In general, Gentoo attempts to not defer from upstream like other distributions do; it is unlikely that mistakes in the LTO code or linker plugin are introduced by Gentoo, especially since we don't support it yet in the first place. > This bug tracker is also a "knowledge base". As such it may hold very well > information about experimental stuff. Gentoo, in it's core, lives on > "experimental" stuff. Compiling stuff from source is experimental, the tons > of patches, sed commands stuffed into portage indicate this. You'd go for a > binary distro if you want to evade this. As indicated above, binary distributions use way more patches and sed commands than we will ever do. Their binary nature hides this from you. We live on experimental stuff up to the limit that we can support it, beyond that you'll have to resort to upstream. > That being said, I'm fine with you closing these bugs - maybe "WONT FIX" > would be better than "RESOLVED" however. WONTFIX is listed under RESOLVED, I'll however take CANTFIX as this can't be fixed at present but may be fixed in the future; at which point we may or may not run through the newest bugs listed in the search "ALL #flto" (runs long, returns 106 bugs at the moment). > Still, I do not see why we should not ease each others lives by having a > tracker for currently not-fixed-by-gentoo-devs, lto related stuff. A tracker will likely come in the future at the point where support will be considered, currently it only would result in unnecessary work and mails which have no benefit other than to keep people from doing more important work. > Users may use the lto-tracker just for reference, just to see, what > experimental features build and work and which are a reported no-go as of > now. Trackers don't work if they track bugs that do not get fixed. > It does make a difference to have a filed bug of an issue to identify a > problem on or not. Upstream is happy to accept them, as far as I know. > E.g.: tons of bugs having "maintainer-wanted" help people with unsupported > software, printer drivers or whatever, despite the fact that their attached > and proposed ebuilds are not in tree. As such they are unsupported and, > considering your scheme, experimental - still they deserve being tracked, do > they not? Adding new packages to the tree is supported under certain conditions. > "look at tracker bug #xx, we do not help with lto currently" serves a better > sink for an issue than a provocative "we do not support LTO" when pratically > every developer experiments with it, imho. If everyone supports it, it surprises me that we barely get bugs about it; just a few ricers that run it, but not every developer...
Have a look at the clang tracker bug, same story. Unsupported yet, but a goal..
(In reply to comment #6) > Have a look at the clang tracker bug, same story. Unsupported yet, but a goal... In this case developers work towards support; different story, different goal.
(In reply to comment #7) > (In reply to comment #6) > > Have a look at the clang tracker bug, same story. Unsupported yet, but a goal... > > In this case developers work towards support; different story, different > goal. Good thing devs don't have to start from scratch one day they decide to start working on LTO ;-) I also doubt you may speak for all devs of gentoo, nevertheless it's the gentoo bug tracker, a place to hold bug reports. Besides, "can't fix" does not mean "won't list". I'll put the tracker bug up myself, if I find time.' It'd be also nice to separate clang and clang+lto issues. gcc is not the only compiler supporting lto.
(In reply to comment #8) > Good thing devs don't have to start from scratch one day they decide to > start working on LTO ;-) Yeah, and a few users have a list of packages that are broken in their /etc/portage/package.env so a tracker would be easily filled. > I also doubt you may speak for all devs of gentoo, nevertheless it's the > gentoo bug tracker, a place to hold bug reports. Besides, "can't fix" does > not mean "won't list". I'll put the tracker bug up myself, if I find time.' Actually, I do, now the message has been changed in 4.8.0 and reads: ewarn "LTO support is still experimental and unstable. Any bug reports" ewarn "about LTO that do not include an upstream patch will be closed as" ewarn "invalid." which you can see in /usr/portage/sys-devel/gcc/gcc-4.8.0.ebuild. Your tracker is unlikely to work because the LTO bugs you would track do not reflect the state you would want as shown in the warning above; and those that stay open, would already be tracked by the toolchain team under the form of a refined search query (something like #fLTO url:http but better, perhaps based on a keyword), as you can see there currently are no such bugs so you would track nothing.
(In reply to comment #9) > Actually, I do, now the message has been changed in 4.8.0 and reads: > > ewarn "LTO support is still experimental and unstable. Any bug reports" > ewarn "about LTO that do not include an upstream patch will be closed as" > ewarn "invalid." Is there a chance to have the tracker bug id you're going to open in that ebuild? Sth like "please report bugs resulting from the usage of -fLTO to $id" maybe would be nice.. "ALL comment:flto" prints a 109 "comment:flto" 25 open bugs "lto" will give 28 Some of them might be a candidate for it.
(In reply to comment #10) > Is there a chance to have the tracker bug id you're going to open in that > ebuild? Sth like "please report bugs resulting from the usage of -fLTO to > $id" maybe would be nice.. You would need to contact toolchain about that. > "ALL comment:flto" prints a 109 Yet, the majority would show up as closed in the tracker; when you work towards fixes that wouldn't work out well as you would have to track it by some other means, which makes the tracker itself do nothing. > "comment:flto" 25 open bugs bug #351532 - No, LTO is not listed in emerge info and build log. bug #371615 - No, other user responds with that yet reporter doesn't use LTO. bug #422121 - No, llvm and therefore not gcc. bug #442272 - No, Python modules don't go through gcc, so not LTO related. bug #448124 - No, dump of gcc specifications, doesn't use LTO. bug #455430 - No, not a build failure related to compiling or linking. bug #424904 - No, bug in pax-utils and not due to compiling or linking. bug #459900 - Maybe, though was tried with LTO and has shown the same result. bug #459034 - Yes, LTO, closed as invalid. bug #458706 - No, mentioned by a third party developer. bug #458706 - Maybe, hardened bug which is being evaluated by the maintainers. bug #374403 - No, bug seems unrelated to LTO, attributable to include problem. bug #403775 - No, mentioned by third party user. bug #461586 - Maybe, but recompiled without LTO and still sees it happen. bug #281543 - No, ebuild that appends LTO and works with it. bug #462796 - Yes, early preparation towards LTO. bug #459592 - No, typical eautoreconf problem. bug #463500 - No, has been tried without LTO. bug #461694 - No, mentions that LTO flags are disabled in advance. bug #352230 - No, automatically enabled LTO like bug #281543. bug #459752 - No, same as previous, automatically enabled, different arch. bug #464734 - No, you state that it is not. bug #437350 - No, bug regarding init script. bug #460196 - No, mention although the main subject is about -O3 in a guide. bug #459306 - No, llvm and therefore not gcc. bug #462608 - No, clang and therefore not gcc. > "lto" will give 28 CTRL+F lto and look for positives: bug #422121 - No, see above list... bug #418377 - No, emerge info doesn't list it and this is icecream / gcc. bug #461634 - Yes, yours, have you filed it upstream? Please do. bug #454426 - No, same as #418377. bug #352230 - No, see above list... bug #459752 - No, see above list... bug #464882 - No, clang and therefore not gcc. bug #462608 - No, see above list... bug #464758 - No, clang and therefore not gcc. > Some of them might be a candidate for it. Barely any candidates, most have been closed in the past and most not by me.
Alright, thanks for the details.
