| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Package-Manager: Portage-2.3.84, Repoman-2.3.20
Signed-off-by: Marek Szuba <marecki@gentoo.org>
|
|
|
|
|
|
|
|
| |
It still depends on llvm-8 though, it gave me a lot of "undefined
reference" errors when I tried to build it against 9.0.1.
Package-Manager: Portage-2.3.84, Repoman-2.3.20
Signed-off-by: Marek Szuba <marecki@gentoo.org>
|
|
|
|
|
| |
Package-Manager: Portage-2.3.79, Repoman-2.3.16
Signed-off-by: Marek Szuba <marecki@gentoo.org>
|
|
|
|
|
| |
Package-Manager: Portage-2.3.79, Repoman-2.3.16
Signed-off-by: Marek Szuba <marecki@gentoo.org>
|
|
|
|
|
| |
Package-Manager: Portage-2.3.79, Repoman-2.3.16
Signed-off-by: Marek Szuba <marecki@gentoo.org>
|
|
|
|
|
|
|
|
|
|
| |
When invoked without max_slot, get_llvm_prefix() iterates over *all*
LLVM slots known to llvm.eclass - including those exceeding LLVM_MAX_SLOT.
As a consequence, an ebuild can e.g. end up getting installed into llvm:9
directories in spite of having been linked against llvm:8.
Package-Manager: Portage-2.3.76, Repoman-2.3.16
Signed-off-by: Marek Szuba <marecki@gentoo.org>
|
|
|
|
|
| |
Package-Manager: Portage-2.3.76, Repoman-2.3.16
Signed-off-by: Marek Szuba <marecki@gentoo.org>
|
|
|
|
|
| |
Package-Manager: Portage-2.3.76, Repoman-2.3.16
Signed-off-by: Marek Szuba <marecki@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upstream CMake files assumed that the shared-library file of opencl-clang
is named libopencl-clang.so.x if LLVM version is x.0.0 but
libopencl-clang.so.x.y.z otherwise. This is not correct, as
demonstrated by opencl-clang-8.0.1 - the shared library is still called
libopencl-clang.so.8. Make CMake always look for .so.x instead.
Closes: https://bugs.gentoo.org/690520
Package-Manager: Portage-2.3.69, Repoman-2.3.16
Signed-off-by: Marek Szuba <marecki@gentoo.org>
|
|
|
|
|
| |
Signed-off-by: Marek Szuba <marecki@gentoo.org>
Package-Manager: Portage-2.3.66, Repoman-2.3.11
|
|
|
|
|
|
|
|
|
| |
From 8.0.1 onwards opencl-clang uses the new library name in place of
the legacy "common_clang". Make sure old IGC ebuilds do not try to use
newer versions.
Signed-off-by: Marek Szuba <marecki@gentoo.org>
Package-Manager: Portage-2.3.66, Repoman-2.3.11
|
|
|
|
|
| |
Signed-off-by: Marek Szuba <marecki@gentoo.org>
Package-Manager: Portage-2.3.66, Repoman-2.3.11
|
|
|
|
|
|
|
| |
Now with proper gcc-9.1 support.
Signed-off-by: Marek Szuba <marecki@gentoo.org>
Package-Manager: Portage-2.3.66, Repoman-2.3.11
|
|
|
|
|
|
|
|
|
| |
Moreover, explicitly reject the use of gcc-9+ because they are known to
fail.
Bug: https://bugs.gentoo.org/685790
Signed-off-by: Marek Szuba <marecki@gentoo.org>
Package-Manager: Portage-2.3.62, Repoman-2.3.11
|
|
First-order dependency of Intel Graphics Compute Runtime.
Signed-off-by: Marek Szuba <marecki@gentoo.org>
Package-Manager: Portage-2.3.62, Repoman-2.3.11
|