Created attachment 560080 [details] compressed build log emerge -pv =llvm-9999 Calculating dependencies... done! [ebuild NS *] sys-devel/llvm-9999:8::gentoo [6.0.1-r2:6::gentoo] USE="libffi ncurses xml -debug -doc -exegesis -gold -libedit -test -xar" ABI_X86="(64) -32 (-x32)" LLVM_TARGETS="AMDGPU ARM (X86) -AArch64 -AVR -BPF -Hexagon -Lanai -MSP430 -Mips -NVPTX -Nios2 -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore" 0 KiB Total: 1 package (1 in new slot), Size of downloads: 0 KiB the header in question can be installed by emerging sci-libs/cblas-reference, so a propper fix might be to add virtual/cblas in RDEPEND?
This error now affects sys-devel/llvm-8.0.0_rc*.
Adjusted the description accordingly. Is it sufficent for you to emerge virtual/cblas?
(In reply to tt_1 from comment #2) > Is it sufficent for you to emerge virtual/cblas? Yes. Builds fine after that.
I'm sorry, did we come to any conclusion where this thing is coming from?
(In reply to Michał Górny from comment #4) > I'm sorry, did we come to any conclusion where this thing is coming from? No idea. A "grep -ri cblas" comes up empty, so that cblas code probably comes from some external .cmake file?
That's what I suspect as well. Could you grep the build log after installing cblas to see where it's referenced?
grep -ri lapack /var/tmp/portage/sys-devel/llvm-8.0.0_rc2 /var/tmp/portage/sys-devel/llvm-8.0.0_rc2/temp/environment:declare -- CMAKE_REMOVE_MODULES_LIST="FindBLAS FindLAPACK" Nothing else.
Wrong paste. I grepped for "blas": $ grep -ri blas /var/tmp/portage/sys-devel/llvm-8.0.0_rc2 /var/tmp/portage/sys-devel/llvm-8.0.0_rc2/temp/environment:declare -- CMAKE_REMOVE_MODULES_LIST="FindBLAS FindLAPACK"
Build log, not environment. If it's finding it, it should report something. Maybe the context could suggest where it's coming from. What I'm trying to figure out first, is whether cblas is a indirect dependency of something LLVM uses, or some random module interaction that really shouldn't happen.
Also, if we hurry and it's upstream issue, we may able to get the fix before 8.0.0 final.
(In reply to Michał Górny from comment #9) > Build log, not environment. It's a "grep -ri". It searches everything. Build log included.
(In reply to Nikos Chantziaras from comment #11) > (In reply to Michał Górny from comment #9) > > Build log, not environment. > > It's a "grep -ri". It searches everything. Build log included. Not necessarily. It doesn't follow symlinks, and if you happen to use PORT_LOGDIR, build log is a symlink. Also it wouldn't work if you used compressed build logs.
if virtual/cblas is emerged, there is no difference whatsoever in the build dir when grepping for 'cblas', see this grep for: grep -ri blas /var/tmp/portage/sys-devel/llvm-8.0.0_rc2/ /var/tmp/portage/sys-devel/llvm-8.0.0_rc2/work/llvm-8.0.0rc2.src/lib/XRay/FDRTraceWriter.cpp: // appear and that we expect, instead of blasting bytes of the struct through. /var/tmp/portage/sys-devel/llvm-8.0.0_rc2/work/llvm-8.0.0rc2.src/lib/Transforms/Scalar/LoopIdiomRecognize.cpp:// replace them with calls to BLAS (if linked in??). /var/tmp/portage/sys-devel/llvm-8.0.0_rc2/work/llvm-8.0.0rc2.src/lib/IR/AsmWriter.cpp: // If we didn't need any quotes, just write out the name in one blast. /var/tmp/portage/sys-devel/llvm-8.0.0_rc2/work/llvm-8.0.0rc2.src/lib/Support/ErrorHandling.cpp: // Blast the result out to stderr. We don't try hard to make sure this /var/tmp/portage/sys-devel/llvm-8.0.0_rc2/work/llvm-8.0.0rc2.src/lib/Passes/PassBuilder.cpp: // Re-require GloblasAA here prior to function passes. This is particularly /var/tmp/portage/sys-devel/llvm-8.0.0_rc2/temp/environment:declare -- CMAKE_REMOVE_MODULES_LIST="FindBLAS FindLAPACK"
I'm still waiting for the new build log.
Created attachment 566660 [details] compressed tmp dir, includes build.log + environement Ok, so I emerged with FEATURES="${FEATURES} keeptemp", the result is attached. virtual/cblas was emerged before the emerge of llvm.
This really looks like some deep internal CMake problem. @kde, any ideas?
look at the patch we carry in rust for it's internal llvm - same problem, because rust's llvm is 7 + some commits on top. https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/rust/files/1.32.0-fix-configure-of-bundled-llvm.patch which reverts https://github.com/llvm-mirror/llvm/commit/6fb010f388bb2cb2f00fe039123092308ac4865d to me it looks like cmake finds stale/broken symlink and tries to links and fails if actual libs/headers are not present, I may be wrong tho.
The patch, with adjusted path for llvm standalone, applies cleanly and seems to solve to initial problem.
Yeah, I guess that'd make sense. lib/Support/CMakeLists.txt has: ADDITIONAL_HEADER_DIRS [...] ${Backtrace_INCLUDE_DIRS} where Backtrace_INCLUDE_DIRS is /usr/include. Lemme try to figure out if scanning this directory is really expected here.
The patch from D59632 should take care of it.
You have orphan symlinks in /usr, see bug 675752. For dev-lang/rust we did https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d50382655a40e343363d82b7c371a06660b9bdf8 to hide the problem but to be honest, we should drop the patch and people should fix /usr and of course, upstream should revert that patch. :)
Oh, Georgy already said that in comment #17, sorry :)
(In reply to Thomas Deutschmann from comment #21) > people should fix /usr These broken symlinks are left behind by the cblas package. When you emerge virtual/cblas, the symlinks are created by they don't belong to any package. When you unmerge/depclean, portage doesn't remove them since they don't belong to any package.
*** Bug 681326 has been marked as a duplicate of this bug. ***
I'm having a very similar problem on =sys-devel/llvm-8.0.0 with a broken symlink header, but for me it's /usr/include/pg_config_ext.h (which appears to be a postgresql thing). Is it related or should I file a separate bug? (If it is part of the same underlying issue, I'd suggest renaming the bug so it's clear it's not cblas-specific.)
*** Bug 681560 has been marked as a duplicate of this bug. ***
I can confirm that removing stale symlinks for cblas and blas pgkconfig and headers makes this ebuild emergable again.
There is a file /usr/include/cblash.h on my system, but it doesn't belong to any package. Removing it, and the configure problem of llvm is solved.
I confirm removing the stale symlink /usr/include/cblas.h solved the problem. It hadn't belong to any package: equery b /usr/include/cblas.h The broken symlink was from 2013 on my system by the way.
Removing broken symlink fixed building for me too.
my system actually didn't even try to bring in cblas or any other and just outright failed.. after emergeing virtual/cblas 3.7 llvm was able to finish compiling.. there were no previous symlinks that were broken on my system in this instance, just the missing packages.
I've pushed the change upstream. If nothing breaks in the next hour or two, I'll push it to Gentoo as well.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4b6a6ed19f30f4f30af53b2426c57194626715e7 commit 4b6a6ed19f30f4f30af53b2426c57194626715e7 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2019-04-05 05:02:42 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2019-04-05 05:13:19 +0000 sys-devel/llvm: Backport dangling symlink failure fix Closes: https://bugs.gentoo.org/674662 Signed-off-by: Michał Górny <mgorny@gentoo.org> ...Add-additional-headers-only-if-they-exist.patch | 41 +++ sys-devel/llvm/llvm-8.0.0-r1.ebuild | 301 +++++++++++++++++++++ 2 files changed, 342 insertions(+)
