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

[Peter Rosin]

Ralf Wildenhues skrev:
> * Peter Rosin wrote on Mon, Aug 04, 2008 at 03:51:29PM CEST:
> > Ralf Wildenhues skrev:
> > > 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.
>
> Well, I certainly don't think we need to put much work in supporting a
> cross compile setup where MSVC is the compiler.  However, that is not
> what I was writing about: the above is a (quite widely used) GCC cross
> that runs on GNU/Linux and produces code for w32, using MSYS stub
> libraries and so on.  It's not nice to introduce a new test failure for
> this setup.
>
> That being said, I'm open to whether the code or the test should be
> fixed, or the test should simply be skipped in this case.  Ideally we
> should take into account that Windows shares may be mounted on unixy
> systems as well, such that maybe there is some benefit to be had from
> nocase support.  (OTOH, I have little experience with such setups;
> maybe the testsuite test would actually succeed there?  Then a skip
> on a case-sensitive system seems appropriate to me)

Ah, ok. That's bad. The misleading name i586-mingw32msvc-gcc caught
me. Again. What in the world is "msvc" doing in there?

Just to reiterate the underlying reason for this code, MSVC has a bunch
of system libs named e.g. DDRAW.LIB, while MinGW has the corresponding
import library as libddraw.dll.a. So, the libtool user can't use a
single canonical name (-lDDRAW and -lddraw are equally correct). At the
same time libtool has code that needs to find the exact file, this code
needs to be made case insensitive for things to work smoothly.

So, I don't think the benefit is all that great on unixy systems, since
there wouldn't be any question as to whether -lFoo or -lfoo is
correct.

To fix the test failure on the MinGW cross compile, it might be enough
to disable the nocase stuff in libtool.m4 for cross compiles (take the
default branch in the case $host_os statement, near the end of
_LT_CHECK_MAGIC_METHOD). This should cause a skip of the offending
test.

> > > > 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).
>
> Ah, ok; thanks.  Then maybe ltmain should not skip export in the first
> place if we have the needed at-file support.

Yes, but the code needs to be written to dig out exports using at-file, 
that mode of operation isn't currently implemented.

> This could fix some of your test failures, too.

Likely so, yes.

Cheers,
Peter