On Thursday 2026-01-15 13:16, Guillem Jover wrote: > >As part of that report, my current inclination is to perhaps add a new >variable for such direct ld(1) call use, where I'm tentatively naming >it LD_LDFLAGS.
LD_LDFLAGS is backwards. The general established pattern... CPP -> CPPFLAGS CPPAS -> CPPASFLAGS CCAS -> CCASFLAGS CXX -> CXXFLAGS OBJC -> OBJCFLAGS OBJCXX -> OBJCXXFLAGS LD -> LDFLAGS so if, then do it like so: CCLD -> CCLDFLAGS CXXLD -> CXXLDFLAGS FCLD -> FCLDFLAGS >In dpkg we define several build flags defaults per vendor via >dpkg-buildflags(1) (<https://manpages.debian.org/dpkg-buildflags>), >and increasingly we have been adding options for the linker in LDFLAGS. >The problem is that some (few) projects are using that for direct >calls to ld(1) without going through the compiler. This is causing >build failures now. > >https://bugs.debian.org/1125323 >ld: -f may not be used without -shared -fcf-protection is not a linker flag and does not belong into LDFLAGS. (Just as -DFOO -I/usr/local/include are preprocessor flags, not compiler flags, and so belong into CPPFLAGS, not CFLAGS/CXXFLAGS. It is only accidental that their use in CFLAGS works, because everyone uses CC=gcc, a driver.) IMHO, none of the programs (CC, CXX, etc.) are required to be a a driver program capable of separating compiler options (such as -fPIC or -Wc,-fPIC) from linker options (such as -lfoo or -Wl,-lfoo). Furthermore, I also think that none of CCLD, CXXLD, etc. are required to be an option-separating driver, but merely a program that knows how to link-and-compose a program and transparently add any mandatory but implementation-specific components like crt1.o or, in case of CXXLD, -lstdc++ (GNU) / -lc++ (Clang-based systems).
