Patching autoconf to support static binutils?

[Bryan Ischo <bryan at ischo dot com>]

Hello.  I am trying to figure out how to build a statically linked 
version of binutils (starting with binutils source version 2.21.1).  I 
have found some old discussions of this topic via search results, but 
there was never any real resolution to this issue as far as I can tell.

A while ago people were suggesting that playing with LDFLAGS during the 
appropriate stage of the configure/make configure-host/make sequence 
could do the trick, but if these instructions ever worked, they don't 
work any more.

I have spent hours trying to find the magic incantations that would make 
this work, but have failed, and I believe that there are in fact no 
magic incantations that will work in the current binutils configure 
script and makefiles.

The basic problem, as far as I can tell, is that some Makefiles within 
binutils use the compiler to link executables, and some Makefiles use 
libtool to do the same.  The option that would need to be passed to the 
compiler (ostensibly being gcc, which accepts the -static option) are 
different than that which would need to be passed to libtool 
(-all-static); but the environment variable that can be used for 
specifing linker flags to the compiler, LDFLAGS, is passed to both the 
compiler and libtool.

Does it seem right that LDFLAGS would be passed to libtool?  It doesn't 
seem right to me, since LDFLAGS suggest being used for the 'ld' program, 
and that program doesn't have compatible arguments with libtool.  It 
would seem cleaner to use LIBTOOLFLAGS for this purpose, however, 
LIBTOOLFLAGS is used for several different 'flavors' of libtool 
invocation, some of which do not accept -all-static (e.g. libtool 
--mode=compile).  In fact the logical conclusion of this train of 
thought would seem to be that there should be a separate LIBTOOLFLAGS 
variable in use for each of the modes of libtool invocation, e.g. 
LIBTOOLFLAGS_LINK, LIBTOOLFLAGS_COMPILE, etc, and additionally, as was 
already mentioned, there is no way to pass linker arguments just to 
invocations of the compiler without also passing those flags to libtool.

I believe that the following *might* be sufficient to allow static 
binutils to be built:

1) Make sure that all invocations of the compiler used as a linker use 
only LDFLAGS (not LIBTOOLFLAGS)
2) Make sure that all invocations of libtool use the appropriate flavor 
of the LIBTOOLFLAGS (i.e. LIBTOOLFLAGS_LINK, LIBTOOLFLAGS_COMPILE, etc), 
and do NOT use LDFLAGS
3) Specify LDFLAGS=-static and LIBTOOLFLAGS_LINK=-all-static when 
running make (and possibly when running configure)

Another alternative might be to encode the users' wishes more explicitly 
in a configure argument, something like --enable-static-executables, 
which would turn on Makefile variables that have the same effect as (1) 
and (2) above, without requiring that the user play with environment 
variables when executing configure and/or make.  However, for this 
option, I am not clear about how this configuration option gets 
specified; does it only need to be specified in the top-level binutils 
configure, or would it need to be present in each configure of each 
sub-directory?  Would this option be 'inherited' in some way in the 
sub-directories (possibly via Makefile variables), or would it need to 
be encoded individually in each sub-directory configure script?  And if 
so, would it naturally be specified to executions of configure in 
sub-directories by the main configure script?  I'm afraid that I am 
pretty unfamiliar with autoconf and mostly go on what I can grok by 
reading the scripts, and these aspects are not obvious to me.  Forgive 
me for not RTFA, but the less I know about autoconf the happier I will 
be, I believe, so I'd rather rely on others' expertise in the tool than 
acquiring such expertise myself :)

I'm happy to do the work to make this happen and to submit patches, but 
I'd like some direction to ensure that I implement a solution that would 
be acceptable to the binutils maintainers.

Thanks, and best wishes,
Bryan