D44548 noted that lorder(1) which is installed in -toolchain requires
nm(1) which is installed in -clang. Add an appropriate dependency.
Reported by: des
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 65768 Build 62651: arc lint + arc unit
Event Timeline
Comment Actions
It's a bit of a shame to do this for the sake of basically obsolete lorder(1).
Also nm likely belongs in the toolchain package rather than clang?
Comment Actions
this was my initial thought as well but it does actually come from clang, so i think you can make an argument either way: i discussed this with des and he favours keeping nm where it is.
maybe we need to define the use-cases here. -toolchain is supposed to be the tools which are not compiler-specific, so it includes things like lex and yacc, as well as config(8) and some of the elftoolchain bits (elfcopy).
what will users want to do?
- build software with the base llvm: install -clang and -toolchain
- build their own software that uses yacc with their own gcc: install gcc (from ports) and -toolchain
- build the base system with gcc: install gcc (from ports) and don't install -toolchain (since config is built by the cross tools)
it seems like cases #1 and #3 don't require this dependency, and in case #2 the dependency is actually unhelpful because the user specifically doesn't want the base clang.
so i'm not opposed to moving nm and ar to -toolchain if no one objects to that. this creates a dependency on libprivatellvm from toolchain, but that's quite a bit smaller.
in that case, is there anything else we'd want to move at the same time?
Comment Actions
an alternative solution (compromise?) would be to create a new package like FreeBSD-llvm-binutils and move the LLVM tools there, then add a dependency from -toolchain to -llvm-binutils. however this seems to differ from the precedent already set with both -toolchain itself and the Kerberos packages, which is that we don't expose the origin of the tools in the package layout: FreeBSD-kerberos is always Kerberos (of some kind), so FreeBSD-toolchain should always be the toolchain (of some kind).
Comment Actions
Doesn't this break platforms where we use an external toolchain? I believe in that case we don't build a clang package, but we do build a toolchain package?
Comment Actions
it does actually come from clang
By default, but it's technically LLVM not Clang. It would make sense that someone could install GCC instead of Clang and I think we'd want nm to still be installed in that case; also it seems sensible that nm would still come from the same package if someone builds WITHOUT_LLVM_BINUTILS (at least while we support that).
a new package like FreeBSD-llvm-binutils
It would be great if we can mirror *_LLVM_BINUTILS by installing either e.g. a FreeBSD-llvm-binutils or FreeBSD-elftoolchain-tools, although I don't think we're really ready for that yet.
Comment Actions
i am not sure about external toolchains (which platforms are those?) but it will probably break if the user builds WITHOUT_LLVM_BINUTILS and WITHOUT_CLANG.
this makes me think that the other option is better: in this case, we'll install the elftoolchain version of those utilities and the -toolchain package will just get whichever ones we build. i'll make another diff to do that instead.
Comment Actions
i've been thinking about how to support this in general but it almost certainly requires reworking the entire package build system, because we can't rely on installing everything to worldstage anymore. i do have some ideas there :-)