RE: MSYS+MSVC for libtool branch-2-0, take 7

[Peter Ekberg]

Ralf Wildenhues wrote:
> > In the patch, the archive built to get the symbols is not used
> > for anything but getting the symbols. But two features in lib
> > are used that are not supported by ar. Namely that lib can take
> > a command file with inputs (@cmdfile notation) so that the
> > command line length is short, and the fact that the path is indeed
> > stored in the archive, so that object file renaming is not needed
> > for this temporary symbol extracting archive.
> 
> Can we get in the position that both might be used ("lib" in older,
> already installed libs, "ar" for a newer package the user is about
> to link)?  I believe not, but need to check so.
> 
> > So, for this, it is not really needed to have AR=lib. It is perhaps
> > cleaner to look up "lib" (or "link -lib") and use that 
> without looking
> > at $AR at all, since ar does not have the required functionality.
> 
> This is precisely what kind of bugs me.  We don't want to prevent
> use of a GNU tool here.

I don't follow you here. Why is it required that you can use a
GNU tool? When you are using MSVC, you are using the Microsoft
Linker, so it's not like a new dependency is added. lib is just
a synonym for "link -lib". So two features of the Microsoft
linker (command files and paths being stored in archives) are
used to overcome the lack of another feature (reloadable object
files).

Yes, I know that some of the tests in the patch test for MSVC
(or rather, not gcc), when it should be tests for features
of the specific tool used, one of the reasons I have not asked
for commit yet...

Any suggestion on how to clean that up?

> > When doing the actual linking, a command file is again used,
> > so it's similar to the linker script approach taken with gnu ld.
> > (except that the linker script isn't used with gnu ld when the
> > command line length is overrun in the extract symbol step, in
> > that case the reloadable object file is used for both symbol
> > extraction and actual link)
> 
> OK.

Cheers,
Peter