RE: MSYS+MSVC for libtool branch-2-0

[Peter Ekberg]

Ralf Wildenhues wrote:

> Hi Peter,
> 
> * Peter Ekberg wrote on Tue, May 24, 2005 at 11:51:08PM CEST:
> > 
> > I started an attempt to support the MSVC compiler natively
> 
> Cool!  I started looking at this a couple of weeks ago, but 
> have had no
> time to pick up on it again.  I have made a couple of notes, though,
> which I can post sometime.
> 
> > (w/o the cccl script, which I haven't tried to be honest)
> > and using MSYS to drive the scripting.
> 
> OK.  If we tune up MSVC support in Libtool, we should do it right,
> meaning that we should (at least allow for) different MSVC 
> versions and
> probably either one of CYGWIN or MSYS scripting.  And we 
> should probably
> also allow to use cccl, or even require it if that makes life a lot
> easier.  (We should also allow for support for other 
> compilers on win32,
> but I for one was not smart enough for the Borland online sheet.)

Yes, all reasonable.

> Which MSVC version do you use?  By looking at whatever rough

cl outputs:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for
80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

The one that came with Visual Studio 6. Old, I know...

> support there is (was once installed) in Libtool, that pertains to an
> old version.  Unfortunately, I don't have access to such an 
> old version.
> If we can get hold of it, though, I think we should not kill 
> its support
> by changing the libtool.m4 settings (unless they are broken, that is).

Well, since the stuff seemed broken anyway I figured it was time
to start fresh.

One problem that made me think it was broken was that "lib /OUT..."
seemed to be a real problem, I had to change it to "lib -OUT..." to
not confuse libtool into thinking that the /OUT... thing was a path.
Does anybody even know what is supposed to work? I.e. what
functionallity should be kept intact?

> > With this (rough) patch I am able to build and use shared libraries
> > (libs and modules) and convenience libraries. I haven't 
> tested static
> > libs (I haven't gone through the pain of bootstraping on 
> Cygwin, which
> > would require building some current autotools from scratch.)
> 
> I have started working on old libs.  AFAICS, the `LIB' program has
> been replaced with `LINK -lib' in one of the newer MSVC versions.

My LINK.EXE does not support the -lib option, so it must be something
added in .Net or later...

> I also believe that (at least the newer) archiver encodes 
> paths into the
> objects, so we might have to move/copy objects around before creating
> it.  OTOH, we could also think of supporting MSYS `ar' while using 
> 
> > I realize that this is not likely an acceptable patch.
> 
> No.  :)
> But it's a start.  I'll try it out when I have time (could be 
> a while).
> Generally, you should avoid putting system-dependent stuff 
> into ltmain.
> For example, `LIB' and tests for $host should be parameterized; yes,
> there are quite a few cases where that is not done currently, but we
> should try to minimize any further regressing to that end.

I don't understand what you mean by parameterized here?

> > Perhaps libname_spec should be just $name on MSVC? Instead
> > of doing that, I added a second very similar loop in
> > ltmain.sh, but that might be a cludge?
> 
> Need to look at this closer.

What I'm referring to is that the libs supplied with MSVC
are named like this:
ACLCLS.LIB
ACTIVEDS.LIB
ADDRLKUP.LIB
ADME.LIB
ADOID.LIB
etc, but with the current version of the patch, any libs that
are created are named lib$name{.lib,.dll} (as they are in MinGW)
This causes problems (solved by the second loop) when searching
for libs to link with when building dependent stuff as some
libs are named libfoo.lib and others are named just bar.lib.

> > This patch was taken from a libtoolized project (I wrote
> > the patch), I think I converted all [...] in its ltmain.sh
> > to [[...]] when I patched ltmain.m4sh in libtool branch-2-0,
> > but I'm not 100% sure as I didn't actually test the result
> > (due to the above bootstrap troubles).
> 
> I don't understand this paragraph.

It was just background, to further emphasize that I have not
actually tested _this_ patch, my working version is in the
project and I just did my best when generating the diff
against libtool branch-2-0.

> > But I'd very much appreciate comments on the general
> > approach, so that I know if I should just throw the whole
> > thing in the bin now rather than later if I'm way off...
> 
> Stuff like cleaning path specs (drive letters etc) should probably be
> factored out.

Yes...

> At the moment, I cannot tell you much more yet, but I'd like to thank
> you for starting to work on this; it's much needed, and I do realize
> that in the end we might have to live with some ugliness in this
> respect.

No rush, it's been sitting on my drive for quite long anyway...

> It might be a good idea to collect information about msvc in some
> document.

Yes...

> > I configure the libtoolized project with
> > 
> > .../configure CC="cl -MD" LDFLAGS=-L/msvc/lib
> > 
> > Where MSYS has a mount so that /msvc points to the MSVC folder
> > (typically "C:\Program Files\Microsoft Visual Studio\VC98"
> > or something similar)
> 
> Yeah, it might be necessary to work around all the `white 
> space in path' issues as well...

That was the general idea, yes :-)
But it is in fact quite ugly. At one point I use the paths
in $LIB to locate the libs provided with the toolchain, and
at one point LDFLAGS is required to also point them out.
Hmm, come to think about it, it might not be needed to look
in $LIB when LDFLAGS is used like this? But, I believe that
the correct thing to do is to look in $LIB, as this is what
the toolchain is doing. Damn spaces.

Cheers,
Peter