On 04/04/2010 20:08, Joseph S. Myers wrote:
> I think extracting compiler/linker *internal commands* and trying to
> process or adapt them is inherently fragile and liable to break whenever
> new compiler/linker options (internal or otherwise) are added. If
> possible the aim should be to work out user-friendly interfaces for direct
> GCC users and have libtool use the same interfaces while expecting how
> they are implemented to change over time. Interfaces by which GCC does
> things (e.g. link a shared library for the multilib implied by the given
> options) seem safer than interfaces where it gives information (if you ask
> it for directories and lists of libraries, you might then find that
> interface inadequate for handling per-library choice of static or shared
> libraries, for example).
Essentially, libtool needs to know about gcc's specs, and what they do to a
command-line. ISTM that using "-###" and the appropriate language-dependent
driver should do most things that libtool needs, but maybe we should add an
option to the driver that turns it into a command-line driven arbitrary specs
processor of some kind. Ralf, might that help the situation, if you could
pass arbitrary command-lines to the driver and have it report back the results
of spec processing in some controlled and parseable fashion?
cheers,
DaveK
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
