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

[Peter Ekberg]

Ralf Wildenhues wrote:
> Thanks a lot for the overview.

No problem.

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

Regarding splitting things out, How small chunks should I make?
I mean, the "lib as archiver" seems like a unit. As is the case
with "dumpbin as name lister". The rest is also a unit in some
sence as it's all to do with support for MSVC, perhaps a natural
boundary is C vs C++. Should I also split C support into basic
support and fixes for various elaborate test cases?

Do you have any guidance on how I generate such a patch
series using cvs, and how I keep it up to date? Should I just
split it out bit by bit and do it the slow way, one patch at
a time? I could manage when it was a handfull of unrelated
oneliners, but this is more intricate...

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

(Sorry for not mentioning -TC and -TP, but I ruled them out as
 useless, maybe that was hasty, but I can't think of a way to
 use them)

I have them, but CC='cl -TP' is no good. The -TP switch has the
bad effect of really compiling *all* files as .cpp, which is
not what you want. If you for example do
        cl -TP foo.cc wsock32.lib
the dang tools will barf on the library not being C++.

So, the only way to use -TP and -TC is to always compile first
(with -c switch) and then link. I think libtool always does it
this way so that may not be a problem?

But you still can't add -TP to $CC as $CC is also used to link.
So you have to add -TP to CPPFLAGS, but I didn't find a
corresponding variable for C++, so you want different CPPFLAGS
for C and C++. Is there such a beast as CXXCPPFLAGS or whatever
it may be called? Can tags be of use here? (I'm pretty ignorant
when it comes to tag variables)

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

One reason to change ac_ext to .cpp is that the sources in
the tests use .cpp, so that is what you should test for.
Perhaps not a great reason, and I'm biased as I'm a lazy
person...

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

Maybe not so great though. I recently downloaded the free
C++ 2003 Toolkit and the latest Platform SDK and dumpbin
was not included. I wonder if support for this tool has
been dropped? Does anybody know?
I did a search on MSDN and there is no information
provided in the Visual Studio 2003 docs, when I look
in the place dumpbin was documented in previous MSVCs.
Dropping support for dumpbin is not mentioned in changes
so perhaps the docs has just moved. I don't think so
however, it looks like dumpbin is a goner.

And I can't find a tool that can fill the gap. Crap! Help!

Maybe I should just give up and say that some tools from
binutils are required. No big deal really.

The "lib as archiver" patch is still needed though, as
this seems like the easiest way to get at all symbols
from a library with so many objects that the max command
line length is exceeded (pdemo.test), as the Microsoft
linker does not seem to support reloadable objects.
You *could* extract symbols from one object at a time
and merge the outcome, but I think that would be a much
bigger change.

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

You mean "new test suite" as in "test suite in HEAD", right?

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

See above.

> Cheers, and thanks again for your great work!

Cheers, and thanks again for reviewing the patches!
Peter