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