John Lenz <[EMAIL PROTECTED]> writes: >Hi. We have been having a bunch of problems recently with SWIG >(http://www.swig.org) and Perl 5.8.0. I am running Debian unstable, >but we have also seen this problem on Solaris. I have reduced the >problem to this short file >#include "EXTERN.h" >#include "perl.h" >#include "XSUB.h" > >#include <iostream> > >int main() { return 42; } > >If you attempt to compile this file, a lot of errors having to do with >do_open are generated. The problem is, <iostream> has a private >function of a class named do_open. It took me a while to find because >here is private member of a class that is inside a namespace >conflicting with a define in the perl headers. Normally, you could >just change the order of including the files, but for SWIG that is >difficult/impossible because the C++ file is generated and any input >file can tell SWIG to include <iostream> at any point in the file.
This is possibly a SWIG problem in that it could do a better job here. I had not realized that: /* NO_EMBED is no longer supported. i.e. EMBED is always active. */ made it into the mainline - this is a step backwards :-( > >So my question is, how can I get rid of all the macros polluting the >global namespace? Since this is a generated file, we can take care of >the context stuff. Really I just want a way to not include embed.h in >these files, and then use the perlapi though all the Perl_ and PL_ >macros so that perl stays in its own namespace. The only thing I can suggest at present is to create a "noembed.h" and ask SWIG to include that before <iostream>. It would contain #undef do_open etc. > >John -- Nick Ing-Simmons http://www.ni-s.u-net.com/
