LLVM17 references binaries in the wrong location

[Begasus]

A build on buildmaster (32bit) for qt-creator revaeled this.
cmake is looking for the binary in $binDir where the binaries are installed in $prefix/bin

CMake Error at /boot/system/lib/x86/cmake/llvm/LLVMExports.cmake:1151 (message):
 The imported target "llvm-tblgen" references the file

    "/boot/system/bin/x86/llvm-tblgen"

 but this file does not exist.  Possible reasons include:

 * The file was deleted, renamed, or moved to another location.

 * An install or uninstall procedure did not complete successfully.

 * The installation package was faulty and contained

    "/boot/system/lib/x86/cmake/llvm/LLVMExports.cmake"

 but not all the files it references.

Call Stack (most recent call first):
 /boot/system/lib/x86/cmake/llvm/LLVMConfig.cmake:280 (include)
 /boot/system/lib/x86/cmake/clang/ClangConfig.cmake:11 (find_package)
 cmake/FindClang.cmake:1 (find_package)
 CMakeLists.txt:105 (find_package)

[Begasus]

Pokes @nielx :)

[Begasus]

The paths for the binaries declared in LLVMExports-release.cmake all point to ${_IMPORT_PREFIX}/bin/x86 where the binaries are installed in ${_IMPORT_PREFIX}/bin

And in LLVMConfig.cmake I see set(LLVM_TOOLS_BINARY_DIR "${LLVM_INSTALL_PREFIX}/bin/x86")

[Begasus]

From CMakeLists.txt, so this probably could be set in BUILD()?

set(LLVM_TOOLS_INSTALL_DIR "${CMAKE_INSTALL_BINDIR}" CACHE STRING
    "Path for binary subdirectory (defaults to '${CMAKE_INSTALL_BINDIR}')")
mark_as_advanced(LLVM_TOOLS_INSTALL_DIR)

[davidkaroly]

Is this a regression from llvm16?

[nielx]

I feel like I am missing something here. Why wouldn't the tools be installed in bin/x86 on a 32 bit system? Isn't that the default?

[Begasus]

Is this a regression from llvm16?

Will do a check with LLVM16 and report back here.

[Begasus]

I feel like I am missing something here. Why wouldn't the tools be installed in bin/x86 on a 32 bit system? Isn't that the default?

It looks like the build for cmake doesn't respect CMAKE_INSTALL_BINDIR and uses $prefix/bin instead of $binDir here. For most of the time we try to install binaries for x86 (x86_gcc2) in $commandBinDir if they can't be build for gcc2 (this isn't an issue here because cmake is using some other form to install the "tools").
But the configuration files seem to respect CMAKE_INSTALL_BINDIR and so confuses the build not finding the tools in the right place?

[Begasus]

Is this a regression from llvm16?

Will do a check with LLVM16 and report back here.

Did a check and indeed with LLVM16 it also fails, LLVM12 is still good (LLVM9 should be also).
Looking into the recipe from version 12 vs 16 I see the switch from using $cmakeDirArgs (which supplies bindir/libdir etc) vs -DCMAKE_INSTALL_PREFIX=$prefix (LLVM12 and LLVM9). This probably caused the breakage?

Still doesn't explain why LLVM_TOOLS_INSTALL_DIR doesn't respect CMAKE_INSTALL_BINDIR

EDIT: LLVM9 also fails but with not finding LLVMDemangle

[nielx]

It was staring us right in the face:

	if [ -n "$secondaryArchSuffix" ]; then
		mv $binDir/* $prefix/bin/
		binDir=$prefix/bin
	fi

I think we have three options:

1. Rewrite the recipe to do things properly, i.e. keep things in the secondary arch suffix and adjust the provides accordingly.
2. Rewrite the cmake configure command to set CMAKE_INSTALL_BINDIR to prefix/bin
3. Symlink the tools to prefix/bin rather than copying, keeping the originals in bin/x86 and thereby not breaking llvm-config.

I will look in the git history to see if there is a reason these tools were moved in the past, but it might just require us some experimenting to see what's right.

[davidkaroly]

It was staring us right in the face:

well I guess that's my fault... I'd go with option (2) i.e. adjust CMAKE_INSTALL_BINDIR. We might need to use hand-crafted cmake args then, instead of $cmakeDirArgs

[nielx]

It was staring us right in the face:

well I guess that's my fault... I'd go with option (2) i.e. adjust CMAKE_INSTALL_BINDIR. We might need to use hand-crafted cmake args then, instead of $cmakeDirArgs

I think @Begasus is going to try to see what happens if we leave things in bin/x86, and adjust the recipe accordingly.

[Begasus]

Yeah, got a build running (slow) on one of the laptops (32bit), will launch one here in virtual (32bit) for it in a bit, should be a lot faster at least.

[Begasus]

PR created, I ran a (quick) check to see if qt-creator could pick up LLVM17 fine now, this worked out OK. Could probably use some more checks. :)

[nielx]

Had a quick glance, looks good to me!

[Begasus]

Fixed in: #9593