only tested this under 3.3.4/4.0 but it seems to go back a few years. it will pass -dynamic-linker to cc1 also. and seems to have been noticed before http://gcc.gnu.org/ml/gcc/2000-10/msg00437.html from what i can tell it suppresses the passing of -dynamic-linker to ld (ignoring that it gets sent to cc1.) To use an alternative dynamic-linker you can do something like cd /tmp cp /lib/ld-linux.so.2 . echo 'main(){}' >foo.c gcc -v -dynamic-linker -Wl,-dynamic-linker /tmp/ld-linux.so.2 foo.c readelf -l a.out | grep -A1 INTERP not sure whether this particular usage of it should be limited to a custom spec with -specs=... but i expected it to accept an option that overrides the default -dynamic-linker sent to ld
Confirmed.
I was discussing this with Joseph Myers earlier today. He said "There isn't meant to be a GCC driver -dynamic-linker option." and pointed at https://gcc.gnu.org/ml/gcc-patches/2010-12/msg00194.html but apparently some backends have broken again since then: arm/freebsd.h c6x/uclinux-elf.h rs6000/freebsd64.h I found through experimentation that nios2-linux-gnu-gcc accepts -dynamic-linker as a link option without error, but totally ignores it. Joseph's explanation is that the driver accepts it as -d<letters> but doesn't check the <letters>. If you try compiling with that option and not just linking, gcc does diagnose that the <letters> are invalid. Anyway, there is no documentation bug here.
(In reply to sandra from comment #2) > > Anyway, there is no documentation bug here. OK, removing that part from the title
(In reply to sandra from comment #2) > I was discussing this with Joseph Myers earlier today. He said "There isn't > meant to be a GCC driver -dynamic-linker option." and pointed at > > https://gcc.gnu.org/ml/gcc-patches/2010-12/msg00194.html > > but apparently some backends have broken again since then: > arm/freebsd.h c6x/uclinux-elf.h rs6000/freebsd64.h > > I found through experimentation that nios2-linux-gnu-gcc accepts > -dynamic-linker as a link option without error, but totally ignores it. > Joseph's explanation is that the driver accepts it as -d<letters> but > doesn't check the <letters>. If you try compiling with that option and not > just linking, gcc does diagnose that the <letters> are invalid. > ...so it seems to me, then, that the "driver" component would make more sense here than "target"