Summary: | dev-util/codeblocks-20.03-r1 fails to emerge | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Klaus Kusche <klaus.kusche> |
Component: | Current packages | Assignee: | Sergey Torokhov <torokhov-s-a> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | jstein, wxwidgets |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=732818 https://bugs.gentoo.org/show_bug.cgi?id=736589 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Emerge log |
Description
Klaus Kusche
2020-07-18 08:05:36 UTC
Created attachment 649740 [details]
Emerge log
As far as I can tell, the errors causing emerge to fail here are completely different from those in 732818. To me, the two problems seem to be unrelated. I emerged gcc-10.0.1-r2, switched to it with `gcc-config`, ran `. /etc/profile`, check the `gcc -v` output and ran `ebuild /usr/portage/dev-util/codeblocks/codeblocks-20.03-r1.ebuild clean compile`. The last was successfuly done. Maybe this issue is related to CXXFLAGS and optimization level. By the way if there was codeblocks-9999 was previously merged in the system? Some emerge issue existed while compile phase of codeblocks if currently system installed is codeblocks-9999. (In reply to Sergey Torokhov from comment #3) > I emerged gcc-10.0.1-r2, switched to it with `gcc-config`, ... My current gcc version is gcc-10.1.0-r2, not gcc-10.0.1-r2, see the emerge --info above. > Maybe this issue is related to CXXFLAGS and optimization level. I've set CFLAGS and CXXFLAGS to -march and -mtune only, same error. > By the way if there was codeblocks-9999 was previously merged in the system? > Some emerge issue existed while compile phase of codeblocks if currently > system installed is codeblocks-9999. Currently installed is codeblocks 20.03. 9999 was never installed. The error happens after many wx headers are included, and it relates to wx definitions. so perhaps the wx version is significant. My current version is wxGTK-3.0.4-r302. The strange thing is that codeblocks-20.03 successfully emerged in April against the same wx version, but now fails in the same way as 20.03-r1. However, gcc changed since April, so most likely the gcc version is the problem. (In reply to Klaus Kusche from comment #4) > My current gcc version is gcc-10.1.0-r2, not gcc-10.0.1-r2, > see the emerge --info above. Yes, I merged 10.1.0-r2, it's was a typo. > The error happens after many wx headers are included, > and it relates to wx definitions. > so perhaps the wx version is significant. > My current version is wxGTK-3.0.4-r302. wxGTK-3.0.4-r302:3.0-gtk3 as I see from build.log I think I need to build libtool and wxGTK with gcc-10 too and then try to emerge codeblocks. > The strange thing is that codeblocks-20.03 successfully emerged in April > against the same wx version, but now fails in the same way as 20.03-r1. > However, gcc changed since April, so most likely the gcc version is the > problem. Does the codeblocks-20.03 (-r0) also failed? codeblocks-20.03-r1 differs only with patches for FortranProject plugin, i.e. USE='fortran'. But compile failed early then reach the build contrib plugins begin compile. (In reply to Sergey Torokhov from comment #5) > I think I need to build libtool and wxGTK with gcc-10 too and then try to > emerge codeblocks. I don't think you need to build wx. The error happens when reading and semantically checking header files. No linking and no wx libraries involved. > > The strange thing is that codeblocks-20.03 successfully emerged in April > > against the same wx version, but now fails in the same way as 20.03-r1. > > However, gcc changed since April, so most likely the gcc version is the > > problem. > > Does the codeblocks-20.03 (-r0) also failed? codeblocks-20.03-r1 differs > only with patches for FortranProject plugin, i.e. USE='fortran'. But compile > failed early then reach the build contrib plugins begin compile. 20.03 worked in April when I emerged it for the first time. Now it fails with exactly the same error as 20.03-r1. So the problem not specific to 20.03-r1 or the fortran patches. Some ideas: * Did you compare the output of the configure step in your build log and in my build log? Perhaps configure is creating different config.h, which then cause the problem? * Should we compare our libtool programs? Found and solved the problem. The problem was caused by a minor difference in our eselect wxwidgets profiles which seems to confuse the codeblocks build. Can you expand a bit more on that, if the "profiles" come from main tree? I mean, is there some eselect-wxwidgets problem hiding somewhere? eselect wxwidgets choice must not affect package builds at all if wxwidgets.eclass using ebuild is fine No, this was a local modification. See bug 736589 . (In reply to Klaus Kusche from comment #7) > Found and solved the problem. > The problem was caused by a minor difference in our eselect wxwidgets > profiles > which seems to confuse the codeblocks build. But the wxwidgets version in codeblocks ebuild is selected by WX_GTK_VER variable of wxwidgets.eclass. (In reply to Sergey Torokhov from comment #10) > But the wxwidgets version in codeblocks ebuild is selected by WX_GTK_VER > variable of wxwidgets.eclass. See bug 736589 for the follow-ups on this |