libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Command file interface to archiver


From: Ralf Wildenhues
Subject: Re: Command file interface to archiver
Date: Tue, 14 Feb 2006 14:24:35 +0100
User-agent: Mutt/1.5.11

* Peter Ekberg wrote on Tue, Feb 14, 2006 at 11:19:25AM CET:
> 
> > | +   case $host_os/$with_gcc in
> > | +   mingw*/no | mingw*/ | cygwin*/no | cygwin*/)
> > | +     # Assume MSVC _and_ lib archiver interface...
> > | +     func_echo "using command file archive linking..."
> > | +     for obj in $oldobjs; do
> > | +       $ECHO \""$obj"\"
> > | +     done > $output_objdir/$libname.libcmd
> > | +     save_oldobjs="$oldobjs"
> > | +     oldobjs=" @$output_objdir/$libname.libcmd"
> > | +     eval cmds=\"\$old_archive_cmds\"
> > | +     oldobjs="$save_oldobjs"
> > | +     ;;
*snip*
> > 
> > I don't like this big hunk yet.  It's pretty invasive, it assumes
> > | +     # Assume MSVC _and_ lib archiver interface...
> > 
> > and there is room for other systems to improve, too.
> > Side note: 
> > | +     if test "X$oldobjs" = "X" ; then
> > 
> > could be `test -z "$oldobjs"'.
> 
> Huh? What is invasive about it? Yes, the hunk is large, but the bulk
> of it is just an indentation change. The meat is 8 lines of code
> specific for MSVC.

Agreed, "invasive" was an over-reaction.  It's a regression for non-gcc
non-MSVC compilers on w32, though.

> Agreed, the test should be done in libtool.m4 and be propagated to
> ltmain through some variable,

Yes.  So we can support PGI/w32 as well, for example.

> and other systems could perhaps
> benefit from a command file to the archiver as well.

Right.  Not that I could name such a system ATM, though.

> You did not like the other command file interface, can you please
> specify this one to your liking? Please ;-)

You mean the file_list_spec one?  I could tell you exactly how I'd like
that, I just never got around to actually implementing it:

- Create variable linker_list_cmds.
For GNU ld,
  linker_list_cmds='
    echo "INPUT (" >$output~
    for obj in $save_libobjs; do $ECHO "\"$obj\""; done >>$output~
    echo ")" >$output'
For AIX ld,
  linker_list_cmds='
    for obj in $save_libobjs; do $ECHO "$obj"; done >$output'
For recent (unreleased) GCC (given that we use it for linking)
and for MSVC,
  use a response file.

- Think about a better input interface to linker_list_cmds than
  `$save_libobjs'.  Adjust above accordingly.
- Better name?  Maybe archive_list_cmds?  Or *_script_cmds?
  Maybe the latter implies support for generic linker scripts?
  Maybe also we _could_ support something more generic..
- Check that all variables are quoted correctly for their usage
  (e.g., $ECHO may not be eval'ed too often).
- Write a good test.
- Actually make sure that, during the execution of above, we _never_
  ever build a command line for an external program that may be too
  long.
- Document linker_list_cmds in libtool.texi.

This is post-2.0 stuff.

> I have found no way to do piecewise linking using Microsoft link,
> so AFAIK the command file is desperately needed here, and I did
> not find a better way to add it, sorry.

Sure.  Probably similar to above, old_archive_list_cmds would be ok.
Or a better name.  :-)

> Comment to side note: that is just reindented old code, so don't
> blame me :-)

Sure.  No need to feel blamed, not for this particular piece of code nor
any other.  I'm just commenting what I see, I may even be criticising
code I wrote myself once.  Making me aware of issues where I contradict
myself is always good.  ;)

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]