Re: state of MSVC patches for HEAD

[Ralf Wildenhues]

Hi Peter,

Back to the list of issues I encountered: it's grown smaller :)

* Peter Ekberg wrote on Mon, Aug 29, 2005 at 03:00:33PM CEST:
> Ralf Wildenhues wrote:
> > 
> > a) I forgot to patch the old testsuite tests, sorry.  So 
> > seeing failures
> > which account for the missing EXTERN should be OK.  But I don't think
> > the ones below are those.
> 
> ACK, except c), but you already guessed that...

OK.

> > b) The first attachment shows a failure of demo-make after 
> > demo-static.

> This seems to be because of a problem with the global_symbol_pipe.
> Consider the following snippet from the dumpbin output from
> foo.obj:
> 
*snip*
>     Section length    8, #relocs    0, #linenums    0, checksum
> 0, selection    2 (pick any)
> 016 00000000 SECT5  notype       External     | address@hidden

This has been resolved with the patch I just committed (see other mail).

> Regarding Platform SDK vs. MSVC, my guess is that PSDK should
> be first in the search order.

OK, thanks for sharing.

> > c) The third attachment shows a pdemo-make after pdemo-conf failure.
> > Is this due to the missing EXTERN patch?
> 
> Yes, seems so. When I try here I run into the __real@ problem,
> and with the workaround for that it works.

OK.

First new issue with them: The mdemo change (add -export-symbols-regex
for libmlib) breaks the mdemo2 tests on cygwin, because then the libltdl
symbols are not exported from it any more.  So that is definitely not OK
for inclusion.  OTOH, we may need to fix this in ltmain/libtool.m4
rather than in mdemo -- this may need discussion.

> > d) The fourth attachment shows tagdemo-make after 
> > tagdemo-static failing
> > because of missing libci.  I searched the net, and found the hint that
> > MS renamed the library to libcp, but forgot to rename all 
> > references to
> > it.  What would I need to do except a "cp libci.lib libcp.lib" in the
> > corresponding direcory/ies to make this work again?
> 
> (Other way around I suppose, "cp libcp.lib libci.lib")
> 
> I found suggestions to do the equivalent of
>       export LINK=-NODEFAUKLTLIB:libci.lib
> but that breaks autoconf for me for some obscure reason. However,
> Saying "make check LINK=-NODEFAULTLIB:libci.lib" did the trick
> for me without disturbing autoconf. I then ran into issue b).

I found a better way to eliminate this issue:  Change all occurrences of
`iostream.h' to `iostream', and sprinkle `using namespace std;'
appropriately.  (The discussion whether to change this has come up
repeatedly; it's an orthogonal issue and should be treated as such.
See separate post.)

Tagdemo tests pass then, great!  And the template.at tests, too, which
is very cool!  (I'll fix the -no-undefined warnings..)

*snip*
> *time passes* (workaround for the __real@ problem added)
> 
> I added $LDFLAGS after -link in libtool.m4 and configured with
> LDFLAGS=-NODEFAULTLIB:libci.lib but that only caused some
> C++ defendencies to be missing. I then tried to configure with
> LDFLAGS="-NODEFAULTLIB:libci.lib libcp.lib" in order to bring
> them in from libcp instead, but that caused failures when linking
> ordinary C stuff, so I don't know if it would work. I think
> not, see below.
> 
> Any suggestions? BTW, your cp suggestion does not appear to work,
> at least not for me. But if I copy libci.lib from my MSVC6
> installation it works...
> 
> I think libci.lib and libmtci.lib (for multithreaded) are
> import libraries, and that Microsoft simply ripped out all
> import libs (including msvcrt.lib) in the free toolkit
> leaving only the option to link statically with libc.
> Apparently that makes some code break, since Microsoft didn't
> solve all problems...

See above.  I won't worry too much about all of this for now.

> > e) Of the new testsuite, test 12 and 13 seem to pass but silently fail
> > for me on my slightly out-of-date MinGW/msys installation (next
> > attachment), it seems because Automake-1.7 is used.  I see MinGW has
> > 1.8.2 for download now; which one did you test with, and do 
> > you see this failure?  This is important, we have to adjust minimum
> > allowed Automake versions for client packages here
> 
> I do not have autotools installed for MSYS. I bootstrap in Cygwin
> with cvs-autotools and just configure on MSYS. Not sure what you
> mean, sorry. Parhaps that I should try to bootstrap with older
> autotools in Cygwin?

