I can't get any of the GitHub CLI ebuilds to build successfully. I can manually build them with `make` but it seems `emake` cannot. Reproducible: Always
Created attachment 781307 [details] build.log
emake vs make doesn't make much sense if you mean you change it in the ebuild. emake doesn't do much special. This is likely to be one of your interesting *FLAGS. Please try to figure out which
Hey Sam. Thanks for responding. You know, I just was gonna respond that I already went over the usual suspects (the LTO flags)...but because of your message, I decided to take another look and get more aggressive with the flag filtering. So it's looking like it's one of the debugging flags, which would mark the first time that a debugging flag causes something to fail (to me). I'll get to the bottom of it, and send a PR.
(In reply to Randall from comment #3) > Hey Sam. Thanks for responding. > > You know, I just was gonna respond that I already went over the usual > suspects (the LTO flags)...but because of your message, I decided to take > another look and get more aggressive with the flag filtering. > > > So it's looking like it's one of the debugging flags, which would mark the > first time that a debugging flag causes something to fail (to me). > > I'll get to the bottom of it, and send a PR. This is one of those weird properties of Go where sometimes flags (I think mainly/only LDFLAGS) get respected and they aren't rejected but instead are interpreted in unexpected ways. Ofc, there's an unset LDFLAGS here, which complicates things. No ideas here yet though, other than it likely being flag related. Easy to test: CFLAGS="-O2 -march=native" CXXFLAGS="-O2 -march=native" LDFLAGS="-Wl,--as-needed" emerge -v1 ... and see if it breaks? Also, remember to include emerge --info!
Noted. Yeah, this one kinda through me a bit. Turns out it's `-ggdb3` that causes it to fail. Seems strange though to me still. Shall I submit a PR or (in your opinion) should this be reported upstream? Also, there are certain LDFLAGS that are filtered by the makefile. I don't know if we need to unset them all, the way we are now. I can probably adapt the ebuild so the same LDFLAGS are filtered if you think that's worth my time. LTO also needs to be added to the filtered flags. > Also, remember to include emerge --info! My bad, I will remember to include it from now on.
(In reply to Randall from comment #5) > Noted. Yeah, this one kinda through me a bit. > > Turns out it's `-ggdb3` that causes it to fail. > > Seems strange though to me still. > > Shall I submit a PR or (in your opinion) should this be reported upstream? > > Also, there are certain LDFLAGS that are filtered by the makefile. I don't > know if we need to unset them all, the way we are now. I can probably adapt > the ebuild so the same LDFLAGS are filtered if you think that's worth my > time. > > LTO also needs to be added to the filtered flags. > I don't yet get how given it unsets LDFLAGS. Surely it's something else? Or what? The unset isn't working?
> I don't yet get how given it unsets LDFLAGS. Surely it's something else? Or what? The unset isn't working? I don't believe the unset works, cause the logs seem to indicate that it's trying to build everything with my LDFLAGS intact. I've attached the successful build log without `-ggdb3`.
Created attachment 781310 [details] build.log (without ggdb3)
(In reply to Randall from comment #7) > > I don't yet get how given it unsets LDFLAGS. Surely it's something else? Or what? The unset isn't working? > > I don't believe the unset works, cause the logs seem to indicate that it's > trying to build everything with my LDFLAGS intact. I've attached the > successful build log without `-ggdb3`. You've tried putting ggdb3 in nothing but LDFLAGS, and then it fails? Besides, your LDFLAGS are included in all your other variables anyway, and then they get used: [snip] yaml.v3\tv3.0.0-20210107192922-496545a6307b\th1:h8qDotaEPuJATrMmW04NCwg7v22aHH28wwpauUhK9Oo=\nbuild\t-compiler=gc\nbuild\t-ldflags=\"-X github.com/cli/cli/v2/internal/build.Date=2022-05-28 -X github.com/cli/cli/v2/internal/build.Version=v2.11.0 \"\nbuild\tCGO_ENABLED=1\nbuild\tCGO_CFLAGS=\"-march=native -O3 -pipe -D_FORTIFY_SOURCE=2 -falign-functions=32 -Wa,-mbranches-within-32B-boundaries -ffat-lto-objects -feliminate-unused-debug-types -fasynchronous-unwind-tables -Wall -Wformat -Wformat-security -grecord-gcc-switches -Wl,-O3 -Wl,--as-needed -Wl,-z,now,-z,relro -Wl,--sort-common -Wl,--enable-new-dtags\"\nbuild\tCGO_CPPFLAGS=\nbuild\tCGO_CXXFLAGS=\nbuild\tCGO_LDFLAGS=\nbuild\tGOARCH=amd64\nbuild\tGOOS=linux\nbuild\tGOAMD64=v1\n\xf92C1\x86\x18 r\x00\x82B\x10A\x16\xd8\xf2"
I had this failure with CFLAGS+="-fplugin=annobin"
Huh, reproduced.
It fails for me if I put ggdb3 in CFLAGS. I don't see any evidence it's actually failing to unset LDFLAGS. I think it's just because you put the same content in each variable.
> It fails for me if I put ggdb3 in CFLAGS. I don't see any evidence it's actually failing to unset LDFLAGS. I think it's just because you put the same content in each variable. I only have ggdb3 in my CFLAGS. I really don't understand why they repeat. My *FLAGS are set up as follows... CFLAGS="-march=native -O3 -pipe -D_FORTIFY_SOURCE=2 -falign-functions=32 -Wa,-mbranches-within-32B-boundaries ${GRAPHITE} -flto=auto -ffat-lto-objects ${SEMINTERPOS} ${DEVIRTLTO} ${NOPLT} ${IPAPTA} -feliminate-unused-debug-types -fasynchronous-unwind-tables -Wall -Wformat -Wformat-security -ggdb3 -grecord-gcc-switches" CXXFLAGS="${CFLAGS} -D_GLIBCXX_ASSERTIONS" LDFLAGS="-Wl,-O3 -Wl,--as-needed -Wl,-z,now,-z,relro -Wl,--sort-common -Wl,--enable-new-dtags" FCFLAGS="${CFLAGS}" FFLAGS="${CFLAGS}"
I made the PR with what we have so far (and an update). Let me know if I need to make any edits.
(In reply to Randall from comment #13) > > It fails for me if I put ggdb3 in CFLAGS. I don't see any evidence it's actually failing to unset LDFLAGS. I think it's just because you put the same content in each variable. > > I only have ggdb3 in my CFLAGS. I really don't understand why they repeat. > My *FLAGS are set up as follows... > https://github.com/vaeth/portage-bashrc-mv does it, I think. You're using an unsupported bashrc thing which modifies your flags in an odd way.
You were right Sam! Thank you for pointing that out. I completely forgot that GentooLTO pulls that in. I fixed my flags, but still, this ebuild flags with `-ggdb3` in the CFLAGS altogether, regardless.
Created attachment 781517 [details] build.log (with ggdb3) [FIXED]
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d4f025e9b4df364ffd0677bafc802eec2ea587ad commit d4f025e9b4df364ffd0677bafc802eec2ea587ad Author: Randall T. Vasquez <ran.dall@icloud.com> AuthorDate: 2022-05-29 16:01:16 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-06-01 01:50:51 +0000 dev-util/github-cli: add new filter flags This commits add `flag-o-matic` and add `-ggdb3` and `-flto*` in two seperate `fliter-flags` stanzas. Closes: https://bugs.gentoo.org/847991 Signed-off-by: Randall T. Vasquez <ran.dall@icloud.com> Signed-off-by: Sam James <sam@gentoo.org> dev-util/github-cli/github-cli-9999.ebuild | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
