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

[Peter Rosin]

Ralf Wildenhues skrev:
> * Peter Rosin wrote on Wed, Aug 06, 2008 at 09:47:28AM CEST:
> > Ralf Wildenhues skrev:
> > > * Peter Rosin wrote on Tue, Aug 05, 2008 at 10:38:14AM CEST:
> > > > Peter Rosin skrev:
> > > >   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.
>
> Ah yes, I didn't look at the test.  In this case, the test should just
> be skipped for systems where reload_cmds does not work.  Speaking of
> which, I think you should set reload_cmds to 'false' or so, so that it's
> clear things fail.  That could then be tested for as a SKIP criterion in
> the testsuite.

Right, I'll prepare a patch later...

> > Side note, the mainfest could perhaps be used to support some version
> > of hardcode_libdir?
>
> I guess.  Patches welcome, as they say.  ;-)
>
> > > >   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.
>
> Is the patch below sufficient?

Yes, please push. Thanks!

> > > >   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...
>
> Not sure whether I understand this.

With MSVC and -avoid-version, libtool will create both the import library
and the old (static) libarary with the same name (at least when both
static and shared are enabled at the same time). The current naming
is:

Shared library: foo-<version>.dll
Import library: foo-<version>.lib
Static library: foo.lib

But naming the import library e.g. foo-imp.lib or something (the -<version>
part isn't really needed), it wouldn't collapse into the name of the static
lib when the -avoid-version option is given. But just tagging on -imp to
the name will of course conflict with any library name ending with -imp.
Don't know if that's a real problem...

> > 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?
>
> Because it can be done on most systems, and w32 is not supported anyway
> for many packages.
>
> > Seems masochistic to me...
>
> Well, the testsuite is intended to test each possible code path.  That
> doesn't mean things have to be tested more often than necessary, but
> there could be for example a bug with exporting variables in the ltmain
> code that is exercises by pdemo.

It's just very hard to see other failures when so much stumbles on this
issue.

> > 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 @.
>
> Oh, I didn't mean to try 'dumpbin -?'  Sorry, I should have been
> clearer: GNU binutils nm understands @FILE since fairly recently; more
> precisely, all binutils tools understand this syntax since version 2.17.
> It would be nice to also enable this for binutils.  That would enable
> most real-world uses of 'ld -r' for good.  Proposed patch below.
>
> However, we need to avoid enabling this for older GNU binutils.  That
> could be done with a feature check or a check of --help output.
> Probably a feature check is more reliable.
>
> Part of my confusion here stemmed from the fact that, while on unixy
> systems, at-file support is a per-tool thing, on Windows it is actually
> a system feature (at least I think that it is that way).

No, it's not a system feature as such, it's just that many tools
implement it. My guess is that it is needed since the "shell"
quoting is so b0rked :-)

> Proposed patch below.  I changed my mind again and moved the
> nm_file_list_spec setting out from LT_PATH_NM.  OK?

Looks perfectly reasonable, but I'd change fi;if into elif, no need
to run $NM --help when nm_file_list_spec is already '@'. But I don't
care all that much... So, please push with or w/o elif.

Cheers,
Peter