On 24 July 2007 21:00, Reini Urban wrote:
> Switching to g++ probably has other issues. Most XS modules are pretty > fine with gcc, but I wouldn't be sure if all of them are C++ safe. This isn't an issue, or rather, it's not as bad as you think. Whether you use g++ or gcc as the driver, it still looks at the file extension to decide what language subcompiler to invoke; the only real difference between the two is in the -I, -D and -L options they assume by default. There could be namespace clashes with C++ headers that don't exist in C, and there could perhaps be issues in linking against libstdc++ and libsupc++ (name mangling would protect against most accidental collisions here, but I don't know if there might be extern "C" functions in either of them), but you would't need to worry about the language incompatibilities. > For the start having a wrapper should help use in fixing this inside > ld2 or perlld. > We should detect if the intermediate .o was compiled as c++ or plain gcc. > nm -C $obj|grep "operator new(" for example. Is there a better way? I'm not sure this is necessary (particularly in light of the above). Whatever you do should work if the final executable combines C *and* C++ modules, without causing complications for the C, so it should work for a final executable that only has plain C modules as a special case. I think you should be just able to use g++ for the link step regardless, and need only trouble yourself with picking the right driver for the compilation step. cheers, DaveK -- Can't think of a witty .sigline today.... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/