| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: William Hubbs <williamh@gentoo.org>
|
|
The real issue is intrinsic to Go (or cgo, anyway) and so we shouldn't
do it per-package, but rather in go-env.eclass. That's done now, so
drop the package-local workaround.
Bug: https://bugs.gentoo.org/924496
Signed-off-by: Sam James <sam@gentoo.org>
|
|
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>
|
|
Signed-off-by: Leonardo Hernández Hernández <leohdz172@proton.me>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: William Hubbs <williamh@gentoo.org>
|
