RE: libtool 2-0-lib-as-archiver.patch

[Peter Ekberg]

Peter O'Gorman wrote:
> Peter Ekberg wrote:
> | Hi!
> |
> | 2005-07-21  Peter Ekberg  <address@hidden>
> |
> |     * Makefile.am: Export user selection of archiver to the
> |     testsuite.
> |     * config/ltmain.m4sh (func_extract_an_archive): Handle case
> |     where the archiver must extract members one by one.
> |     * m4/libtool.m4 (_LT_PROG_AR): New function that looks for
> |     Microsoft lib.exe and Microsoft link.exe after failing to find
> |     ar. Then checks what interface the archiver expects.
> |     (_LT_CMD_OLD_ARCHIVE): Make use of _LT_PROG_AR.
> |     (_LT_CMD_OLD_ARCHIVE, _LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG):
> |     Support archivers that do not like a space between $AR_FLAGS
> |     and the library name.
> 
> Thanks for pointing me to Ralf's comments on this. If I may 
> make a suggestion:
> 
> Have a shell function in ltmain.m4sh that takes all the usual 
> ar arguments and feeds them to lib.exe appropriately. Just wrap
> lib.exe in an ar like interface. In libtool.m4 substitute an
> lt_AR=ar or lt_AR=func_win_ar depending on the result of checks
> and always use lt_AR in ltmain.
> 
> Is this too much trouble? It would avoid trouble with the 
> separator etc. and using lt_AR would be internal to libtool.

It's not too much trouble, but I have two 'issues'.

1. What about the automake rule to use $(AR) in the demo-deplibs
test? I don't want a solution that's a dead end in that regard.
Are you saying that automake should support this "weird"
archiver independently of libtool? I don't think that's possible
without some external script (yikes).

Perhaps what is needed is a libtool interface to enable
automake to do what it wants to do in that rule (update an
individual object in the archive without recreating the whole
archive?) by using libtool instead of using $(AR) directly.
Perhaps that's a too big of a performance hit? But maybe
this could be enabled only if automake was used in
conjunction with libtool and if the project is configured
with an archiver that is not "ar compatible" or POSIX or
whatever.

2. The Microsoft linker does not support (at least not to my
knowledge) reloadable objects (ld -r), which are needed in
order to find all symbols that should be exported from a
shared lib when the command line length is limited (tested
by pdemo). The way I have solved this in the msys+msvc patch
is to build an archive (instead of a gigantic object file)
using lib.exe, and in doing so I use a "command file". I then
find out what symbols are available in the temporary archive,
and use those symbols as input in the shared lib creation.

Maybe issue 2 is orthogonal to your suggestion, but it's
certainly tied to what features (command file, stores paths
in the archive to prevent duplicate filenames to clash) the
archiver supports...

(BTW, thanks for all the Okays!)

Cheers,
Peter