Mail Archives: cygwin/2007/07/24/18:15:57
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/
- Raw text -