RE: state of MSVC patches for HEAD

[Peter Ekberg]

* Ralf Wildenhues wrote on Thursday, September 08, 2005 18:09 CEST:
> Hi Peter,
> 
> Back to the list of issues I encountered: it's grown smaller :)

It starts to feel like a new issue is found for each we cross out.

> * Peter Ekberg wrote on Mon, Aug 29, 2005 at 03:00:33PM CEST:
> > Ralf Wildenhues wrote:

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

I never intended the mdemo part of the patch for inclusion,
it's a horrible hack just to indicate where the problem is.
The other patches to the testsuite are better, at least they
don't muck around with other platform (IIRC, it's been a
while now).

But I was hoping to get the core functionallity for MSVC in
first and then fix the testsuite and the remaining problems
bit by bit. Perhaps that's backwards, but it would be easier
for me, I think. See $AR discussion below...

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

Hmm, I tries that but it failed for some reason I have now
forgotten. But cool! (side note: it has worked for MSVC6 all
along)

*snip*

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

Ah, ok.

> > 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/2
2/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/su
> b2/.libs/a.lib'
> 
> Looks like there is another path conversion to win32 path missing
> somewhere.  Have not investigated further yet, sorry.

Indeed. It's the -OUT:/full/path notation that throws off
MSYS as -OUT: is directly prepended and /full/path is not an
argument on it's own. Crap crap crap.

I guess the generic path conversion function is again called
for. But still there needs to be some way to indicated when
this function should be used. How about setting up one
cmd variable for *how* to do the conversion and then have one
variable listing *when* to do the conversion? Or should we
have one cmd for fixing src files (fix_srcfile_path), one for
-L paths (in func_dashL_to_envvar in the MSVC patch), one for
$AR libraries, etc.

Regarding this issue, which is connected to demo-deplibs above,
isn't it a bit limited to:

1. Have a means to build static archives in strange ways
   (old_archive_cmds) using $CC and what not.

2. Expect automake to be able to update this archive
   using $AR, and without using libtool (demo-deplibs).

3. Not provide a libtool mode for automake to make requests
   for archive updates.

Or have I misunderstood demo-deplibs and it is not
updating the archive? Is it only recreating the archive
from scratch? Either way, #2 is bad enough given #1, and
automake needs to pick up that libtool is used and output
the correct rule, IMO. I mean, it picks up that it should
compile and link with libtool, so what's the difference?
I suppose it's just difficult, but this sucks.

Anyway, since we are getting further and further away from
a simple $AR invocation to work, it's perhaps best to
implement a wrapper function in ltmain and ignore automake?
That would also significantly reduce the patch and perhaps
make it more digestable as it wouldn't need to touch all
those other $AR users.

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

MSVC probably suffers from this too (truncating PATH seems
nasty), but I'd be surprised if my patch causes it.

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

How do I trigger it?

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

Whoeps. How about file_list_spec?

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

OK.

Cheers,
Peter