I am a linker (ld.lld) developer and have posted ⚙ D103303 [ELF] Add --overwrite-section-script for a linker script feature customizing output section descriptions1 without affecting the output section
order[2].
This option is versatile. Users can do
Use section : { KEEP(...) } to retain input sections under section-based garbage collection
Define encapsulation symbols (start/end) for an output section
Use section : ALIGN(...) : { ... } to overalign an output section (similar to ld64 -sectalign)
From a build system perspective, do you think such an option should be able to be used implicitly (an input text file is considered a linker script)?
Implicit examples include glibc libc.so and libm.a (GROUP (/usr/lib/x86_64-linux-gnu/libm-2.31.a /usr/lib/x86_64-linux-gnu/libmvec.a )). ld ... -lc -lm can pick up such linker scripts disguised as .so and .a files. A comment on D103303 has an argument preferring this usage: "… Supporting “just add -lfoo to your compile” as the end-user API for using a library is highly desireable, and often a non-negotiable requirement. "
An argument preferring an explicit option is that the implicit usage can be too subtle. GROUP and INPUT commands may be ok as they just provide a way to split a library into more files. Allowing the full power of SECTIONS command may be too clever and can be tricky to debug.
[2]: The default SECTIONS command specifies an output section order
and suppresses some built-in rules of section placement.
I suspect that CMake will continue preferring the full path to “libraries” (even if they are linker scripts), so I don’t know how much is of interest here. Making it explicit would mean find_library may need some changes to find these things (akin to .tbd files on macOS I suspect).
Implicit examples include glibc libc.so and libm.a
Yes, and those have worked fine.
akin to .tbd files on macOS I suspect
For reference, on macOS that has worked well. .tbd files are treated seamlessly as libraries, including find_library suffixes, but have content much like linker scripts. For example: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libc.tbd.
An argument preferring an explicit option is that the implicit usage can be too subtle.
If the purpose of a file is provide symbols for linking, or other things libraries can do, then its internal format is an implementation detail. Requiring an explicit option for a particular file format leaks such implementation details into the usage interface. This is especially problematic if command-line order matters, e.g. if the file must be ordered in the middle of a list of libraries to work correctly with them.
If one were to go with the explicit option, CMake projects would have to be explicit through target_link_options, which are placed on the link line separately from target_link_libraries and do not intermix.
Note that one place linker scripts (usually) cause problems is with file(GET_RUNTIME_DEPENDENCIES). Generally, I’ve ignored TBB (the usual suspect that I’ve run into) via PRE_EXCLUDE_REGEX and had to manage it specifically. But this is a CMake thing that needs to be handled in the general case anyways.
Thanks for the comments, the analogy of macOS .tbd files, the inconvenience of target_link_options. So I guess implicit usage looks good. I have updated my patch to allow implicit usage.