Description of problem: Package kyua fails to build from source in Fedora rawhide. Version-Release number of selected component (if applicable): 0.13-1.fc28 Steps to Reproduce: koji build --scratch f29 kyua-0.13-1.fc28.src.rpm Additional info: This package is tracked by Koschei. See: http://apps.fedoraproject.org/koschei/package/kyua --- g++ -DHAVE_CONFIG_H -I. -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_FORTIFY_SOURCE=2 -Wall -Wcast-qual -Wextra -Wpointer-arith -Wredundant-decls -Wreturn-type -Wshadow -Wsign-compare -Wswitch -Wwrite-strings -DNDEBUG -Wctor-dtor-privacy -Wno-deprecated -Wno-non-template-friend -Wno-pmf-conversions -Wnon-virtual-dtor -Woverloaded-virtual -Wreorder -Wsign-promo -Wsynth -c -o cli/cli_cmd_debug_test-cmd_debug_test.o `test -f 'cli/cmd_debug_test.cpp' || echo './'`cli/cmd_debug_test.cpp make[1]: Leaving directory '/builddir/build/BUILD/kyua-0.13' In file included from ./cli/common.ipp:30, from cli/cmd_debug_test.cpp:35: ./utils/cmdline/base_command.ipp: In member function 'int utils::cmdline::base_command< <template-parameter-1-1> >::main(utils::cmdline::ui*, const args_vector&, const Data&) [with Data = utils::config::tree]': ./utils/cmdline/base_command.ipp:94:1: error: 'int utils::cmdline::base_command< <template-parameter-1-1> >::main(utils::cmdline::ui*, const args_vector&, const Data&) [with Data = utils::config::tree]' causes a section type conflict with 'int main(int, char* const*)' base_command< Data >::main(ui* ui, const args_vector& args, const Data& data) ^~~~~~~~~~~~~~~~~~~~ In file included from /usr/include/atf-c++.hpp:33, from cli/cmd_debug_test.cpp:33: cli/cmd_debug_test.cpp:78:1: note: 'int main(int, char* const*)' was declared here ATF_INIT_TEST_CASES(tcs) ^~~~~~~~~~~~~~~~~~~
Since it was building before and only after some dependency changes it became FTBFS I have suspicion that this is change in gcc or glibc. Reassigning for help. I've never seen such error neither I'm proficient in C++ so seeking for help. Thanks in advance!
Seems that this is breaking boost too (see devel.o).
Also scidavis: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4TNC64ZF4AV74TK7Q5A7RUEDPY2OS6TI/
This seems to be breaking 'ndctl' as well: https://kojipkgs.fedoraproject.org//work/tasks/7986/28057986/build.log Adding the %undefine _annotated_build workaround lets a local mockbuild succeed.
Hi Everyone, Yeah, sorry, this was my bad. The annobin plugin was calling gcc's function_section() function in order to get the section of the current function. (Which you would have thought would be obvious and would work). But it turns out that under certain circumstances, ie destructor functions, calling function_section() can actually result in the creation of a new, incompatible function structure. *sigh* Anyway I have updated annobin to avoid calling function_section and checked that kyua now builds. (I am assuming that boost, llvm, scidavis and ndctl will also start building now too). Cheers Nick Fixed in: annobin-8.5-1.fc29
When does the change propagate through the build environment? I tried a scratch build of ndctl and it still fails: https://koji.fedoraproject.org/koji/taskinfo?taskID=28098344 root.log shows annobin at 8.7-1
(In reply to Vishal Verma from comment #6) > When does the change propagate through the build environment? > I tried a scratch build of ndctl and it still fails: > https://koji.fedoraproject.org/koji/taskinfo?taskID=28098344 > > root.log shows annobin at 8.7-1 For what it's worth, I resubmitted scidavis a few hours after Nick's post and it was built successfully.
(In reply to Vishal Verma from comment #6) > When does the change propagate through the build environment? > I tried a scratch build of ndctl and it still fails: > https://koji.fedoraproject.org/koji/taskinfo?taskID=28098344 > > root.log shows annobin at 8.7-1 It turns out that ndctl's problem is not the same as the one that was reported with this BZ. In fact the issue is that now the annobin plugin is preventing the linker's garbage collection feature from removing unused pieces of code. In theory this should only mean a slight increase in program size, but for the ndctl package it is a deal breaker, since it relies upon linker garbage collection working. (It really shouldn't. Either the unneeded code should never have been compiled or else the source file providing the missing functions - test/libndctl.c - should have been included in the link). Anyway, since I assume that you do not want to update ndctl, and since this problem could potentially arise with other packages, I have patched annobin to stop it from interfering with linker garbage collection. This will have consequences for build flag checking since there is now a sceanario where code can be compiled but not annotated, but I have a (long term) plan to fix this. Please try: annobin-8.8-1.fc29
Sorry - there appears to be a problem building annobin-8.8-1. Please stand by...
Right, annobin-8.9-1.fc29 is now available. Vishal - please can you try it out ?
(In reply to Nick Clifton from comment #10) > Right, annobin-8.9-1.fc29 is now available. Vishal - please can you try it > out ? Yes, I tried a scratch build, and that now succeeds. I got a notification from Koschei that the rawhide builds are back to normal. Thank you Nick.
This has reappeared with annobin-8.12-1.fc29: https://koji.fedoraproject.org/koji/taskinfo?taskID=28427014 Was it fixed again in 8.13-1?
I have opened https://bugzilla.redhat.com/show_bug.cgi?id=1603071 to track newly appeared issue.
Hi Guys, My fault again - I managed to reintroduce the bug in 8.11. I have however found a different fix, which I hope will be more permanent this time... Please try annobin-8.14.fc29 Cheers Nick
(In reply to Nick Clifton from comment #14) > Hi Guys, > > My fault again - I managed to reintroduce the bug in 8.11. > I have however found a different fix, which I hope will be more > permanent this time... > > Please try annobin-8.14.fc29 > > Cheers > Nick This is still broken for me when trying to compile Node.js: https://koji.fedoraproject.org/koji/taskinfo?taskID=28444049
ndctl breaks again in the same way: https://koji.fedoraproject.org/koji/taskinfo?taskID=28461257 This is with annobin-8.14 based on root.log from above. I'm guessing the linker garbage collection fixes got lost too?
And now gromacs: https://koji.fedoraproject.org/koji/taskinfo?taskID=28445002 This is with annobin-8.14-1.fc29 and only on x86_64 and i686. Same bug?
In my case, a scratch build of scidavis with annobin-8.14-1.fc29 ran just fine: https://koji.fedoraproject.org/koji/taskinfo?taskID=28463362
(In reply to Stephen Gallagher from comment #15) > This is still broken for me when trying to compile Node.js: > https://koji.fedoraproject.org/koji/taskinfo?taskID=28444049 Hi Stephen, This is very strange. When I tried to repeat the failure using almost the same environment, it worked. I was using a mock fedora rawhide x86_64 environment which should be identical to the build environment used by fedpkg. The "almost" above refers to the fact that I could not satisfy one of the dependencies of the nodejs package. It needed libuv-devel-1.22.0 and rawhide only has libuv-devel-1.21.0. I edited the nodejs.spec file by hand to reduce the dependency to 1.21.1 and then I was able to build the nodejs package. Could this be the cause of the problem you had ? It seems very unlikely to me. So at the moment I am baffled. There is a new annobin to try (8.15) but I doubt if that will solve this particular problem. (It should solve Vishal's ndctl build problem). The thing that really confuses me is that 8.14 should have worked. There was only one place in the annobin where it examined the gcc section structure, and I fixed that one to set the correct flags. Cheers Nick
(In reply to Vishal Verma from comment #16) > ndctl breaks again in the same way: > https://koji.fedoraproject.org/koji/taskinfo?taskID=28461257 > > This is with annobin-8.14 based on root.log from above. > I'm guessing the linker garbage collection fixes got lost too? No the fixes are in. ndctl is triggering a different bug in the annobin plugin, which is then causing the garbage collection to appear to fail. (It actually works, but just does not garbage collect enough. Which in turn appears to be a problem with the assembler creating spurious duplicate sections). Anyway I have tweaked the plugin so that these duplicate sections should no longer appear. So please try: annobin-8.15. Cheers Nick
(In reply to Dominik 'Rathann' Mierzejewski from comment #17) > And now gromacs: https://koji.fedoraproject.org/koji/taskinfo?taskID=28445002 > > This is with annobin-8.14-1.fc29 and only on x86_64 and i686. Same bug? Investigating now...
(In reply to Dominik 'Rathann' Mierzejewski from comment #17) > And now gromacs: https://koji.fedoraproject.org/koji/taskinfo?taskID=28445002 Hi Dominik, *sigh* Well I think have found the cause of the problem. GCC is creating the special sections but not telling the annobin plugin about them. Then when annobin creates sections of its own it uses the same name, but different flags, and this creates a conflict. I have created a new version of the plugin which I hope will work around this problem. Please give annobin-8.16 a try. Note - when I ran an rpmbuild of gromacs in a rawhide mock environment with the new annobin installed the build worked, but the testing that followed failed with: The following tests FAILED: 2 - TestUtilsMpiUnitTests (Failed) 13 - MdrunUtilityMpiUnitTests (Failed) Errors while running CTest Is this expected ? The log also showed: mpiexec has detected an attempt to run as root. Running at root is *strongly* discouraged as any mistake (e.g., in defining TMPDIR) or bug can result in catastrophic damage to the OS file system, leaving your system in an unusable state. So I am guessing that this is the cause. Cheers Nick
(In reply to Stephen Gallagher from comment #15) > This is still broken for me when trying to compile Node.js: Hi Stephen, I think that the new annobin-8.16-1 rpm should also fix the Node.js building problem. Would you mind giving it a go please ? Cheers Nick
(In reply to Nick Clifton from comment #19) > (In reply to Stephen Gallagher from comment #15) > > > This is still broken for me when trying to compile Node.js: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=28444049 > > Hi Stephen, > > This is very strange. When I tried to repeat the failure using almost > the same environment, it worked. I was using a mock fedora rawhide > x86_64 environment which should be identical to the build environment > used by fedpkg. The "almost" above refers to the fact that I could > not satisfy one of the dependencies of the nodejs package. It needed > libuv-devel-1.22.0 and rawhide only has libuv-devel-1.21.0. I edited > the nodejs.spec file by hand to reduce the dependency to 1.21.1 and > then I was able to build the nodejs package. Could this be the cause > of the problem you had ? It seems very unlikely to me. > > So at the moment I am baffled. There is a new annobin to try (8.15) > but I doubt if that will solve this particular problem. (It should > solve Vishal's ndctl build problem). The thing that really confuses > me is that 8.14 should have worked. There was only one place in the > annobin where it examined the gcc section structure, and I fixed that > one to set the correct flags. > > Cheers > Nick I worked around the problem by setting `%undefine _annotated_build` in the spec, after which the build succeeded just fine. So I'm pretty sure that the issue is in annobin. I'm running another scratch build right now with annobin-8.16-1.fc29 in the buildroot. I'll let you know if it works.
*** Bug 1605163 has been marked as a duplicate of this bug. ***
(In reply to Nick Clifton from comment #23) > (In reply to Stephen Gallagher from comment #15) > > > This is still broken for me when trying to compile Node.js: > > Hi Stephen, > > I think that the new annobin-8.16-1 rpm should also fix the Node.js > building problem. Would you mind giving it a go please ? Yes, that fixed the issue. Thanks!
(In reply to Nick Clifton from comment #20) > > No the fixes are in. ndctl is triggering a different bug in the annobin > plugin, which is then causing the garbage collection to appear to fail. > (It actually works, but just does not garbage collect enough. Which in > turn appears to be a problem with the assembler creating spurious duplicate > sections). Anyway I have tweaked the plugin so that these duplicate > sections should no longer appear. So please try: annobin-8.15. > > Cheers > Nick ndctl build is fixed with 8.16. Thanks Nick!