gcc-wrapper / liborcus bustage ...

[Michael Meeks]

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 at collabora.com  <><, Pseudo Engineer, itinerant idiot