# ld.lld --overwrite-section-script: should it be explicit or implicit?
**URL:** https://discourse.cmake.org/t/ld-lld-overwrite-section-script-should-it-be-explicit-or-implicit/3494
**Category:** Usage
**Tags:** os:linux
**Created:** [June 4, 2021, 5:07am UTC](https://discourse.cmake.org/t/ld-lld-overwrite-section-script-should-it-be-explicit-or-implicit/3494 "2021-06-04T05:07:22Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@MaskRay](https://discourse.cmake.org/u/MaskRay)
#### Post date: [June 4, 2021, 5:07am UTC](https://discourse.cmake.org/t/ld-lld-overwrite-section-script-should-it-be-explicit-or-implicit/3494/1 "2021-06-04T05:07:22Z")
I am a linker (ld.lld) developer and have posted [⚙ D103303 [ELF] Add --overwrite-section-script](https://reviews.llvm.org/D103303) for a linker script feature customizing output section descriptions[1](https://sourceware.org/binutils/docs/ld/Output-Section-Description.html) 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.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [June 4, 2021, 12:42pm UTC](https://discourse.cmake.org/t/ld-lld-overwrite-section-script-should-it-be-explicit-or-implicit/3494/2 "2021-06-04T12:42:00Z")
@brad.king Thoughts on how CMake would do this?
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).
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [June 4, 2021, 3:38pm UTC](https://discourse.cmake.org/t/ld-lld-overwrite-section-script-should-it-be-explicit-or-implicit/3494/3 "2021-06-04T15:38:39Z")
> 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](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.20.3/Modules/Platform/Darwin.cmake#L67), 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.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [June 4, 2021, 4:04pm UTC](https://discourse.cmake.org/t/ld-lld-overwrite-section-script-should-it-be-explicit-or-implicit/3494/4 "2021-06-04T16:04:39Z")
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.
---
### Author:  [@MaskRay](https://discourse.cmake.org/u/MaskRay)
#### Post date: [June 4, 2021, 8:06pm UTC](https://discourse.cmake.org/t/ld-lld-overwrite-section-script-should-it-be-explicit-or-implicit/3494/5 "2021-06-04T20:06:01Z")
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.