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

[Ralf Wildenhues]

Hi Peter,

* Peter Ekberg wrote on Fri, Jul 22, 2005 at 09:37:47AM CEST:
> 
> I'm back with another gigantic mail. Sorry about that,
> but this time I've tried to keep some structure.

Thanks a lot for the overview.

I have a couple of comments for stuff you have not split out yet,
see below (and a couple of issues I have not looked at yet; but I
did not want to wait even longer with this mail).

*snip*
> tagdemo-*.test
> --------------
> 
> Apart from a bunch of shared lib description variables,
> I have also made a dirty change. Without it C++ fails
> miserably for MSVC. cl.exe only detects .cpp and
> .cxx files as C++ source files. If you have source
> files e.g. foo.cc and bar.cc, you have to say:
>   cl -Tp foo.cc -Tp bar.cc
> or
>   cl -Tpfoo.cc -Tpbar.cc
> and so on for each file that is a C++ source file.
> Otherwise, cl simply forwards the file to the linker...
> 
> So, I made this dirty change:
> ac_ext=cpp
> instead of
> ac_ext=cc
> 
> (the same is true for C source files, which has to
>  be named .c, or you have to use the -Tc option.
>  But who does not name C source files .c?)

Hmm, I thought there were a non-position dependent option for cl.exe to
make it compile C code..  *time passes* this version:
| Version 13.10.3077 for 80x86

states:
| /Tc<source file> compile file as .c
| /Tp<source file> compile file as .cpp
| /TC compile all files as .c
| /TP compile all files as .cpp

so you should be fine with CC='cl -TC'.  Does that work with your
version as well?

Still, we should think of changing ac_ext so it works out of the box.
Doesn't this need a patch against Autoconf?

> With the above dirty change, it works.
> 
> Also, since MSVC uses @ and ? in C++ symbols (it also
> uses @ for __fastcall C symbols for that matter) I'm
> unsure of how ltdlopen (and preopen) will work...

Later.

> * Support for NM="dumpbin -symbols" as the name lister.

Nice!

> Testsuite
> =========
> 
> Here's the output from make check, when configured with:
> configure CC=cl CFLAGS=-MD CXX=cl CXXFLAGS=-MD LD=link AR=lib STRIP=:
> NM="dumpbin -symbols" F77=:
> 
> This is my environment:

Could you be bothered to run the new test suite as well for this
environment?
  make check TESTS=
(adding TESTSUITE_FLAGS="-v" or also "-d" comes in handy at times, but
the autotest test suite saves a lot of interesting state by default.)

Show testsuite.log and whatever else you deem interesting.


*snip*
> demo-hardcode
> -------------
> 
> After changing the test to invoke
> $(LIBTOOL) --tag=CC --mode=link $(CC) etc
> instead of just
> $(CC) etc
> I get this output near the end:
> 
> ------8<------
> demo-hardcode.test: ===  Finding libtool.m4's guesses at hardcoding
> values
> = Searching for hardcoded library directories in each program
> .libs was hardcoded in `hc-direct', which fooled libtool
> .libs was hardcoded in `hc-libflag', as libtool expected
> `hc-libpath' was not linked properly, as libtool expected
> .libs was hardcoded in `hc-minusL', which fooled libtool
> FAIL: tests/demo-hardcode.test
> ------8<------
> 
> Various variables from the generated libtool script:
> hardcode_libdir_flag_spec=" "
> hardcode_libdir_flag_spec_ld=""
> hardcode_libdir_separator=""
> hardcode_direct=no
> hardcode_minus_L=no
> hardcode_shlibpath_var=unsupported
> hardcode_automatic=no
> 
> With the above change the test scans the wrapper scripts for
> the path, where it should have scanned the binaries. The change
> to use libtool to link the binaries also breaks the test for
> MinGW and Cygwin...
> 
> The problem here is that you can't use $CC directly from the
> Makefile, you have to wrap it in the magic provided by
> libtool (or revert to the cccl script), but the test isn't
> written to handle linking with libtool, and I don't know
> how to change it so that it does.

I don't understand the whole above stuff (but have not looked at it in
detail yet).  Posting the test output could help, thank you.

> Wishlist
> ========
> 
> * Find a way to eliminate objdump, the only remaining
>   required tool from binutils. If that is done, it
>   should be possible to just install MSYS and GNU make
>   to use MSVC with libtool.

AFAICS objdump is needed in 2 places: to test for the right file format
in func_win32_libid.  Can't we just feed the library in question to some
windows tool to decide this question?

Similarly for file_magic_cmd (here, ltmain should not even have to be
changed; simply a test in libtool.m4 that throws in some win32 tool iff
objdump is not present).

Cheers, and thanks again for your great work!
Ralf