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

[Peter Ekberg]

Ralf Wildenhues wrote:
> Hi Peter,
> 
> * Peter Ekberg wrote on Fri, Jun 10, 2005 at 10:57:33PM CEST:
> > Ralf Wildenhues wrote:
> > > 
> > > `link -LIB' can be a problem if the cygwin `link' (to create 
> > > hard links)
> > > comes before the win32 paths.  `LIB' works here.
> > 
> > I have a fix for that in the attached patch, where you can
> > override by setting MSLINK to the appropriate executable.
> 
> Hmm.  Can't we just move all this stuff to the section in libtool.m4
> where $AR is set?  It already allows user override (by setting AR
> appropriately during configure).  We could test whether `ar' 
> works, and
> if not, whether either one of `link -lib' or `lib' work.
> (This is where we then should also test whether `ar' 
> understands the `S'
> option, and adjust archive_cmds/postinstall_cmds accordingly, 
> but that's
> totally unrelated to this patch.)

Of course, reuse the AR variable. *smacks forehead*

Looking closer reveals a couple of problems though...
$AR is used in three ways if I read it correctly:
1. "$AR $AR_FLAGS archive files..." to create archives.
2. "$AR x archive" to extract archives.
3. "$AR t archive" to list archive content.

I see no way to set AR and AR_FLAGS so that 1. is expanded
to "lib -OUT:archive files..." as is needed here (-OUT:
has to be prepended to the archive name without space).

"$AR x archive" has to be hidden in some construct, as there is
the problem that there is no way to extract all members from
a MSVC .lib in one go, you have to loop over the archived
files and extract them one by one.

3 is easy to solve, just introduce $AR_LFLAGS and set it to
"t" by default and to "-NOLOGO -LIST" for MSVC.

I have made an attempt to solve these issues in
msys_msvc-4.patch.

(It turns out that both ar and lib works as the archiver
 since MSVC does not actually see the generated archives.
 ar is selected by default, so you have to specify AR=lib
 or AR="link -lib" to get the Microsoft tool.)

There are some more instances where the space after $AR_FLAGS
should be removed, but those are system specific and I think
it's safe to assume the archiver to be ar on those systems.
So, in order to keep the patch size down I left them as is.

> > I have the feeling that some of this work should perhaps
> > be in autoconf or automake, but I also have the feeling
> > that it is not as easy to warp the arguments as needed
> > to suit MSVC?
> 
> Are we heading back towards `cccl'?  :)

Right, better not go there... :-)

> To be honest: if the environment variables can be used to circumvent
> problems with, e.g., configure (such as backslashes, spaces in path),
> then we should be happy that they exist and not bother any more.  What
> do you think?

It will probably be very messy to make MSVC work with autoconf
without cccl (or some other wrapper script). Libtool should be
doable.

> > > After working around these, the next failure is when 
> linking libltdl:
> > > 
> > > | libltdl_la-ltdl.obj : error LNK2019: unresolved external 
> > > symbol _lt_libltdl_LTX_preloaded_symbols referenced in 
> > > function _lt_dlinit.
> > > | .libs/ltdl-6.dll : fatal error LNK1120: 1 unresolved externals
> > 
> > Haven't tried libltdl, I do not depend on it for the project
> > I'm targeting and I have a hard time bootstrapping libtool
> > so I haven't tried the testsuite myself.
> 
> Is that only because you'd need recent Autoconf/Automake (from CVS)?

Yes. That, and I'm unsure of if there are any patches needed for
Cygwin (which I guess I would be using to bootstrap) and since
Cygwin has a strange side-by-side installation of autotools.

> If not: show the specific problems, we can try to fix them then.
> Did you try to bootstrap on mingw?

No, I tried bootstrapping with Cygwin and ac 2.59 and it of
course didn't work...

> > Any chance of a more up-to-date -2-0 prerelease soon, so that
> > I can get a bootstrapped version for free? :-)
> 
> Well, I'd really like to have the pending patches and Gary's fix for
> "the last big bug" in the next prerelease.  Dunno when Gary has time
> again, though (I'll be gone next week, by the way).
> 
> I could build a tarball for you, but if you intend to change knobs and
> adjust things in libtool.m4, it'll not be of much help unless you can
> bootstrap for yourself.

I guess I better find some way to bootstrap myself then. :-)

> > > The `mv' command in this line
> > > | +      _LT_TAGVAR(archive_cmds, $1)='$CC -o $lib $libobjs 
> > > $compiler_flags `$ECHO "X$deplibs" | $Xsed -e '\''s/ 
> > > -lc$//'\''` -link -dll~linknames=~mv .libs/${libname}`$ECHO 
> > > "X${release}" | $Xsed -e +s/[.]/-/g`${versuffix}.lib 
> > > .libs/${libname}.lib'
> > > 
> > > is also broken w.r.t lib name.
> > 
> > I don't see what you mean here. It does what I intend it to do,
> > it renames the import lib to not have a version number. Why
> > is that a problem? It matches the content of the .la file.
> 
> I didn't keep a note on this due to time constraints, sorry.  Was a
> problem with the paths again, I think (i.e., correct quoting).

