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(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=116f54058abd4fa4a5b3c16ee49a99df11883a45 commit 116f54058abd4fa4a5b3c16ee49a99df11883a45 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-08-15 21:13:28 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-08-15 21:18:23 +0000 go-env.eclass: workaround debug info issues Go can't handle some DWARF produced by GCC but nobody's been able to produce a simple testcase for it, so add a workaround where we replace -g3 with -g and -ggdb3 with -ggdb for GCC, like Ionen did in Kitty. Bug: https://bugs.gentoo.org/847991 Bug: https://bugs.gentoo.org/924436 Bug: https://bugs.gentoo.org/924496 Closes: https://bugs.gentoo.org/929219 Signed-off-by: Sam James <sam@gentoo.org> eclass/go-env.eclass | 6 ++++++ 1 file changed, 6 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8b05c1c26ef96bb9324db626572f3c4a73e3178c commit 8b05c1c26ef96bb9324db626572f3c4a73e3178c Author: Emanuele Torre <torreemanuele6@gmail.com> AuthorDate: 2024-08-14 05:36:34 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-08-15 21:18:22 +0000 dev-util/github-cli: fix build failure when -ggdb3 is in CFLAGS After experiencing the bug described in https://bugs.gentoo.org/924496, I was surprised to see filter-flags "-ggdb3" in the ebuilds for this package. I did some digging and found that go's goc does not use CFLAGS, LDFLAGS, etc by default; it only uses the GOC_*FLAGS environment variables. What causes goc to use CFLAGS if GOC_FLAGS is unset or empty is the go-env_set_compile_environment function from the go-env eclass, that is indirectly called by the go-module_live_vendor and go-module_src_unpack functions from the go-module eclass that are being called from the src_unpack of this ebuild. So, calling filter-lto , filter-flags "-ggdb3" , and unset LDFLAGS from src_compile before emake seems completely useless since those will only filter regular *FLAGS environment variable, and not the GOC_*FLAGS environment variables initialised from the *FLAGS variables earlier on in src_unpack. Moving those filter/unset commands to the start of src_unpack makes them filter/unset *FLAGS variables before GOC_*FLAGS variables are set, and actually fix the build problem encountered when CFLAGS contains -ggdb3. Bump copyright of touched ebuild files. Bug: https://bugs.gentoo.org/847991 Closes: https://bugs.gentoo.org/924496 Signed-off-by: Emanuele Torre <torreemanuele6@gmail.com> Closes: https://github.com/gentoo/gentoo/pull/38140 Signed-off-by: Sam James <sam@gentoo.org> dev-util/github-cli/github-cli-2.27.0.ebuild | 15 ++++++++------- dev-util/github-cli/github-cli-2.31.0.ebuild | 15 ++++++++------- dev-util/github-cli/github-cli-2.32.1.ebuild | 15 ++++++++------- dev-util/github-cli/github-cli-2.33.0.ebuild | 15 ++++++++------- dev-util/github-cli/github-cli-2.42.0.ebuild | 13 +++++++------ dev-util/github-cli/github-cli-2.52.0.ebuild | 13 +++++++------ dev-util/github-cli/github-cli-9999.ebuild | 15 ++++++++------- 7 files changed, 54 insertions(+), 47 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1f754863ff91dc4dca11e6a5217ffd449f39c74c commit 1f754863ff91dc4dca11e6a5217ffd449f39c74c Author: Sam James <sam@gentoo.org> AuthorDate: 2024-08-15 21:23:22 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-08-15 21:24:05 +0000 go-env.eclass: improve debug workaround Use what Ionen did in x11-terms/kitty to avoid touching flags for non-Go parts of the build. Bug: https://bugs.gentoo.org/847991 Bug: https://bugs.gentoo.org/924436 Bug: https://bugs.gentoo.org/924496 Bug: https://bugs.gentoo.org/929219 Signed-off-by: Sam James <sam@gentoo.org> eclass/go-env.eclass | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)
