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

[Markus Duft]

> 
> Markus Duft skrev:
> >> Also, your changes to tests/duplicate_conv.at is (or, to be correct,
> >> "will probably be") addressed by setting reload_cmds to false (patch
> >> pending on libtool-patches@). Hold on! This is exactly what was
> >> discussed in this very thread. You should definitely set reload_cmds
> >> to false for Parity as well. You even say this in your ChangeLog:
> >> "Disable the use of reloadable objects (not supported)."
> >
> > Hmm... i remember that i tried many different things to force libtool
> (I
> > think it was 1.5.24 back then) to _not_ try to use reloadable
> objects. The
> > only solution I found back then was patching ltmain.sh somehow to
> simply
> > skip that part with parity.
> 
> There is now code that passes files using a response file and that code
> path is preferred over reloadable objects, just set the variable
> $file_list_spec to '@' in libtool.m4 (if Parity can handle that and
> pass it on to MSVC of course). Or was that $nm_file_list_spec? Oh well,
> you can do the legwork. :-)

Yeah, right... parity doesn't understand @ - at least not yet... :*(

Cheers, Markus

> 
> >> Your changes to the following files should be obsoleted by patches
> >> already in the pr-msvc-support branch:
> >> tests/export.at
> >> tests/link-order.at
> >> tests/stresstest.at
> >
> > Mhm, ok, cool :)
> >
> >> I find it strange that you tie $host matching *winnt* to
> >> Parity/MSVC. That seems to be different from the intentions of
> >> $host ($host is to me a system type, not a toolchain). I would
> >> argue that for Parity, $build should be *-interix* (since
> >> you are using Interix to drive the scripts, IIUC), and $host
> >> should be *-mingw*. I.e. what you are really doing is something
> >> that is in fact cross-compilation (with the quirk that you
> >> happen to be able to run the resulting binaries of course).
> >> But - and that's a big but - I'm in no way an expert on these
> >> issues. And I haven't read up on what Parity is really doing,
> >> so if the dlls etc that pop out are not usable by anything but
> >> Parity it might be a totally different matter.
> >
> > We have spent many hours here playing with "cross" compiling (which
> it isn't
> > since we can execute the result, etc.), and never where too
> successful. The
> > best results where when using the same host triplet for
> build/host/target...
> > mingw would be totally wrong IMHO. Parity just uses cl.exe and co. as
> > backend, pretty much like your patches do directly I guess. Which
> host are
> > you using. The winnt was just the best that came to our ming, since
> the
> > result is plain win32 binaries. So really the host could be *-
> interix* and
> > target of parity is *-winnt*. However as I said above, I have no good
> > experience with cross compiling. There is code out there that asks if
> it is
> > cross compiled, and just breaks...
> 
> As I said, I'm no expert, so check out the mail from Ralf on the list.
> It just seemed strange to me...
> 
> (But I still think it's a cross compile. It's just a coincident that
> you happen to be able to execute the results. I also know that cross
> building is painfull and broken in far too many packages, so I fully
> understand if you don't want to go there. I just climbed too far out
> on the teoretical branch I suppose...)
> 
> Cheers,
> Peter