Nono, I mean the following: some of the tests from the new testsuite
execute aclocal/automake/autoconf as part of their testing.  They need
newer autotools versions.  Next time I test I will install them
beforehand; not because I assume failures in them, but because some of
the tests also exercise other features of `libtool'.

> > f) The standalone failure is really weird.  I'd guess it's a 
> > merge error of mine when putting together your outstanding patches..
> 
> Works for me, let's assume you are right.

Works for me now, too, so let's just ignore it for now.

> Can you please try this patch, with the dirty workaround for the
> __real@ problem and $LDFLAGS added to archive_expsym_cmds, not
> that LDFLAGS solved any problems, see above...
> 
> LIB='C:\Program Files\Microsoft Platform SDK\Lib;C:\Program
> Files\Microsoft Visual C++ Toolkit 2003\lib;'
> INCLUDE='C:\Program Files\Microsoft Platform SDK\Include;C:\Program
> Files\Microsoft Platform SDK\Include\crt;C:\Program Files\Microsoft
> Visual C++ Toolkit 2003\include'
> PATH=/c/Program\ Files/Microsoft\ Visual\ C++\ Toolkit\ 2003/bin:$PATH
> export INCLUDE LIB
> 
> configure CC=cl CXX=cl CXXFLAGS=-GX STRIP=: RANLIB=: AR="link -lib"
> NM="link -dump -symbols" F77=no FC=no
> 
> (-GX flag for C++ exceptions)

Well, I tried with the LIB/INCLUDE/PATH settings (adjusted to locale),
but my own configure options (empty CXXFLAGS).  And the patch I used
was a sort-of-forward port of yours.

> Well, I can reproduce your problems here, except f). I just
> didn't try the free MSVC++ 2003 before.

Never mind, see above.

> > Any pointers are greatly appreciated!  :)
> 
> FYI: I also still get occational failures on
> tests/mdemo-dryrun.test due to the same issue I tried to solve
> with the "sleep 1" calls in my mdemo-dryrun-extra-sleep.patch.
> I wonder if 1 second was not enough or if I missed a spot...

Ahh, seeing that fail as well.  Haven't looked into it yet.

> > By the way, can I expect another update on the "link -dump" issue from
> > you regarding the recent comments from people?
> 
> I was intending to suggest that my proposed patch should be
> applied as is and that the problem of locating a good link
> program could be attacked later. I'm grateful for anything
> that can be applied, the weeds are accumulating...

I understand.  But there are still regression w.r.t. non-MSVC mingw or
cygwin systems, and that is absolutely not acceptable at this time,
sorry.



Remaining failures I see that we already know about: 
- tagtrace: missing fitting Autoconf install -- the test should be
fixed,
- demo-deplibs: Automake needs patch for $(AR) cru
- mdemo-dryrun: see above (btw, mingw/gcc has this as well)
- demo-hardcode: known -L/-l option conversion issue
 

Remaining untested tests:
- am-subdir (12-13)
- early-libtool (20-21)


New issues:
- stresstest (happens when you fix the sed script in ltmain as I suggested
earlier in the other thread):

| libtool: link: link -lib  -NOLOGO 
-OUT:/home/ralf/libtool-msvc/build2.1-cl/tests/testsuite.dir/22/sub2/.libs/a.lib
 /home/ralf/libtool-msvc/build2.1-cl/tests/testsuite.dir/22/sub/.libs/a.obj
| LINK : fatal error LNK1104: cannot open file 
'/home/ralf/libtool-msvc/build2.1-cl/tests/testsuite.dir/22/sub2/.libs/a.lib'

Looks like there is another path conversion to win32 path missing
somewhere.  Have not investigated further yet, sorry.

- With a mingw/gcc build, I see this silent failure:
demo-hardcode:
| You may ignore any linking errors from the following command:
| PATH=./.libs gcc -g -O2  -o hc-libpath main.o -lhello  -lm 
-L/home/ralf/libtool-msvc/build2.1-gcc/_inst/lib || echo unsupported > 
hc-libpath
| /bin/sh: gcc: command not found

I haven't checked whether this is a regression or not.  In any case it's
not testing what it should.

- mingw/gcc still has the lt__error_strings issue. (Not a regression)


Other notes:
- A small glitch in your patch: your setting of export_symbols_cmds
belongs in _LT_LINKER_SHLIBS rather than in _LT_LANG_CXX_CONFIG; or
did I miss anything here?  (I have not corrected this yet.)

- For reference, the patch I used is attached.  It's against current CVS
but does not contain the outstanding bootstrap or Makefile.am patch, nor
the TAG_COMPILER patch.

Cheers,
Ralf

head-msys_msvc-12-forwarded.patch.gz
Description: GNU Zip compressed data