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

[Ralf Wildenhues]

* Peter Ekberg wrote on Tue, Aug 09, 2005 at 02:40:36PM CEST:
> Ralf Wildenhues wrote:
> > 
> > I believe your patch and Keith's proposed patch for "-sobase" interact
> > (i.e., -sobase support would have to be forward ported into 
> > your patch.)
> 
> Seems like a simple s/libname/sobase_name/ but someone has to
> remember to do it...

Kind of like that.  Plus maybe run a test.

> > > The "lib as archiver" patch is still needed though, as
> > > this seems like the easiest way to get at all symbols
> > > from a library with so many objects that the max command
> > > line length is exceeded (pdemo.test), as the Microsoft
> > > linker does not seem to support reloadable objects.
> > > You *could* extract symbols from one object at a time
> > > and merge the outcome, but I think that would be a much
> > > bigger change.
> > 
> > I'm still not convinced that we don't end up having more trouble with
> > paths encoded into the archive.  But since "lib" does that anyway, I
> > guess we might just have to care for all bad cases (see that we don't
> > encode paths, but expect encoded paths in other libs).  
> > 
> > I must admit I haven't checked your patch closely w.r.t this yet.
> 
> 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.

> 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,
Ralf