Well, I didn't even try to solve problems caused by spaces in paths,
I used my little -L/msvc/lib workaround instead.

> > Things that should probably be worked on:
> > 
> > - Install dlls in ../bin/foo.dll, just like they are for MinGW
> >   and Cygwin. The generated .la are wrong as is.
> 
> ACK.

Fixed in msys_msvc-4.patch.

> > - Add paths given with -L to the LIB variable so that the linker
> >   actually sees them. This should be done after converting them
> >   to win32 paths, which is easy on Cygwin and harder on MSYS.
> 
> ACK.

Maybe not so hard on MSYS after all, how about:
win32=$(cmd \\/C echo "$unix " | sed -e "s/\"\(.*\) \" /\1/")

(cmd is not directly CMD.EXE, but a shell script provided by MSYS
that invokes $COMSPEC. One question is how portable /C is as an
option to $COMSPEC? I would guess that /C works for all command
interpreters from Microsoft, but I'm unsure about others...)

Also, how portable is it to assume that the sed matcher is greedy,
like GNU sed is documented to be? But assuming GNU sed on MSYS
should be fairly safe. Or?

Anyway I made -L options visible to the linker using a variant
of the above in msys_msvc-4.patch.

> > - libtool at some point thinks /mingw/bin/ld is the linker and
> >   uses that to deduce stuff, perhaps other configure checks are
> >   also a problematic, I haven't looked closely since it works
> >   for me.
> 
> Show `./libtool --config'.  In order to use only the msvc tools, it
> might be necessary to configure somehow like
>   CC=cl CXX=cl LD=link AR=link\ -lib
> iff the respective mingw/cygwin tools are available as well. 
> I regard this as a feature, BTW, not a bug.
> 
> It'll likely be some time before I can look at your patch again.
> It's good to see that it's getting smaller, though.  :)
> 
> Another couple of hints: if you intend to work on the path conversion
> thing, please separate that out into a shell function if at all
> possible.  (And have a reasonably fast default path so that 
> not everyone
> has to suffer from it.)

One more thing that perhaps should be handled is that the content
of the LIB variable should be added to sys_lib_search_path (or
some other variable?) This would require converting paths from
win32 style to unix style, which again is easy on Cygwin, but
much harder on MinGW (the workaround above does not work).
But I would not consider this a showstopper. The user can always
add the needed paths with -L as I have done.

PS. With msys_msvc-4.patch I configure with
./configure CC="cl -MD" AR=lib LDFLAGS=-L/msvc/lib

I also have this line in my msys /etc/fstab
C:/PROGRA~1/MICROS~4/VC98 /msvc

PPS. The patch does not solve as many issus on Cygwin as it
does on MSYS. Therefore, please don't judge it by its
performance on Cygwin. You have to walk before you can run...

PPPS. _LT_COMPILER_OPTION is very nice in that it is good at
detecting options that are not supported, even though the dang
MSVC compiler only prints a warning and ignores the unknown
option. Any chance of seeing that in autoconf, so that -g is
not falsely being detected as being usable for MSVC?

Is there any particular risk involved with using the above macro
in the project configure.ac? I mean, how likely is it that it
will go away or change interface? (the leading underscore looks
like a warning)

Cheers,
Peter

msys_msvc-4.patch
Description: msys_msvc-4.patch