SymLink ld.lld -> ld.lld-9 about tc-build HOT 16 CLOSED

If you specify -fuse-ld=lld but don't use -Bprefix, clang will locate x86_64-unknown-linux-gnu-ld.lld (if the default target triple is x86_64-unknown-linux-gnu) and ld.lld in clang -print-search-dirs, then $PATH.

clang-9 will not magically locate ld.lld-9. If you really want to locate ld.lld-9, use -fuse-ld=lld-9

from tc-build.

AFAICS there is a blabla suffix which can be set (here: 9) as build-option.

MAJOR_VER="9"
MINOR_VER="0"
PATCH_VER="0"
VER="${MAJOR_VER}.${MINOR_VER}.${PATCH_VER}"
##RC="rc5"
PKG_VER="${VER}${RC}"

PRG_SUFFIX_VER="$MAJOR_VER"

from tc-build.

That's specifically a Debian thing as far as I can tell; I would rather not add semantics like this to the script (right now it has no concept of version) and the build/installation process is just upstream's. Plus, this would be backwards from clang; clang-10 is symlinked to clang.

I think the proper thing for you to do is either:

• Do the symlink yourself in your wrapper script
• Don't do the symlink and just modify your build script to just use ld.lld

from tc-build.

clang & co gets symlinked to clang-9 within/after the build-process, but why not ld.lld?

Looks like linker do not need a $PRG_SUFFIX_VER :-).

from tc-build.

clang & co gets symlinked to clang-9 within/after the build-process, but why not ld.lld?

It's actually the reverse. clang-10 is the normal binary, clang is a symlink to it. Debian is the one that does that whole symlink dance with everything being versioned: https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/blob/snapshot/debian/rules#L631

$ ls -al clang*
lrwxrwxrwx 1 nathan nathan        8 Jul 21 20:21 clang -> clang-10
lrwxrwxrwx 1 nathan nathan        5 Jul 21 20:21 clang++ -> clang
-rwxr-xr-x 1 nathan nathan 57602456 Jul 21 20:21 clang-10
lrwxrwxrwx 1 nathan nathan        5 Jul 21 20:21 clang-cl -> clang
lrwxrwxrwx 1 nathan nathan        5 Jul 21 20:21 clang-cpp -> clang
-rwxr-xr-x 1 nathan nathan  2295816 Jul 21 20:20 clang-format
-rwxr-xr-x 1 nathan nathan 28209536 Jul 21 20:20 clang-import-test
-rwxr-xr-x 1 nathan nathan  3526688 Jul 21 20:20 clang-offload-bundler
-rwxr-xr-x 1 nathan nathan 23997504 Jul 21 20:20 clang-refactor
-rwxr-xr-x 1 nathan nathan 23025056 Jul 21 20:20 clang-rename
-rwxr-xr-x 1 nathan nathan 22557200 Jul 21 20:20 clang-scan-deps

I have no idea why ld.lld doesn't do something similar but that'd be a question for the upstream developers.

from tc-build.

In Debian system you can use diverse versions of llvm-toolchain components. So, you can parallelly install ld.lld-8 with ld.lld-9.

from tc-build.

Using different names for install-dir targets (stage1-only built toolchain), I should be able to use binaries from a llvm-toolchain-9 and llvm-toolchain-10 parallelly.

from tc-build.

Yeah, I do not want to add those heuristics into the script itself. It has no concept of versioning right now, which I would have to add to symlink the binaries to their versioned location, and I do not want to have to keep track of what binaries to version and such. That logic belongs in a wrapper script like you have. Alternatively, you could just switch between which LLVM toolchain bin directory is added to PATH at kernel compilation time (are you ever going to be using LLVM 9 and LLVM 10 at the exact same time?)

from tc-build.

Currently, I am building llvm-toolchain-9.

from tc-build.

@MaskRay

Thanks for the clarifications.

I remember the early days with lld and -fuse-ld=... option.

So I have:

[ ~/.bashrc ]
...

# tc-build
if [ -d ~/src/llvm-toolchain/install/bin ] ; then
    export PATH=~/src/llvm-toolchain/install/bin:${PATH}
fi

...and see:

$ clang-9 -print-search-dirs
programs: =/home/sdi/src/llvm-toolchain/install/bin:/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/bin
libraries: =/home/sdi/src/llvm-toolchain/install/lib/clang/9.0.0:/usr/lib/gcc/x86_64-linux-gnu/8:/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu:/lib/x86_64-linux-gnu:/lib/../lib64:/usr/lib/x86_64-linux-gnu:/usr/lib/gcc/x86_64-linux-gnu/8/../../..:/home/sdi/src/llvm-toolchain/install/bin/../lib:/lib:/usr/lib

