Re: [patch #6448] [MSVC 7/7] Add MSVC Support

[Peter Rosin]

Ralf Wildenhues skrev:
> Hi Peter,
>
> yeah, replying to a mail that's 5 months old:
>
> * Peter Rosin wrote on Tue, Mar 04, 2008 at 11:23:48AM CET:
> > I have no problems with this patch series on either mingw, nor
> > cygwin.
>
> Great.  I've rebased your patches against current git Libtool,
> and put them in a git branch, named pr-msvc-support, which I
> pushed to savannah's git repo.  You should be able to get it with
>
>   git clone git://git.sv.gnu.org/libtool.git
>   git branch pr-msvc-support origin/pr-msvc-support
>   git checkout pr-msvc-support
>
> NOTE!  This git branch may be rewound at times, rebased against
> a newer master, or whatnot else.  I don't think that in practice
> it will need rewinding a lot, and I hope we can get by with only
> reworking patches incrementally in order to get patches cherry
> picked into master.  But all bets are off, and I don't want anybody
> to come back crying later.
>
> That being said, of course I won't rewind the branch without
> prior notification or asking, depending on who else wants to
> work on the branch.

Great, thanks!

> I've fixed a couple of trivial typos in the patches, a couple of
> instances of "test $foo == $bar"  (needs to be = instead of ==).
>
> +  if shopt | grep nocaseglob 2>&1 > /dev/null; then
>
> I changed this to:
>
> +  if ( shopt | grep nocaseglob ) >/dev/null 2>&1; then
>
> to really drop stderr, and silence ash as well.
>
> I've reformatted tests/nocase.at a bit, and sprinkled in more AT_CHECKs
> because the test fails for me on a GNU/Linux -> MinGW cross compile
> (using i586-mingw32msvc-gcc):
>
> libFOO is found but -lfoo is not rewritten to -lFoo.  I don't know if it
> should be, but either the test or the implementation needs fixing.

Test works fine on the MSYS/MSVC pair. I suspect if fails bacause the
build system FS is case sensitive? Cross compile is not my top priority.

> > Annotated testsuite with these patches:
> >
> > On MSYS and MSVC 12.00.8804 (MSVC 6) with:
> > ../configure CC=cl CFLAGS=-MD CXX=cl CXXFLAGS=-MD LD=link NM="dumpbin
> > -symbols" AR=lib STRIP=: RANLIB=: F77=no FC=no
> >
> > The problems with the exported variables can be solved with the
> > right amount of declspecs. I will not work on the other problems
> > until basic MSVC support is commited.
>
> I think there have been various patches floating around for the exported
> variables things.  You can probably search the list archives for them.
> Maybe you've even written some of them.
>
> What I'd ideally like to see here is a patch that
> - isn't ugly (yeah ;-)
> - keeps system-specifics abstracted away as much as possible,
> - but still allows the intermediate (non-expert) user to understand
>   that these annotations are needed for plain MSVC support only
>   (i.e., for packages which are deeply rooted in unixy land, that
>   may be ported to Cygwin but never to MinGW or MSVC, there is no
>   need for these annotations).

Right...

> > PASS: tests/demo-conf.test
> > FAIL: tests/demo-make.test (exported variable, remove it fixes it)
>
>
> > FAIL: tests/demo-deplibs.test (assumes oldlibs are named lib???.a)
>
> Let's not worry about this for now; this is clearly a testsuite issue.
> (Of course the corresponding real-world issue exists, but may be worked
> around using libtool libraries everywhere).
>
> Speaking of which, maybe a manual chapter for Windows specifics is in
> order?

Probably.

> > FAIL: tests/pdemo-make.test (link can't create reloadable object files (-r))
>
> That indicates a bug in libtool.m4: file_list_spec isn't working right.
> With too many files on the command line, it should use an at file (@)
> to specify them.  (Maybe the corresponding code in ltmain needs
> adjustment, I don't know.)

No, I don't think this is as simple as a libtool.m4 bug. This is something
that's not implemented in ltmain. What's going on is that a cmd is too
long during the preparation of the list of exported symbols. This causes
skipped_export=: which is bad on MSVC, since it unconditionally ends up
in the func_verbose "creating reloadable object files..." branch. The
functionallity behind "ld -r" is not available in MS link, so $reload_cmds
may not be used at all but is used in this branch and everything goes
belly up.

And MSVC needs the list of exported symbols, or it doesn't export anything.
Well, it will obviously export stuff marked with declspecs, but that's
what we're trying to avoid (and it works fine for functions, but not
variables, as long as the the $reload_cmds branch isn't taken as above).

> This issue should be fixed before the patches go to master.

Ok.

> > SKIP: tests/demo-hardcode.test (...but fails here, using $CC w/o going
> > through libtool)
>
> Don't worry about this for now.
>
> Could you run
>   make check-local
>
> (you may have to set TESTSUITEFLAGS="CC=cl ..." accordingly)
> and post tests/testsuite.log?

Attached, I'll work through all the failures to try to find out why
they fail...

Cheers,
Peter

testsuite.log.gz
Description: GNU Zip compressed data