Strange SWIG behaviour

[Esteban Manchado Velázquez]

Hi,

I'm doing some experiments with SWIG (trying to make a Ruby interface =
for
MuSE low-level sound classes), and I'm having some problems.

One of them is really weird: it seems that there are problems with ext=
ern
"C" declarations (from C++) and with functions _named_ "error" (namely, t=
hat
when you try to call the function, the interpreter aborts, without except=
ions
or anything).

Here is my tiny example:

-- errortest.c / errortest.cxx ------ 8< --------------------------------=
-----
#include <stdio.h>

void error(const char *fmt, ...)
{
printf("I won't be called\n");
}
------------------------------------- >8 --------------------------------=
-----

-- errortest.i ---------------------- 8< --------------------------------=
-----
%module errortest

%{
#include "errortest.h"
%}

#ifdef __cplusplus
extern "C" {
#endif

void error(const char *format, ...);

#ifdef __cplusplus
}
#endif
------------------------------------- >8 --------------------------------=
-----

-- errortest.h ---------------------- 8< --------------------------------=
-----
#ifdef __cplusplus
extern "C" {
#endif

void error(const char *format, ...);

#ifdef __cplusplus
}
#endif
------------------------------------- >8 --------------------------------=
-----

-- Makefile ------------------------- 8< --------------------------------=
-----
BASENAME =3D errortest
WRAPPER_BASENAME =3D $(BASENAME)_wrap
SWIG =3D swig
INTERFACE =3D $(BASENAME).i
CXXSRCS =3D errortest.cpp
SRCDIR =3D .
OBJS =3D $(CXXSRCS:.cpp=3D.o)
INCLUDES =3D -I.
LINK =3D=20
CPP =3D 1
GCC =3D $(if $(CPP),g++,gcc)
SWIG_OPTS =3D $(if $(CPP),-c++,)
SRC_EXT =3D $(if $(CPP),cxx,c)


all: $(BASENAME).so

$(BASENAME).so: $(BASENAME).o $(WRAPPER_BASENAME).o
$(GCC) -shared $(OBJS) $(WRAPPER_BASENAME).o $(LINK) -o $@

$(BASENAME).o: $(SRCDIR)/$(BASENAME).$(SRC_EXT)
$(GCC) -fpic -fPIC -DHAVE_CONFIG_H -c -shared $(INCLUDES) $<

$(WRAPPER_BASENAME).o: $(WRAPPER_BASENAME).$(SRC_EXT)
$(GCC) -fpic -fPIC -DHAVE_CONFIG_H -c -shared $(INCLUDES) -I/usr/lib/rub=
y/1.8/i386-linux $(WRAPPER_BASENAME).$(SRC_EXT)

$(WRAPPER_BASENAME).$(SRC_EXT): $(INTERFACE)
$(SWIG) $(SWIG_OPTS) -ruby $(INTERFACE)

clean:
$(RM) $(BASENAME).so $(BASENAME).o $(WRAPPER_BASENAME).o $(WRAPPER_BASEN=
AME).$(SRC_EXT)

PHONY: all clean
------------------------------------- >8 --------------------------------=
-----

When I try to use it:

------------------------------------- 8< --------------------------------=
-----
zoso@velutha:~/tmp/swig$ ruby -rerrortest -e "puts Errortest::error('some=
error')"
ruby:
zoso@velutha:~/tmp/swig$
------------------------------------- >8 --------------------------------=
-----

When I rename the "error" function to "error2", it works great :-?

Also, if I remove the extern "C" declarations (from both errortest.{h,=
i}, I
don't know if it makes sense leaving it in errortest.i) but leave the fun=
ction
as "error", it works, too (note that I tried both with C and C++, hence t=
he
errortest.c{,xx} file and the $(CPP) variable in the Makefile).

Can anyone shed some light on this?

--=20
Esteban Manchado Vel=E1zquez <[email protected]> - http://www.foton.es
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es

 

[Steven Jenkins]

Hi,
=20
I'm doing some experiments with SWIG (trying to make a Ruby interfac= e for
MuSE low-level sound classes), and I'm having some problems.
=20
One of them is really weird: it seems that there are problems with e= xtern
"C" declarations (from C++) and with functions _named_ "error" (namely,= that
when you try to call the function, the interpreter aborts, without exce= ptions
or anything).

I played around with this a little yesterday afternoon and saw exactly=20
the problem you desribe on Gentoo Linux. I ran gcc -E looking for a=20
global 'error' pulled in from some header file, but found nothing. I'm=20
stumped.

You might try it without SWIG--just write your own version of=20
_wrap_error() using the Ruby C API. I suspect it'll have the same=20
problem, but if not, you'll know the problem is with SWIG.

Steve

 

[Esteban Manchado Velázquez]

=20
I played around with this a little yesterday afternoon and saw exactly=20
the problem you desribe on Gentoo Linux. I ran gcc -E looking for a=20
global 'error' pulled in from some header file, but found nothing. I'm=20
stumped.

Thanks for trying

You might try it without SWIG--just write your own version of=20
_wrap_error() using the Ruby C API. I suspect it'll have the same=20
problem, but if not, you'll know the problem is with SWIG.

OK, I'll try that. Thanks again!

--=20
Esteban Manchado Vel=E1zquez <[email protected]> - http://www.foton.es
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es

 

[Esteban Manchado Velázquez]

=20
I played around with this a little yesterday afternoon and saw exactly=20
the problem you desribe on Gentoo Linux. I ran gcc -E looking for a=20
global 'error' pulled in from some header file, but found nothing. I'm=20
stumped.
=20
You might try it without SWIG--just write your own version of=20
_wrap_error() using the Ruby C API. I suspect it'll have the same=20
problem, but if not, you'll know the problem is with SWIG.

The only conclusion I've reached is that a function named "error" can'=
t be
declared in C (and I guess this goes for _every_ Ruby C extension), proba=
bly
because it's declared somewhere. The problem is, I don't know where and I
don't have the slightliest idea of where to find it (in the interpreter
code?).

As I was told by a friend, it probably works in C++ (without the exter=
n "C"
thing) because of C++ function name mangling.

I guess I'll have to remove the extern "C" declarations from MuSE, to =
be
able to make the Ruby interface :-/

Best regards, and thanks again for trying...

--=20
Esteban Manchado Vel=E1zquez <[email protected]> - http://www.foton.es
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es