This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Trying to build (perl) Inline::CPP-0.25.

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.

Can't think of a witty .sigline today....

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]