I don't have a lot more to add, I've put some comments inline:
Ping. Any more thoughts on this option?
Given the amount of possible names, sometimes target dependent, that
libclang_rt can take I think the current situation is unfriendly
enough to do something about it.
The GCC equivalent solution to this is -print-libgcc-file-name
From the man page:
Same as -print-file-name=libgcc.a.
This is useful when you use -nostdlib or -nodefaultlibs but
you do want to link with libgcc.a. You can do:
gcc -nostdlib <files>... `gcc -print-libgcc-file-name`
Would it be worth coming up with a similar solution in clang?
As Petr says, this exists already. My proposal is to have a more user friendly option that doesn’t require a separation invocation. The issue with using that technique for me is that you have to specify all the necessary options in order to get the exact same path to the runtime lib as you would get in the link invocation. The driver already has the information available to it, so it seems a waste to have to specify it twice.
OK, I can see that not requiring a second tool invocation would be a benefit.
Some other questions:
- On Linux there is not a single libclang_rt.a, but many separate ones
like ./clang/9.0.0/lib/linux/libclang_rt.builtins-x86_64.a would this
option be just the builtins?
This is somewhat case as well on Darwin too, I just omitted the variants for brevity. For example, we have libclang_rt.ios.a and libclang_rt.osx.a, which are fat archives containing multiple architecture libs inside. Point being there’s no single libclang_rt.a file, we have logic in the driver to select the right variant to link. As to your question on whether this would be just the builtins, I would say yes. The intended use case for this option is to link in the runtime which the compiler needs as a necessary part of it’s codegen. I don’t intend to link anything else like asan runtimes. Because of that, perhaps a more obvious name like “-flink-builtin-rt” might be better? I don’t know.
Thanks for the clarification. I personally prefer making the name
specific to the builtins, but I'm aware that compiler-rt is split up
that way. I don't know whether many users will though. Not got a
- Would this extend to libgcc on linux? I don't know enough about
Windows to know about an equivalent?
I would only implement this on Darwin for now, but in theory yes. I think libgcc’s divide routines for example are necessary for armv7, but if you try to use -nostdlib with a linux target you’d run into the same problem.
A pity, this could be useful on linux and embedded systems.
- A possible alternative is that the presence of --rtlib=<library> is
sufficient to add the -l even if --nodefaultlib etc. are added.
I thought about that. It’s possible but I would rather not change the existing behaviour of options unless consensus is that it’s a good idea. With a new option there’s no risk of breaking existing code. The other thing with that is it seems like it could be interpreted as config option rather than a link option. E.g. maybe there are cases that option could be used to specify the *names* of symbols to use for particular runtime functionality, but without prescribing the implementation. It’s a niche corner case that I don’t know is realistic I admit.