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: Sat, 2 Aug 2008 15:39:25 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

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.

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.

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

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

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

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

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

Cheers, and thanks a lot,
Ralf




reply via email to

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