libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Ekberg
Subject: RE: MSYS+MSVC for libtool branch-2-0, take 2
Date: Fri, 10 Jun 2005 22:57:33 +0200

Ralf Wildenhues wrote:
> Hi Peter,
> 
> I've tried your patch now, with cygwin and this version:
> 
> | Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077
for 80x86
> | Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
> 
> configured like: CC=cl CXX=cl.
> 
> Notes:
> 
> `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.
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?

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

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?

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

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

Any chance of a more up-to-date -2-0 prerelease soon, so that
I can get a bootstrapped version for free? :-)

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

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

> Other than that, the HEAD convenience archive tests pass with 
> this.  :)
> Libtool's legacy test suite does too much with absolute paths which
> kills my path workaround (a symlink in /tmp to my real $HOME which has
> spaces in its name).
> 
> 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

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.

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

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

Attached is the latest version of the patch.

Cheers,
Peter

(and thanks for the review)

Attachment: msys_msvc-3.patch
Description: msys_msvc-3.patch


reply via email to

[Prev in Thread] Current Thread [Next in Thread]