Actually, it doesn't use the compiler to link its shared libraries, it
uses $LD directly. Totally broken. The resulting shared library is LTO
bytecode linked without a bytecode handler, i.e. it's not really a real
library. Everything then explodes.
Closes: https://bugs.gentoo.org/772014
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Upstream changed this whole code around in 5.3.0 via:
https://github.com/ROCm/ROCR-Runtime/commit/adae6c61e10d371f7cbc3d0e94ae2c070cab18a4
Since then, this sed has been tweaked in small ways without
fundamentally changing the part that doesn't match anymore. Since the
sed wasn't tested, I can only assume that the promise about system
clang/llvm is outdated. ;)
I believe cmake's hints logic should simply work anyway...
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
* SED: the following did not cause any changes
* sed -i -e "s:1.7.0:${PV}:" CMakeLists.txt || die;
* no-op: -e s:1.7.0:5.7.1:
I don't actually understand the reasoning for attempting to modify it at
all, since the cmake function that this is an argument to (before it
changed to 1.8.0) explicitly takes the value, splits it on the periods
and adds each component to a VERSION_MAJOR etc cmake variable.
Then it also runs git, regardless of the input value, and tries to
calculate VERSION_COMMIT_COUNT.
So, there was nothing to fix as far as I can tell here? The only thing
sed'ing this out would ever do AFAICT is change the soname of libraries
from "1.7.0" to whatever the current ${PV} is... which is NOT how
sonames work, and upstream had a good reason to NOT have this be ${PV}.
It's quite irrelevant now since clearly the package worked just fine
despite the sed not applying, thus it *cannot* be fixing anything, and
also thus, there is clearly nothing to fix.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
A fix ported from upstream:
commit 0539e12b3de14a77481bd3f87b301b7e7550172c (HEAD -> master, repo.or.cz/master)
Author: Petr Písař <petr.pisar@atlas.cz>
Date: Thu Nov 23 21:10:05 2023 +0100
Fix building with libxml2-2.12.0
libxml-2.12.0 shuffled included header files.
Closes: https://bugs.gentoo.org/926129
Signed-off-by: Petr Písař <petr.pisar@atlas.cz>
Signed-off-by: Sam James <sam@gentoo.org>
New patch fixes AC_SYS_LARGEFILE issues. Thanks to Dima Pasechnik for
doing the legwork.
Closes: https://bugs.gentoo.org/921138
Signed-off-by: Michael Orlitzky <mjo@gentoo.org>
Dropped upstream in https://sourceforge.net/p/hugin/hugin/ci/7811fb3dab6c7d5cfd1133df40e1f0845a173d62/
from 2014.
Someone posted about this on /r/gentoo a few weeks ago and I found it curious
but didn't dig into it more. After coming across bug #924925 for zthread, I thought
I'd take a deeper look.
hugin still has the CMake module for zthread but it's not called anywhere, and
the bundled copy in foreign/ it references is long-gone too.
Note that hugin also, since 2014, supports OpenMP as a replacement, but handling
that in a separate commit as can't do that in stable like we are here.
Bug: https://bugs.gentoo.org/924925
Bug: https://bugs.gentoo.org/926788
Signed-off-by: Sam James <sam@gentoo.org>
When installing a binpkg, Portage will restore the ebuild environment
from when the binpkg was built. The stored values for KV_* may be
different from the values that would be detected on the current system.
To work around this, unset some key variables in
linux-info_get_any_version when MERGE_TYPE == binary.
Also, only look for the running kernel version: we can't possibly need
a full kernel source tree when installing a package that has already
been compiled. This gives a nice speedup as well.
Closes: https://bugs.gentoo.org/926063
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
Old codebase with no upstream releases since 2007. Already has a scary Fortran
workaround for GCC 10 too.
Closes: https://bugs.gentoo.org/863368
Signed-off-by: Sam James <sam@gentoo.org>
Due to implicit function declarations, LTO fails to detect the
availability of a function and errors out due to an undefined reference
at link time.
It's fixed in bash 4.0 and on, but the value of backporting the fix to
versions of bash that have niche use (people interested in exploring old
versions, not people who are looking for the shebang interpreter for
their system scripts) is a matter of some question...
Closes: https://bugs.gentoo.org/893958
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Needed to e.g. pass LTO warning flags through to the linker.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Sam James
Eli Schwartz
Holger Hoffstätte
Petr Písař
Michael Orlitzky
Mike Gilbert
Matt Turner
Andreas K. Hüttel
Mike Pagano