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

[Peter Rosin]

Ralf Wildenhues skrev:
> * Peter Rosin wrote on Tue, Aug 05, 2008 at 10:38:14AM CEST:
> > Peter Rosin skrev:
> > > Attached, I'll work through all the failures to try to find out why
> > > they fail...
> >   16: duplicate_conv.at:25 duplicate convenience archive names
> > MS link doesn't have reloadable objects (i.e. like "ld -r").
>
> Should be fixed by at-file support I hope.

Unfortunately not, the test tries to link with "-o cee.$OBJEXT" which
triggers some different code path using -r. I don't think's it's
possible to have link.exe output an object file.

> >   25: link-order2.at:46  Link order of deplibs.
> > Don't know. Should defbindir=`pwd`/lib be defbindir=`pwd`/bin in
> > link-order2.at? Maybe the MSVC fixup of -L options is too coarse?
>
> Forget about this failure for now.  The link-order tests all suffer a
> bit from being too system-specific.
>
> >   29: static.at:68       static linking flags for programs
> > m-all-static.exe.manifest isn't installed
>
> What does the manifest file do?

The manifest is an XML file that describes how the executable should
be run. In this case it contains a hint where the side-by-side (SxS)
assembly containing the C runtime (msvcrt80.dll) is. The manifest can
also specify if a file should be executed with elevated priviliges (or
not).

I'm no manifest guru, so the above is perhaps not 100% accurate.

Side note, the mainfest could perhaps be used to support some version
of hardcode_libdir?

The crude fix is to (un)install the mainfest file, the nice fix
is to embed it as a resource in the executable using the manifest
tool (mt.exe).

> >   30: static.at:357      ccache -all-static
> > cl.exe spews out a banner on stderr which isn't [ignore]d
>
> I think that banner should just be ignored.

Me too.

> >   46: lt_dladvise.at:28  lt_dlopenadvise library loading
> > -avoid-version causes the names of the import lib and the static
> > lib to be the same. But something else<TM> also seems bad...
>
> Several issues:
> - the test is somewhat broken (also on other systems)
> - maybe we need to forbid enabling both static and shared at the same
>   time

- Or come up with a naming scheme that doesn't conflict with itself,
  but I don't know if that's possible...

> >   47: need_lib_prefix.at:25 enforced lib prefix
> > -avoid-version problem from 46, but also needs -no-undefined.
>
> Sigh.
>
> >   72: stresstest.at:31   Link option thorough search test
> > Automatic path conversion in MSYS doesn't kick in for the argument
> > -OUT:/some/absolute/path so lib.exe barfs.
>
> Not the biggest problem.
>
> >   73: cmdline_wrap.at:28 Run tests with low max_cmd_len
> > I just ran out of steam...
>
> That's where I hope most of the failures are either
> - failing for the same reason the non-low test is failing,
> - and/or fixed with at-file support.

Yes, that's what I figured. I actually had a little bit of steam
left, but was holding on to it a bit :-)

> Please try the patch below for simplistic at-file support with $NM.
> While testing, I set nm_file_list_spec to '@' and always_export_symbols
> to yes on GNU/Linux, and saw no test failure, probably because my nm
> also understands '@'.  :-)
> (IOW, we could enable that for when 'nm --help' lists @FILE.)
>
> Probably the setting of nm_file_list_spec should be moved to where $NM
> is set; not sure, as this is actually a Windows feature, not a $NM one.

I tried the patch and it fixes the old testsuite pdemo test, excellent!
But pdemo still fails due to an exported variable. Sigh. Why does each and
every damn test (well, almost) have to export a variable when that's listed
as not portable in the docs? Seems masochistic to me...

From my point of view, you may push the ltmain part of the patch. I'll test
any improved m4 code when you have settled on how to enable it. However,
your idea to check the help output will not work, dumpbin -? doesn't
indicate any support whatsoever for @.

Maybe hook into the existing
AC_CACHE_CHECK([the name lister ($NM) interface], [lt_cv_...
and add
  if test "$lt_cv_nm_interface" = "MS dumpbin"; then
    _LT_TAGVAR(nm_file_list_spec, $1)='@'
  fi
to the end of LT_PATH_NM?

But I don't know it's too early to use _LT_DECL/_LT_TAGVAR?

If that's the case, maybe add the above if statement to
_LT_CMD_GLOBAL_SYMBOLS (where $lt_cv_nm_interface is already used)?

That assumes that you don't think it's important to enable the new code
for gnu tools as well, of course.

Cheers,
Peter