libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ralf Wildenhues
Subject: Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Date: Mon, 4 Aug 2008 22:12:19 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

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

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

This could fix some of your test failures, too.

Thanks!
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]