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

[Ralf Wildenhues]

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.)

> I decided to not use LINK, since link.exe looks in the
> LINK veriable for extra options.
> 
> Should we therefore keep track of LINK?  Maybe that's an autoconf
> question?

You mean save its contents at configure time?  Probably not.
We don't keep track of things like COMPILER_PATH or GCC_EXEC_PREFIX
either.  And yes, that would probably be an Autoconf question.

> (The same is true for the CL and _CL_ variables used in a
> similar maner by cl.exe.)

Similar answer.  Unless there turn out to be problems.

> 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'?  :)
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?

> > `LIB -EXTRACT' needs Windows paths for lib and extraction directory.
> > With cygwin, `cygpath -w' works.  But the result needs to be properly
> > quoted for func_show_eval, if that is to be used.
> 
> On MSYS, the paths does not need to be converted. They are
> automatically converted for arguments to executables outside
> the MSYS tree or something like that (they are assumed to be
> win32 executables expecting win32 paths).

Ah, ok.

> > 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)?
If not: show the specific problems, we can try to fix them then.
Did you try to bootstrap on mingw?

> 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.

> > because that thing is called `_lt_ltdl_LTX_preloaded_symbols' now that
> > libname_spec changed.  This is probably a bug in our build which
> > hardwires 
> >   libltdl_la_CPPFLAGS = -DLTDLOPEN=libltdl
> > but OTOH I'm not convinced yet that the libname_spec change 
> > is correct.
> 
> I think I have convinced myself that changing libname_spec is
> the right thing to do. I find that I can remove some of the really
> ugly stuff from the patch when I do that.

OK.  Let's keep it like that for now 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).

> > How do I get sensible information about what's in a dll (except trying
> > to link against it)?  (I really know little about win32.)
> 
> http://www.dependencywalker.com/ (aka depends.exe)
> dumpbin.exe is a command line tool

Thanks.

> 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.

> - 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.

> - 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.)

Cheers,
Ralf