ld: Append LDFLAGS to flags variable in default_ld_link
A patch to append LDFLAGS to the flags variable in default_ld_link is being reconsidered.
John David Anglin is revisiting a patch that appends LDFLAGS to the flags variable in default_ld_link within the binutils linker (ld). Alan Modra indicates that the original approach intentionally avoided this, updating .exp files instead, but is open to the change if all ld_link instances should use LDFLAGS, potentially simplifying the configuration by removing redundant LDFLAGS specifications in .exp files.
- proposer
States that appending `LDFLAGS` to the flags in `default_ld_link` is acceptable if it ensures all `ld_link` calls utilize `LDFLAGS`, and suggests removing any now-unnecessary `LDFLAGS` additions.
“That was likely why I did it that way, but if you need all occurrences of ld_link to use LDFLAGS then I'm happy for you to put it in default_ld_link, and ideally remove the then unnecessary places I added LDFLAGS.”
In Details
The ld linker combines object files into executables or shared libraries. LDFLAGS is an environment variable commonly used to specify linker flags. The default_ld_link function likely sets up default flags for the linking process. The core question is whether to incorporate LDFLAGS into these defaults versus passing them explicitly in test scripts (.exp files), balancing convenience and control.
For Context
The linker (ld) is a crucial tool in the software build process. It takes compiled object files and combines them into a single executable program or library. The linking process often requires specific flags to control how the files are combined such as specifying library paths or defining symbols. These flags can be passed to the linker via the LDFLAGS environment variable. This discussion revolves around whether to automatically include LDFLAGS in the default linker settings or to specify them explicitly in test scripts.