gcc-wrapper / liborcus bustage ...

Hi there,

        I've been getting some horrible compile problems on windows around
liborcus & gcc-wrapper:

        This comes down to the rather old libtool 2.2.6b that is/was used to
make dist liborcus turning the relative path to
parser/liborcus-parser-0.6.lib into:


C:/cygwin/opt/lo/core/solver/wntmsci14.pro/bin/g++-wrapper.exe
-IC:/cygwin/opt/lo/core/workdir/wntmsci14.pro/UnpackedTarball/boost -O2
-Wall -o orcus-mso-encryption.exe
orcus_mso_encryption-orcus_mso_encryption.obj
 parser/.libs/liborcus-parser-0.6.lib
-LC:/cygwin/opt/lo/core/solver/wntmsci14.pro/lib
mso/.libs/liborcus-mso-0.6.lib 
/opt/lo/core/workdir/wntmsci14.pro/UnpackedTarball/liborcus/src/parser/.libs/liborcus-parser-0.6.lib
 -lzlib -lboostsystem
cl : Command line warning D9035 : option 'o' has been deprecated and
will be removed in a future release
LINK : fatal error LNK1104: cannot open file
'pt/lo/core/workdir/wntmsci14.pro/UnpackedTarball/liborcus/src/parser/.libs/liborcus-parser-0.6.lib'

        Where - as you can see passing /opt/lo/core as an argument to
g++wrapper results in the compiler having a nice failure.

        Apparently other people don't build on windows in /opt ;-) but - I'd
like to fix this; I pushed this to at least give a more helpful warning
- though I guess it will trigger for everyone as of now:

--- a/solenv/gcc-wrappers/wrapper.cxx
+++ b/solenv/gcc-wrappers/wrapper.cxx
@@ -87,7 +87,11 @@ string processccargs(vector<string> rawargs) {
 
     for(vector<string>::iterator i = rawargs.begin(); i != rawargs.end(); ++i) {
         args.append(" ");
-        if(*i == "-o") {
+        if(i->find("/") == 0) {
+            cerr << "Error: absolute unix path passed that looks like an option: '" << *i << "'";

        Thoughts on what to do appreciated. I can't see any kind of escaping
that works here.

        My hope would be that using a newer libtoolise would produce a liborcus
that doesn't have this problem [ I imagine it is an underlying libtool
bug with some missing cygpath's ].

        As/when/if we have an updated liborcus with that, it might be nice to
turn the above into a proper exit(1) error such that we can detect and
avoid these corner cases more easily in future :-)

        Or did I mess this up ? thoughts ?

        Thanks,

                Michael.

-- 
 michael.meeks@collabora.com  <><, Pseudo Engineer, itinerant idiot