Setting -fuse-ld=/full/path/to/linker/executable works as well (see [1] and [2]):

ifneq ($(shell $(LD) --version 2>&1 | head -n 1 | grep LLD),)
CLANG_FLAGS	+= -fuse-ld=$(shell which $(LD))
endif

I dropped all kbuild-lld patches and build now without them.

Personally, I liked the patch "init/Kconfig: add config support for detecting linker" (see [3]).
To see in my kernel-config which CONFIG_LD_XXX is set.
Currently it has no users.

How can I check for ld.bfd linker usage (below for ld.lld)?

$ cd linux
$ readelf --string-dump .comment vmlinux

String dump of section '.comment':
  [     0]  Linker: LLD 9.0.0 (git://github.com/llvm/llvm-project 1e6b12dd3158a554c63d332df6b25f407eed9556)
  [    61]  ClangBuiltLinux clang version 9.0.0 (git://github.com/llvm/llvm-project 1e6b12dd3158a554c63d332df6b25f407eed9556) (based on LLVM 9.0.0)

[1] https://lore.kernel.org/patchwork/patch/1057183/
[2] https://lists.llvm.org/pipermail/llvm-dev/2018-March/122163.html
[3] https://lore.kernel.org/patchwork/patch/1040760/

from tc-build.

@MaskRay

clang-9 will not magically locate ld.lld-9. If you really want to locate ld.lld-9, use -fuse-ld=lld-9

For my linker wrapper-script:

[ /usr/bin/mylinker ]

#!/bin/bash

ld.lld-9 "$@" <--- XXX: Use ld.lld instead?

from tc-build.

-fuse-ld won't do anything for the kernel right now because $(CC) is not used to link anything after the vDSO conversion that Masahiro did (example), only $(LD) is. The way to use lld for the kernel is passing LD=ld.lld to make.

What I would recommend doing is doing something similar to what you have in your .bashrc but in your kernel build script what will allow you to change versions based on a parameter; maybe something like this (defaults to 9 unless a parameter is provided)?

...
LLVM_VERSION=${1:=9}
PATH=${HOME}/src/llvm-toolchain-${LLVM_VERSION}/install/bin:${PATH}
...

# Uses LLVM 9
$ ./build.sh
# Uses LLVM 8
$ ./build.sh 8

from tc-build.

Happy to make changes to the Debian packages if it makes your life easier.

from tc-build.

As a user of a wrapper-script for compiler and linker - on a Debian/buster system - I see the problem to mix them up when I use a llvm-toolchain build with tc-build and parallelly have:

# apt-get install --no-install-recommends llvm-9 clang-9 lld-9 -t llvm-toolchain-buster

lld-9 installs:

/usr/bin/ld.lld-9
/usr/bin/ld64.lld-9
/usr/bin/lld-9
/usr/bin/lld-link-9
/usr/bin/wasm-ld-9

As /path/to/install/bin (tc-build with stage1-only build+install) provides only ld.lld I will do a manually generated symlink.

Here my wrapper-script:

[ /usr/bin/mylinker ]
#!/bin/bash

ld.lld-9 "$@"

Debian provides a symlink only when lld meta-package is installed.
For Debian/buster the default is version 7 means ld.lld -> ld.lld-7.

# LC_ALL=C apt-cache policy lld
lld:
  Installed: (none)
  Candidate: 1:7.0-47
  Version table:
     1:9.0-48+0~20190219101442.49~1.gbpfaf61f 99
         99 http://apt.llvm.org/unstable llvm-toolchain/main amd64 Packages
     1:8.0-48~exp1 99
         99 http://deb.debian.org/debian experimental/main amd64 Packages
     1:7.0-47.1 99
         99 http://deb.debian.org/debian testing/main amd64 Packages
         99 http://deb.debian.org/debian unstable/main amd64 Packages
     1:7.0-47 500
        500 http://deb.debian.org/debian buster/main amd64 Packages

To be on the safe side I de-install all Debian packages from lvm-toolchain-buster when I want to use a selfmade llvm-toolchain built with tc-build.

I see that I have to ensure which binaries will be used for a build.

from tc-build.

Is there nothing wrong with just adding PATH=<path_to_tc_build_install_bin_folder>:${PATH} <kernel_build_command> to make sure that all of the proper binaries get used?

from tc-build.

I am closing this as this is not something the script will support natively (and based on further discussion upstream, not necessarily something we will account for with the proposed LLVM=y: https://lore.kernel.org/lkml/20200331193544.GA55810@ubuntu-m2-xlarge-x86/)

from tc-build.