Following is output from an attempt to create a binding to php5.4 (5.4.0~rc6-1) using swig v2.0.4-4 and also using the swig svn version 12901. This was done in debian testing (wheezy) with the php5 package installed from debian experimental. See the patch proposed at: http://www.graphviz.org/mantisbt/view.php?id=2177
make[2]: Entering directory `.../libhdate/libhdate-now/trunk/libhdate/bindings/php'
swig -php5 -c++ hdate.i
g++ -I../../src `php-config --includes` -fpic -c hdate_wrap.cpp
hdate_wrap.cpp: In function ‘void* SWIG_ZTS_ConvertResourcePtr(zval*, swig_type_info*, int)’:
hdate_wrap.cpp:933:65: error: invalid conversion from ‘const char*’ to ‘char*’ [-fpermissive]
make[2]: *** [hdate.so] Error 1
make[2]: Leaving directory `...//libhdate/libhdate-now/trunk/libhdate/bindings/php'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `...//libhdate/libhdate-now/trunk/libhdate/bindings'
make: *** [all-recursive] Error 1
As a comment on the graphviz ticket notes, this is already fixed in SWIG SVN trunk - the revision for it was 12724 (which was shortly after the 2.0.4 release):
$ svn diff -c12724
Index: Lib/php/phprun.swg
===================================================================
--- Lib/php/phprun.swg (revision 12723)
+++ Lib/php/phprun.swg (revision 12724)
@@ -142,7 +142,7 @@
result = zend_lookup_class(classname, SWIG_PREFIX_LEN + type_name_len, &ce TSRMLS_CC);
efree(classname);
} else {
- result = zend_lookup_class(type_name, type_name_len, &ce TSRMLS_CC);
+ result = zend_lookup_class((char *)type_name, type_name_len, &ce TSRMLS_CC);
}
if (result != SUCCESS) {
/* class does not exist */
As a comment on the graphviz ticket notes, this is already fixed in SWIG SVN trunk - the revision for it was 12724 (which was shortly after the 2.0.4 release):
$ svn diff -c12724
Index: Lib/php/phprun.swg
===================================================================
--- Lib/php/phprun.swg (revision 12723)
+++ Lib/php/phprun.swg (revision 12724)
@@ -142,7 +142,7 @@
result = zend_lookup_class(classname, SWIG_PREFIX_LEN + type_name_len, &ce TSRMLS_CC);
efree(classname);
} else {
- result = zend_lookup_class(type_name, type_name_len, &ce TSRMLS_CC);
+ result = zend_lookup_class((char *)type_name, type_name_len, &ce TSRMLS_CC);
}
if (result != SUCCESS) {
/* class does not exist */
Olly, my bug report said that the failure also occurred in svn build 12901 ( > 12724 )
Well, that commit should address the issue in the graphviz ticket, and the comment on that ticket suggests it actually does. So if you're still seeing this, I think you must have hit a different issue.
What is line 933 of hdate_wrap.cpp?
Yes, That information is clearly provided in my initial bug report.
Sorry. My misunderstanding.
Line 933 reads:
type_name=zend_rsrc_list_get_rsrc_type(z->value.lval TSRMLS_CC);
Yeah, I needed to see the actual contents of the line so I can find the corresponding one in the SWIG macro library - the line number in the generated file isn't useful as I don't have that file, or the means to easy obtain the same version of it you have.
OK, that's a slightly different issue, but that one was fixed in r12710.
If you look at line 924 (or near there if I counted incorrectly), it should be:
const char *type_name;
If there's no "const" there, how are you running your build of SVN HEAD?
If you're running it from an uninstalled tree, then just running the built "swig" binary won't work correctly, as it won't know to use the in-tree swig macro library (which is where these fixes were made). You need to run the "preinst-swig" script instead.
If that isn't the issue, then I'm baffled. The lval is a long, and the TSRM stuff expands to a void*** argument or nothing, so the only char* involved in that line seems to be the return type.
The const was not present.
I had originally installed swig with apt-get. After I discovered mention of the graphviz patch, I checked out the latest svn commit, did an apt-get purge to clear out the version of swig I had installed, and went through the autogen/configure/make install procedure.
Is this issue fixed by version 2.0.5-1 of Debian's swig2.0 package?
I believe this issue is fixed, and there's been no feedback from submitter for over 7 months, so it seems unlikely we'll get confirmation now, and I don't see any point keeping this ticket open indefinitely.
If you're still seeing this issue with Debian package 2.0.5-1 or newer, please comment and I'll reopen.