[0/11] Native MSVC support.

[Peter Rosin]

Hi!

I ran out of steam last spring, but I have now spent some time on
my MSVC patch(es). I think I have adressed all previous concerns, but
it has been a while so I'm sure I missed some and/or that something
else will crop up...

Oh, I haven't tested with the MinGW cross-compiler in e.g. Debian.
That was requested. Someone else, please?

I dug into the tool "quilt" and cut the original patch into smaller
pieces to make the discussion easier. Heck, I even wrote ChangeLog
entries, how presumptuous is that? :-)
I hope this helps the review and clarifies a few things...

I will reply to this message with the actual patches. Stay tuned.


I have tested "make check-local" with:

1. Cygwin

2. MSYS/MinGW

3. MSYS/MinGW and MS lib as archiver:
        configured with these options:
        AR=lib

4. MSYS/MSVC
        configured with these options:
        CC=cl CFLAGS=-MD CXX=cl CXXFLAGS=-MD LD=link NM="dumpbin -symbols" \
        AR=lib STRIP=: RANLIB=: F77=no FC=no

And without the patches applied:

5. Cygwin

6. MSYS/MinGW (but still with #include <stdint.h> in the cwrapper)


I do not have any installed autotools for MSYS, some things fail/skip due
to that.

Using MinGW with lib (3 above) results in an UNEXPECTED PASS for
test 24, static library contains static library, but that is natural
since lib knows how to "merge" two archives.

I don't see any unexpected (for me) test results for MSYS/MSVC. However,
there are some "new" failures relative to MSYS/MinGW in the testsuite
for MSVC, but nothing /really major/:

 7: duplicate convenience archive names
        FAILED (duplicate_conv.at:79)
        Relinking ($CC -r) is not supported by MSVC.

 8: preserve duplicate convenience deps
        skipped (duplicate_deps.at:66) (expected failure on MinGW)
        Circular deps is not an issue with MSVC.

15: Link order test.
        FAILED (link-order.at:69)
        Exports a variable. Isn't that covered by export.at? Is it
        really necessary to export variables in every other test?

16: Link order of deplibs.
        FAILED (link-order2.at:129) (same as MinGW)
        Finding libs through PATH is too limited?

18: shlibpath_overrides_runpath
        skipped (shlibpath.at:54) (same as MinGW)
        Finding libs through PATH is too limited?

19: static linking flags for programs
        FAILED (static.at:187)
        Non-libtool library liba3 is linked statically in the
        m-static.exe and m-static-libtool-libs.exe cases.
        Probably because there is a naming clash between
        the import lib (a3-0.lib) and the static lib (a3.lib)
        and -la3 selects the static lib (when there is no
        .la file to guide libtool). I could make libtool
        convert -lfoo to foo-#.lib if there is such a file
        instead of (blindly) converting it to foo.lib (when
        there is no guiding libfoo.la).

20: Export test
        FAILED (export.at:157)
        Needs more dllimport etc...

24: static library contains static library
        UNEXPECTED PASS
        AR=lib is different from AR=ar...

32: lt_dlopenadvise library loading
        FAILED (lt_dladvise.at:314) (same as MinGW)
        No dladvice with dlls.

53: Link option thorough search test
        FAILED (stresstest.at:270)
        Absolute paths doesn't always work.

54: Run tests with low max_cmd_len
        FAILED (cmdline_wrap.at:43)
        Natural, since some of the above fails...

Cheers,
Peter