libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Duft
Subject: FW: [patch #6448] [MSVC 7/7] Add MSVC Support
Date: Fri, 22 Aug 2008 15:25:37 +0200

Forwarding because i forgot to add libtool-patches to CC...

> 
> >
> > Markus Duft skrev:
> > > Could this break parity support? I know It's not in the tree yet,
> but
> > I
> > > still hope, that ralf comes to looking into my patch some day....
> >
> > Hi Markus,
> >
> > Looking at your patch, the changes to ltmain.m4sh should not have any
> > special casing for $CC matching *parity* or $host matching *winnt*. I
> 
> Hey, thanks for looking at it!
> 
> > know that the first hunk just piggybacks on older such code, but new
> > code should forward a control variable from libtool.m4 instead.
> > Check e.g. these patches [1] [2] for how to create such variables.
> >
> 
> Hm... i'll have a look at it as soon as i have some spare time.
> 
> > It's not unlikely that there are more issues with your patch, but
> > that's something to start with, in case you have spare time (yeah,
> > right...)
> 
> Err... haha... ;)
> 
> >
> > 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.
> 
> >
> > 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...
> 
> Cheers, Markus
> 
> >
> > Cheers,
> > Peter
> >
> >
> [1]http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=752
> > 20caf33f6635e80cc2b540a75d58bf0e00d46
> >
> [2]http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=92e
> > 15986a43a8009decffc4d5d290272449487a4






reply via email to

[Prev in Thread] Current Thread [Next in Thread]