On Wed, Aug 19, 2015 at 01:30:12PM +0930, Alan Modra wrote: > On Tue, Aug 18, 2015 at 08:58:43PM -0400, Rich Felker wrote: > > I've updated the patch to cover the changes needed for all the > > elf??-*.c target files (lots of code duplication already there), skip > > the clearing of command_line.interpreter, and based it on current git > > master with your output_type changes. > > This is OK to commit with a suitable ChangeLog. I think a separate ld > option is best too, because historically -static and its aliases > -Bstatic, -dn, -non_shared really are about what type of libraries are > accepted rather than choosing linker output type.
I see good arguments for both ways, and H.J. Lu seems to have switched sides midway if I understand correctly. Using the existing -static option seems nice in that it avoids the need for GCC to know whether ld supports --no-dynamic-linker, but GCC needs to know the right crt file to link anyway. And linking the rcrt1.o file with self-relocation code would be wrong if an external dynamic linker were used. So I don't think this really simplifies the GCC-side problem at all. On the other hand, having a dedicated option also makes other neat stuff possible: for instance, it's possible to do dynamic linking, but with the dynamic linker itself (or at least the bootstrap part of it) linked into the application. This is a potentially interesting setup when you don't want to depend on a fixed dynamic-linker path; the program could instead to an rpath-$ORIGIN style search for its dynamic linker and libs. I don't have any plans to implement such a thing right now, but it's nice to have the option to do so. Overloading -static would not allow this, or at least not easily, since it would suppress linking shared libraries unless you tweak the order perfectly. So, my mild preference is to stick with the way I've done it in the patch, using --no-dynamic-linker (or a different name if anyone wants to change the name). Rich
