libtool reloadable object files versus multilib

[David Edelsohn]

Summary:

	libtool uses "ld -r" to create temporary reloadable object files,
which breaks in a multilib environment where one needs invoke the linker
with an "emulation" option instead of the default.


	On AIX I tried to bootstrap GCC in an NFS directory that gets
converted into a very long set of subdirectories for the actual mount
point.  This appears to be causing ltconfig to discover a maximum command
length that is half the normal value.  This shorter value causes the build
of libf2c to generate a temporary reloadable object file because creating
the shared library directly would create too long a command line.

	When configuring libtool for target libraries, the correct
multilib commandline for CC is created, but the reloadable object file is
generated with:

reload_flag=" -r"
reload_cmds="\$LD\$reload_flag -o \$output\$reload_objs"

where LD is defined as "ld" in all target multilib libtool
configurations.  Generating the reloadable object invokes LD directly, not
using CC to invoke the linker.

On AIX, at least, invoking "ld" without the emulation option matching the
object files fails.  Result: Bootstrap failure.

	Two problems:

1) the fragile computation of maximum command length

2) multilib target library not defining multilib-specific LD in libtool,
which may be difficult or impossible because libtool does not necessarily
know options for target linker, i.e., it may not be GNU ld.

One could hard code the limit to the correct value to get around the
immediate problem, but that only fixes the symptom for this particular
failure, not the underlying problem of invoking "ld" without the correct
options.

	Also, I believe this is a problem for bi-arch GNU/Linux systems if
someone generates a libtool link line longer than ARG_MAX - ENVIRONMENT,
assuming the libtool command length value is not calculated too small.

	Any ideas on how to fix these problems?

Thanks, David