I agree that the relationship between compiler, linker and OS is problematic. In the OpenJDK build system, we have used the concept of "toolchain", by which we mean (amongst other things) a compiler and a linker working together. For some platforms it's a perfect fit (eg Visual Studio), for others like gcc it's so-so, for yet others (solstudio) it's really bad.
So, we already tacitly assume a specific linker with the gcc toolchain; we have just not made that check explicitly. As I said in a previous email, part of the reason for this switch is to allow --incremental. So for that reason, we must know that the linker supports that option. /Magnus > 24 jan. 2019 kl. 15:48 skrev Martin Buchholz <marti...@google.com>: > > Getting into the business of choosing the linker is big trouble. > > The system default toolchain may have already chosen a linker. > > BFD might be configured to have either bfd ld or gold. > # Handle --enable-gold, --enable-ld. > # --disable-gold [--enable-ld] > # Build only ld. Default option. > # --enable-gold [--enable-ld] > # Build both gold and ld. Install gold as "ld.gold", install ld > # as "ld.bfd" and "ld". > # --enable-gold=default [--enable-ld] > # Build both gold and ld. Install gold as "ld.gold" and "ld", > # install ld as "ld.bfd". > # --enable-gold[=default] --disable-ld > # Build only gold, which is then installed as both "ld.gold" and "ld". > # --enable-gold --enable-ld=default > # Build both gold (installed as "ld.gold") and ld (installed as "ld" > # and ld.bfd). > # In other words, ld is default > > The compiler driver itself may have been configured to choose a linker. > > The system administrator may have used update-alternatives to choose a linker. > > A user might have configured openjdk to use -fuse-ld=... (we do this!) > How do you resolve the conflict? > > There's evidence that lld is even faster than gold. The Internet says, > """Liked linking 3x faster with gold? Link 10x faster with lld!""" > so hardcoding gold might be a regression! > > So ... -fuse-ld is a flag that is perfect for a local wrapper around > configure that is __not__ part of openjdk (we do this!)
