Ralf Wildenhues wrote: > Hi Peter, others, > > I've decided to start yet another new thread about this neverending > issue. I've given your patches (and also my pending ones) > another test > round, and something seems to be going very wrong. Since > more than just > one thing changed between the last time I tested (and only a couple of > failures occurred there), I may have just done some things > wrong, but I > can't see them at the moment.
Arrrgh, and here I was thinking I was pretty much done... I guess
I too have to do some tests with the free toolkit. *installing*
> 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...
> b) The first attachment shows a failure of demo-make after
> demo-static.
> This might be a local setup problem or not, I'm not sure. The same
> failure occurs in half the testsuite failing. For reference, I have
> attached as second one my settings of LIB and INCLUDE, which may be
> wrong, I don't know. Some of the libraries exist in both MSVC and the
> developer toolkit, and frankly, I don't know what the
> required order is.
> (also watch out for the stupid native language path if you want to try
> this for yourself).
This seems to be because of a problem with the global_symbol_pipe.
Consider the following snippet from the dumpbin output from
foo.obj:
00E 00000000 SECT3 notype External | _nothing
00F 00000000 SECT4 notype Static | .text
Section length 2B, #relocs 4, #linenums 0, checksum 3A8D1F2D
011 00000000 SECT4 notype () External | _foo
012 00000000 UNDEF notype () External | _printf
013 00000000 UNDEF notype () External | _cos
014 00000000 SECT5 notype Static | .rdata
Section length 8, #relocs 0, #linenums 0, checksum
0, selection 2 (pick any)
016 00000000 SECT5 notype External | [EMAIL PROTECTED]
Notice how the "Section" line before the [EMAIL PROTECTED] symbol says
"(pick any)" at the end? (the line is probably wrapped, but you
get it) I think this "Section" line has to be accounted for when
determining if a symbol is to be exported. Nm for that symbol
says R, not D. However, my sed-fu is week, but I've read that sed
can be made to remember one line in some buffer, perhaps I can
come up with something given some time to tinker. This is the
first time I've noticed "(pick any)", just so that you know.
Anyway, you can always try without NM="link -dump -symbols",
and use the name lister from MinGW (but then the C++ tests will
fail). Or use the attached patch which has been updated to
simply strip out any line with " __real@" on it. A real fix is
needed here though, but the @ at the end saves most users
wishing to have a "_real" global symbol.
Regarding Platform SDK vs. MSVC, my guess is that PSDK should
be first in the search order.
> 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.
> 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 did mean to add $LDFLAGS to archive_expsym_cmds but did not know
if I should add it before or after the -link option. If I add it
after -link, there is no way to add linker flags to the compiler
and if I add it before -link I have to provide some means to
actually pass them on to the linker (all options after -link are
simply passed on to the linker).
I guess I can just add $LDFLAGS after -link for now, and if the
need arises, provide some means to make part of LDFLAGS end up
before the -link option. Perhaps something like this is feasible:
If -link option is given in LDFLAGS, everything before
-link ends up before -link, and anything after -link
ends up after -link. If -link option is *not* given
in LDFLAGS, all of it is added after -link.
*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...
> 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?
> 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.
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)
> Finally, I've attached the compressed output of "cvs diff" to show my
> merge of your patches plus a couple of pending ones of mine.
> And: I've
> actually bootstrapped with 1.9.5 and 2.59, so issues related to that
> could've shown up as well.
>
> Regarding "test one issue at a time": yes, I should do that.
> No, my bug
> reports cannot be qualified as decent. If you want decent
> ones, you'll
> get them, but only much much later.
Well, I can reproduce your problems here, except f). I just
didn't try the free MSVC++ 2003 before.
> 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...
> 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...
Cheers,
Peter
head-msys_msvc-12.patch
Description: head-msys_msvc-12.patch
