468,103 Members | 1,243 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,103 developers. It's quick & easy.

Problem using SWIG with perl

Hi,

I was trying to use SWIG to expose some C++ functions to perl. But, I
ran into some issues here. I don't know why, but I see that a macro in
SWIG replaces "NORMAL" with "PL_op->op_next"...

I ran the following test:

Files:

test.cxx:
#include "test.h"

test.h:
enum User
{
NORMAL = 1,
FOREIGN = 2
};

test.i:

/* File : test.i */
%module test

%{
#include "test.h"
%}

/* Let's just grab the original header file here */

%include "test.h"

If I run the Makefile (similar to the one in Examples/Perl5 directory
in SWIG), it gives the following error :

In file included from test_wrap.cxx:1464:
test.h:5: error: `PL_op' redeclared as different kind of symbol
/prj/qisdcrm/QChat/perl-5.6.1-Linux/lib/5.6.1/i686-linux/CORE/thrdvar.h:25:
error: previous declaration of `OP*PL_op'
test.h:5: error: declaration of `PL_op'
/prj/qisdcrm/QChat/perl-5.6.1-Linux/lib/5.6.1/i686-linux/CORE/thrdvar.h:25:
error: conflicts with previous declaration `OP*PL_op'
test.h:5: error: expected `}' before '->' token
test.h:5: error: expected unqualified-id before '->' token
test.h:8: error: expected declaration before '}' token
make[1]: *** [perl5_cpp] Error 1
It seems that some macro replaces "NORMAL" with "PL_op->op_next". I ran
a "grep" for "NORMAL" in the SWIG directory, but could not find
anything that replaces it. Can anyone help me with this?

Thanks,
Avinash.

Jan 11 '07 #1
6 2292
None wrote:
I was trying to use SWIG to expose some C++ functions to perl. But, I
ran into some issues here. I don't know why, but I see that a macro in
SWIG replaces "NORMAL" with "PL_op->op_next"...
[..]
>
It seems that some macro replaces "NORMAL" with "PL_op->op_next". I
ran a "grep" for "NORMAL" in the SWIG directory, but could not find
anything that replaces it. Can anyone help me with this?
Look further. Look in your compiler's 'include' directory, in your
OS headers, in other libraries, in your own headers...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jan 11 '07 #2
Avi
It seems that some macro replaces "NORMAL" with "PL_op->op_next". I
ran a "grep" for "NORMAL" in the SWIG directory, but could not find
anything that replaces it. Can anyone help me with this?

Look further. Look in your compiler's 'include' directory, in your
OS headers, in other libraries, in your own headers...

I just replaced "NORMAL" with "NORMAL_TYPE" and it works fine. Also, I
tried removing NORMAL from theenum and declaring :
#define NORMAL 1

It works fine. Is there a problem with declaring NORMAL within an enum
only? This is really wierd!

-Avinash.

Jan 11 '07 #3
Avi wrote:
>>It seems that some macro replaces "NORMAL" with "PL_op->op_next". I
ran a "grep" for "NORMAL" in the SWIG directory, but could not find
anything that replaces it. Can anyone help me with this?

Look further. Look in your compiler's 'include' directory, in your
OS headers, in other libraries, in your own headers...


I just replaced "NORMAL" with "NORMAL_TYPE" and it works fine. Also, I
tried removing NORMAL from theenum and declaring :
#define NORMAL 1

It works fine. Is there a problem with declaring NORMAL within an enum
only? This is really wierd!
If 'NORMAL' is a macro (which it looks like, from your original post),
then redefining it should cause a good compiler to complain. Turn up
your warning level to the max, see if you get "redefinition" warning
with a reference to the place where 'NORMAL' is previously defined...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jan 11 '07 #4
Avi
If 'NORMAL' is a macro (which it looks like, from your original post),
then redefining it should cause a good compiler to complain. Turn up
your warning level to the max, see if you get "redefinition" warning
with a reference to the place where 'NORMAL' is previously defined...

Yes I got the problem fixed. I tried undefining the macro while
compiling. That did not work. But with some help from the forums, I got
to know that I had to add the following code snippet in the .i file:

%runtime %{
#undef NORMAL
%}

Basically undefine the macro in the runtime environment.
This seems to work fine. Thanks a lot for the help.

-Avi.

Jan 11 '07 #5
"Avi" <av********@gmail.comwrote in message
news:11*********************@77g2000hsv.googlegrou ps.com...
>If 'NORMAL' is a macro (which it looks like, from your original post),
then redefining it should cause a good compiler to complain. Turn up
your warning level to the max, see if you get "redefinition" warning
with a reference to the place where 'NORMAL' is previously defined...


Yes I got the problem fixed. I tried undefining the macro while
compiling. That did not work. But with some help from the forums, I got
to know that I had to add the following code snippet in the .i file:

%runtime %{
#undef NORMAL
%}

Basically undefine the macro in the runtime environment.
This seems to work fine. Thanks a lot for the help.
Your other option would be to follow the advice that says only macros use
all capital letters. Since your enum of NORMAL isn't a macro, it should be
Normal or something else. Then you wouldn't have to undefine anything
because your variable name wouldn't be conflicting with your macro name.
Jan 11 '07 #6
On Thu, 11 Jan 2007 15:43:34 -0500 in comp.lang.c++, "Victor Bazarov"
<v.********@comAcast.netwrote,
>If 'NORMAL' is a macro (which it looks like, from your original post),
then redefining it should cause a good compiler to complain. Turn up
your warning level to the max, see if you get "redefinition" warning
with a reference to the place where 'NORMAL' is previously defined...
Or if that doesn't tell where it's coming from, put a line like

#define NORMAL ::::

before the first include, and see what the error message changes to.

Jan 12 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by Carl Waldbieser | last post: by
1 post views Thread by Uwe Mayer | last post: by
1 post views Thread by Arthur Chereau | last post: by
reply views Thread by Thomas G. Apostolou | last post: by
2 posts views Thread by ajikoe | last post: by
1 post views Thread by fdu.xiaojf | last post: by
6 posts views Thread by Harika | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.