Menu
▾
▴
swig-devel
|
From: Jitka P. <jpl...@re...> - 2019-02-18 13:27:32
|
Hi,
I am trying to rebuild all packages, which need SWIG, in Fedora with the latest version of SWIG from git.
I found that ldns and libsolv fails with similar error.
In file included from /usr/include/python3.7m/pytime.h:6,
from /usr/include/python3.7m/Python.h:77,
from ./contrib/python/ldns_wrapper.c:154:
./contrib/python/ldns_wrapper.c: In function '_wrap_ldns_key_set_pubkey_owner':
./contrib/python/ldns_wrapper.c:37784:51: error: 'obj1' undeclared (first use in this function); did you mean 'j1'?
37784 | ldns_key_set_pubkey_owner(arg1,arg2); Py_INCREF(obj1);
| ^~~~
The wrong code was added by this line in ldns_key.i:
%exception ldns_key_set_pubkey_owner(ldns_key *k, ldns_rdf *r) %{ $action Py_INCREF(obj1); %}
The differences in function '_wrap_ldns_key_set_pubkey_owner' generated by SWIG 3.0.12/4.0.0
can be found in attached files. Most of the occurrences 'objX' were replaces by 'swig_obj[X]'
except the line above.
I can fix it by changing 'obj1' to 'swig_obj[1]' in ldns_key.i. But I am not sure, if it is
the right way how to solve it.
Could you please look at it and let me know what is wrong?
Thank you,
Jitka Plesnikova
--
Jitka Plesnikova
Software Engineer
Red Hat
|
|
From: William S F. <ws...@fu...> - 2019-02-19 08:33:58
|
On Mon, 18 Feb 2019 at 13:27, Jitka Plesnikova <jpl...@re...> wrote:
> Hi,
>
> I am trying to rebuild all packages, which need SWIG, in Fedora with the latest version of SWIG from git.
>
> I found that ldns and libsolv fails with similar error.
>
> In file included from /usr/include/python3.7m/pytime.h:6,
> from /usr/include/python3.7m/Python.h:77,
> from ./contrib/python/ldns_wrapper.c:154:
> ./contrib/python/ldns_wrapper.c: In function '_wrap_ldns_key_set_pubkey_owner':
> ./contrib/python/ldns_wrapper.c:37784:51: error: 'obj1' undeclared (first use in this function); did you mean 'j1'?
> 37784 | ldns_key_set_pubkey_owner(arg1,arg2); Py_INCREF(obj1);
> | ^~~~
>
> The wrong code was added by this line in ldns_key.i:
>
> %exception ldns_key_set_pubkey_owner(ldns_key *k, ldns_rdf *r) %{ $action Py_INCREF(obj1); %}
>
> The differences in function '_wrap_ldns_key_set_pubkey_owner' generated by SWIG 3.0.12/4.0.0
> can be found in attached files. Most of the occurrences 'objX' were replaces by 'swig_obj[X]'
> except the line above.
>
> I can fix it by changing 'obj1' to 'swig_obj[1]' in ldns_key.i. But I am not sure, if it is
> the right way how to solve it.
>
> Could you please look at it and let me know what is wrong?
>
>
>
Hi Jitka
I'm pleased to hear you are rebuilding all Redhat packages with swig 4, I
was going to see if you could do it before the release.
What is happening in ldns is hard coding of the generated variables. You
could change obj1 to swig_obj[1], but then it won't work with earlier
versions of SWIG. SWIG removes the "-modern -fastunpack" options which
would have generated swig_obj[1] instead of obj1 in swig-3.0.12. Do you
think ldns and libsolv needs changes to work with older versions of SWIG?
If so, we could use a better approach: %typemap(argout) ldns_rdf *r
"Py_INCREF($input);". However, this typemap will then get applied
unintentionally to other functions that use this type and variable name
combination if we are not careful. I can make a patch if you like to get
this right. What do you think?
William
|
|
From: Jitka P. <jpl...@re...> - 2019-02-19 11:00:58
|
> > Hi Jitka > > I'm pleased to hear you are rebuilding all Redhat packages with swig > 4, I was going to see if you could do it before the release. > > What is happening in ldns is hard coding of the generated variables. > You could change obj1 to swig_obj[1], but then it won't work with > earlier versions of SWIG. SWIG removes the "-modern -fastunpack" > options which would have generated swig_obj[1] instead of obj1 in > swig-3.0.12. Do you think ldns and libsolv needs changes to work with > older versions of SWIG? If so, we could use a better approach: > %typemap(argout) ldns_rdf *r "Py_INCREF($input);". However, this > typemap will then get applied unintentionally to other functions that > use this type and variable name combination if we are not careful. I > can make a patch if you like to get this right. What do you think? > > William Hi, patching of libsolv and ldns looks good to me and it think it is safer for all. I prepared patches which update code due to value of SWIG_VERSION, so they works for swig 3.0.12 and 4.0.0. There are more packages which failed during the rebuild. I will provide you the list of them and the build log with the failures. Regards, Jitka -- Jitka Plesnikova Software Engineer Red Hat |
|
From: William S F. <ws...@fu...> - 2019-02-21 18:11:00
|
On Tue, 19 Feb 2019 at 11:00, Jitka Plesnikova <jpl...@re...> wrote: > > Hi Jitka > > I'm pleased to hear you are rebuilding all Redhat packages with swig 4, I > was going to see if you could do it before the release. > > What is happening in ldns is hard coding of the generated variables. You > could change obj1 to swig_obj[1], but then it won't work with earlier > versions of SWIG. SWIG removes the "-modern -fastunpack" options which > would have generated swig_obj[1] instead of obj1 in swig-3.0.12. Do you > think ldns and libsolv needs changes to work with older versions of SWIG? > If so, we could use a better approach: %typemap(argout) ldns_rdf *r > "Py_INCREF($input);". However, this typemap will then get applied > unintentionally to other functions that use this type and variable name > combination if we are not careful. I can make a patch if you like to get > this right. What do you think? > > William > > Hi, > patching of libsolv and ldns looks good to me and it think it is safer for > all. > > I prepared patches which update code due to value of SWIG_VERSION, so they > works for swig 3.0.12 and 4.0.0. > Using SWIG_VERSION and hard coding those variables could be used but I'd still consider using the hard coded variables names as less than ideal. Changes to use %typemap(argout) would be more sustainable. I can help do that if need be. > There are more packages which failed during the rebuild. > I will provide you the list of them and the build log with the failures. > Are there other failing packages apart from nordugrid-arc? If so, please send the details. William |
|
From: Jitka P. <jpl...@re...> - 2019-02-22 07:57:09
|
On 2/21/19 7:10 PM, William S Fulton wrote: > > > On Tue, 19 Feb 2019 at 11:00, Jitka Plesnikova <jpl...@re... > <mailto:jpl...@re...>> wrote: > >> >> Hi Jitka >> >> I'm pleased to hear you are rebuilding all Redhat packages with >> swig 4, I was going to see if you could do it before the release. >> >> What is happening in ldns is hard coding of the generated >> variables. You could change obj1 to swig_obj[1], but then it >> won't work with earlier versions of SWIG. SWIG removes the >> "-modern -fastunpack" options which would have generated >> swig_obj[1] instead of obj1 in swig-3.0.12. Do you think ldns and >> libsolv needs changes to work with older versions of SWIG? If so, >> we could use a better approach: %typemap(argout) ldns_rdf *r >> "Py_INCREF($input);". However, this typemap will then get applied >> unintentionally to other functions that use this type and >> variable name combination if we are not careful. I can make a >> patch if you like to get this right. What do you think? >> >> William > > Hi, > > patching of libsolv and ldns looks good to me and it think it is > safer for all. > > I prepared patches which update code due to value of SWIG_VERSION, > so they works for swig 3.0.12 and 4.0.0. > > > Using SWIG_VERSION and hard coding those variables could be used but > I'd still consider using the hard coded variables names as less than > ideal. Changes to use %typemap(argout) would be more sustainable. I > can help do that if need be. If you can help me with it I will appreciate it. > > > > There are more packages which failed during the rebuild. > I will provide you the list of them and the build log with the > failures. > > > > Are there other failing packages apart from nordugrid-arc? If so, > please send the details. I will add build.log and source rpm for packages which starts failed with SWIG 4 here: https://jplesnik.fedorapeople.org/swig-4/ I added there COPASI and libprelude, which failed with 'invalid conversion' error: COPASI BUILDSTDERR: /builddir/build/BUILD/COPASI-Build-197/build/copasi/bindings/python/copasi_wrapper.cpp: In function 'PyObject* _wrap_new_CCopasiMessage(PyObject*, PyObject*)': BUILDSTDERR: /builddir/build/BUILD/COPASI-Build-197/build/copasi/bindings/python/copasi_wrapper.cpp:18828:51: error: invalid conversion from 'PyObject*' {aka '_object*'} to 'Py_ssize_t' {aka 'long int'} [-fpermissive] BUILDSTDERR: 18828 | return _wrap_new_CCopasiMessage__SWIG_0(self, args); BUILDSTDERR: | ^~~~ BUILDSTDERR: | | BUILDSTDERR: | PyObject* {aka _object*} BUILDSTDERR: /builddir/build/BUILD/COPASI-Build-197/build/copasi/bindings/python/copasi_wrapper.cpp:18828:55: error: too few arguments to function 'PyObject* _wrap_new_CCopasiMessage__SWIG_0(PyObject*, Py_ssize_t, PyObject**)' BUILDSTDERR: 18828 | return _wrap_new_CCopasiMessage__SWIG_0(self, args); libprelude BUILDSTDERR: _prelude.cxx: At global scope: BUILDSTDERR: _prelude.cxx:19775:5: error: invalid conversion from ‘PyObject* (*)(PyObject*, PyObject*)’ {aka ‘_object* (*)(_object*, _object*)’} to ‘hashfunc’ {aka ‘long int (*)(_object*)’} [-fpermissive] BUILDSTDERR: 19775 | _wrap_IDMEFValue_getType, /* tp_hash */ BUILDSTDERR: | ^~~~~~~~~~~~~~~~~~~~~~~~ BUILDSTDERR: | | BUILDSTDERR: | PyObject* (*)(PyObject*, PyObject*) {aka _object* (*)(_object*, _object*)} I tried to send you rest of failures today and also add the latest build.log. Thanks, Jitka -- Jitka Plesnikova Software Engineer Red Hat |
|
From: William S F. <ws...@fu...> - 2019-02-24 22:30:29
|
On Fri, 22 Feb 2019 at 07:56, Jitka Plesnikova <jpl...@re...> wrote: > > On 2/21/19 7:10 PM, William S Fulton wrote: > > > > On Tue, 19 Feb 2019 at 11:00, Jitka Plesnikova <jpl...@re...> > wrote: > >> >> Hi Jitka >> >> I'm pleased to hear you are rebuilding all Redhat packages with swig 4, I >> was going to see if you could do it before the release. >> >> What is happening in ldns is hard coding of the generated variables. You >> could change obj1 to swig_obj[1], but then it won't work with earlier >> versions of SWIG. SWIG removes the "-modern -fastunpack" options which >> would have generated swig_obj[1] instead of obj1 in swig-3.0.12. Do you >> think ldns and libsolv needs changes to work with older versions of SWIG? >> If so, we could use a better approach: %typemap(argout) ldns_rdf *r >> "Py_INCREF($input);". However, this typemap will then get applied >> unintentionally to other functions that use this type and variable name >> combination if we are not careful. I can make a patch if you like to get >> this right. What do you think? >> >> William >> >> Hi, >> patching of libsolv and ldns looks good to me and it think it is safer >> for all. >> >> I prepared patches which update code due to value of SWIG_VERSION, so >> they works for swig 3.0.12 and 4.0.0. >> > > Using SWIG_VERSION and hard coding those variables could be used but I'd > still consider using the hard coded variables names as less than ideal. > Changes to use %typemap(argout) would be more sustainable. I can help do > that if need be. > > If you can help me with it I will appreciate it. > > > > > >> There are more packages which failed during the rebuild. >> I will provide you the list of them and the build log with the failures. >> > > > Are there other failing packages apart from nordugrid-arc? If so, please > send the details. > > I will add build.log and source rpm for packages which starts failed with > SWIG 4 here: https://jplesnik.fedorapeople.org/swig-4/ > > I added there COPASI and libprelude, which failed with 'invalid > conversion' error: > > COPASI > > BUILDSTDERR: /builddir/build/BUILD/COPASI-Build-197/build/copasi/bindings/python/copasi_wrapper.cpp: In function 'PyObject* _wrap_new_CCopasiMessage(PyObject*, PyObject*)': > BUILDSTDERR: /builddir/build/BUILD/COPASI-Build-197/build/copasi/bindings/python/copasi_wrapper.cpp:18828:51: error: invalid conversion from 'PyObject*' {aka '_object*'} to 'Py_ssize_t' {aka 'long int'} [-fpermissive] > BUILDSTDERR: 18828 | return _wrap_new_CCopasiMessage__SWIG_0(self, args); > BUILDSTDERR: | ^~~~ > BUILDSTDERR: | | > BUILDSTDERR: | PyObject* {aka _object*} > BUILDSTDERR: /builddir/build/BUILD/COPASI-Build-197/build/copasi/bindings/python/copasi_wrapper.cpp:18828:55: error: too few arguments to function 'PyObject* _wrap_new_CCopasiMessage__SWIG_0(PyObject*, Py_ssize_t, PyObject**)' > BUILDSTDERR: 18828 | return _wrap_new_CCopasiMessage__SWIG_0(self, args); > > > libprelude > > BUILDSTDERR: _prelude.cxx: At global scope: > BUILDSTDERR: _prelude.cxx:19775:5: error: invalid conversion from ‘PyObject* (*)(PyObject*, PyObject*)’ {aka ‘_object* (*)(_object*, _object*)’} to ‘hashfunc’ {aka ‘long int (*)(_object*)’} [-fpermissive] > BUILDSTDERR: 19775 | _wrap_IDMEFValue_getType, /* tp_hash */ > BUILDSTDERR: | ^~~~~~~~~~~~~~~~~~~~~~~~ > BUILDSTDERR: | | > BUILDSTDERR: | PyObject* (*)(PyObject*, PyObject*) {aka _object* (*)(_object*, _object*)} > > These two are due to a bug in the way overloaded constructors (or functions) are handled by SWIG for Python when one of the constructors/functions contain varargs. It occurs when the first parsed constructor/function is not one of the vararg constructors/functions. I'll work out a fix and commit it in due course. William |
|
From: William S F. <ws...@fu...> - 2019-02-25 19:35:31
|
> There are more packages which failed during the rebuild. >>> I will provide you the list of them and the build log with the failures. >>> >> >> >> Are there other failing packages apart from nordugrid-arc? If so, please >> send the details. >> >> I will add build.log and source rpm for packages which starts failed with >> SWIG 4 here: https://jplesnik.fedorapeople.org/swig-4/ >> >> I added there COPASI and libprelude, which failed with 'invalid >> conversion' error: >> >> COPASI >> >> BUILDSTDERR: /builddir/build/BUILD/COPASI-Build-197/build/copasi/bindings/python/copasi_wrapper.cpp: In function 'PyObject* _wrap_new_CCopasiMessage(PyObject*, PyObject*)': >> BUILDSTDERR: /builddir/build/BUILD/COPASI-Build-197/build/copasi/bindings/python/copasi_wrapper.cpp:18828:51: error: invalid conversion from 'PyObject*' {aka '_object*'} to 'Py_ssize_t' {aka 'long int'} [-fpermissive] >> BUILDSTDERR: 18828 | return _wrap_new_CCopasiMessage__SWIG_0(self, args); >> BUILDSTDERR: | ^~~~ >> BUILDSTDERR: | | >> BUILDSTDERR: | PyObject* {aka _object*} >> BUILDSTDERR: /builddir/build/BUILD/COPASI-Build-197/build/copasi/bindings/python/copasi_wrapper.cpp:18828:55: error: too few arguments to function 'PyObject* _wrap_new_CCopasiMessage__SWIG_0(PyObject*, Py_ssize_t, PyObject**)' >> BUILDSTDERR: 18828 | return _wrap_new_CCopasiMessage__SWIG_0(self, args); >> >> >> libprelude >> >> BUILDSTDERR: _prelude.cxx: At global scope: >> BUILDSTDERR: _prelude.cxx:19775:5: error: invalid conversion from ‘PyObject* (*)(PyObject*, PyObject*)’ {aka ‘_object* (*)(_object*, _object*)’} to ‘hashfunc’ {aka ‘long int (*)(_object*)’} [-fpermissive] >> BUILDSTDERR: 19775 | _wrap_IDMEFValue_getType, /* tp_hash */ >> BUILDSTDERR: | ^~~~~~~~~~~~~~~~~~~~~~~~ >> BUILDSTDERR: | | >> BUILDSTDERR: | PyObject* (*)(PyObject*, PyObject*) {aka _object* (*)(_object*, _object*)} >> >> > These two are due to a bug in the way overloaded constructors (or > functions) are handled by SWIG for Python when one of the > constructors/functions contain varargs. It occurs when the first parsed > constructor/function is not one of the vararg constructors/functions. I'll > work out a fix and commit it in due course. > > Fixed now in commit 83ea2280e2e99ecafa2e3d2e041548a2f02aa19b. Jitka, thanks for testing and reporting this before the release went out. William |
|
From: William S F. <ws...@fu...> - 2019-03-04 22:21:24
|
On Wed, 27 Feb 2019 at 13:00, Jitka Plesnikova <jpl...@re...> wrote: > > On 2/25/19 8:34 PM, William S Fulton wrote: > > > > >> There are more packages which failed during the rebuild. >>>> I will provide you the list of them and the build log with the failures. >>>> >>> >>> >>> Are there other failing packages apart from nordugrid-arc? If so, please >>> send the details. >>> >>> I will add build.log and source rpm for packages which starts failed >>> with SWIG 4 here: https://jplesnik.fedorapeople.org/swig-4/ >>> >>> I added there COPASI and libprelude, which failed with 'invalid >>> conversion' error: >>> >>> COPASI >>> >>> BUILDSTDERR: /builddir/build/BUILD/COPASI-Build-197/build/copasi/bindings/python/copasi_wrapper.cpp: In function 'PyObject* _wrap_new_CCopasiMessage(PyObject*, PyObject*)': >>> BUILDSTDERR: /builddir/build/BUILD/COPASI-Build-197/build/copasi/bindings/python/copasi_wrapper.cpp:18828:51: error: invalid conversion from 'PyObject*' {aka '_object*'} to 'Py_ssize_t' {aka 'long int'} [-fpermissive] >>> BUILDSTDERR: 18828 | return _wrap_new_CCopasiMessage__SWIG_0(self, args); >>> BUILDSTDERR: | ^~~~ >>> BUILDSTDERR: | | >>> BUILDSTDERR: | PyObject* {aka _object*} >>> BUILDSTDERR: /builddir/build/BUILD/COPASI-Build-197/build/copasi/bindings/python/copasi_wrapper.cpp:18828:55: error: too few arguments to function 'PyObject* _wrap_new_CCopasiMessage__SWIG_0(PyObject*, Py_ssize_t, PyObject**)' >>> BUILDSTDERR: 18828 | return _wrap_new_CCopasiMessage__SWIG_0(self, args); >>> >>> >>> libprelude >>> >>> BUILDSTDERR: _prelude.cxx: At global scope: >>> BUILDSTDERR: _prelude.cxx:19775:5: error: invalid conversion from ‘PyObject* (*)(PyObject*, PyObject*)’ {aka ‘_object* (*)(_object*, _object*)’} to ‘hashfunc’ {aka ‘long int (*)(_object*)’} [-fpermissive] >>> BUILDSTDERR: 19775 | _wrap_IDMEFValue_getType, /* tp_hash */ >>> BUILDSTDERR: | ^~~~~~~~~~~~~~~~~~~~~~~~ >>> BUILDSTDERR: | | >>> BUILDSTDERR: | PyObject* (*)(PyObject*, PyObject*) {aka _object* (*)(_object*, _object*)} >>> >>> >> These two are due to a bug in the way overloaded constructors (or >> functions) are handled by SWIG for Python when one of the >> constructors/functions contain varargs. It occurs when the first parsed >> constructor/function is not one of the vararg constructors/functions. I'll >> work out a fix and commit it in due course. >> >> > Fixed now in commit 83ea2280e2e99ecafa2e3d2e041548a2f02aa19b. Jitka, > thanks for testing and reporting this before the release went out. > > Hi William, > > I check the fix and it works for COPASI, but libprelude still fails with > error: > > make[3]: Leaving directory '/builddir/build/BUILD/libprelude-4.1.0/bindings/python' > _prelude.cxx: In function ‘int IDMEFValue_to_SWIG(PyObject*, const Prelude::IDMEFValue&, void*, PyObject**)’: > _prelude.cxx:5886:58: warning: enum constant in boolean context [-Wint-in-bool-context] > 5886 | else if ( t == IDMEF_DATA_TYPE_UINT32 || IDMEF_DATA_TYPE_INT ) > > I'd assume that this should be: else if ( t == IDMEF_DATA_TYPE_UINT32 || t == IDMEF_DATA_TYPE_INT ) Looks like a new useful gcc warning. > | ^~~~~~~~~~~~~~~~~~~ > _prelude.cxx: At global scope: > _prelude.cxx:19775:5: error: invalid conversion from ‘PyObject* (*)(PyObject*, PyObject*)’ {aka ‘_object* (*)(_object*, _object*)’} to ‘hashfunc’ {aka ‘long int (*)(_object*)’} [-fpermissive] > 19775 | _wrap_IDMEFValue_getType, /* tp_hash */ > | ^~~~~~~~~~~~~~~~~~~~~~~~ > | | > | PyObject* (*)(PyObject*, PyObject*) {aka _object* (*)(_object*, _object*)} > error: command 'g++' failed with exit status 1 > > swig-4.0.0 no longer generates a cast for the slots provided by the "python:slot" feature. This change should flush out bad code at compile time rather than runtime. In this case it does indeed do as intended as the error shows above. Previously the output blindly cast to hashfunc: (hashfunc) _wrap_IDMEFValue_getType, /* tp_hash */ A closure function is needed and It should be: _wrap_IDMEFValue_getType_hashfunc_closure,/* tp_hash */ with the support code: SWIGPY_HASHFUNC_CLOSURE(_wrap_IDMEFValue_getType) /* defines _wrap_IDMEFValue_getType_hashfunc_closure */ #define SWIGPY_HASHFUNC_CLOSURE(wrapper) \ SWIGINTERN Py_hash_t \ wrapper##_hashfunc_closure(PyObject *a) { \ return SwigPyBuiltin_hashfunc_closure(wrapper, a); \ } SWIGINTERN Py_hash_t SwigPyBuiltin_hashfunc_closure(SwigPyWrapperFunction wrapper, PyObject *a) { PyObject *pyresult; Py_hash_t result; pyresult = wrapper(a, NULL); if (!pyresult) return -1; result = SWIG_PyNumber_AsPyHash(pyresult); Py_DECREF(pyresult); return result; } Anyway, all this is easily fixed by changing %feature("python:slot", "tp_hash") Prelude::IDMEFValue::getType; to %feature("python:slot", "tp_hash", functype="hashfunc") Prelude::IDMEFValue::getType; in libprelude-4.1.0/bindings/python/libpreludecpp-python.i I'd expect it to fix some runtime problems with calls to hash of any IDMEFValue instances too as currently the behaviour is undefined. William |
|
From: William S F. <ws...@fu...> - 2019-03-15 08:10:42
|
On Wed, 27 Feb 2019 at 13:00, Jitka Plesnikova <jpl...@re...> wrote: > > On 2/25/19 8:34 PM, William S Fulton wrote: > > > > >> There are more packages which failed during the rebuild. >>>> I will provide you the list of them and the build log with the failures. >>>> >>> >>> >>> Are there other failing packages apart from nordugrid-arc? If so, please >>> send the details. >>> >>> I will add build.log and source rpm for packages which starts failed >>> with SWIG 4 here: https://jplesnik.fedorapeople.org/swig-4/ >>> >>> I added there COPASI and libprelude, which failed with 'invalid >>> conversion' error: >>> >>> COPASI >>> >>> BUILDSTDERR: /builddir/build/BUILD/COPASI-Build-197/build/copasi/bindings/python/copasi_wrapper.cpp: In function 'PyObject* _wrap_new_CCopasiMessage(PyObject*, PyObject*)': >>> BUILDSTDERR: /builddir/build/BUILD/COPASI-Build-197/build/copasi/bindings/python/copasi_wrapper.cpp:18828:51: error: invalid conversion from 'PyObject*' {aka '_object*'} to 'Py_ssize_t' {aka 'long int'} [-fpermissive] >>> BUILDSTDERR: 18828 | return _wrap_new_CCopasiMessage__SWIG_0(self, args); >>> BUILDSTDERR: | ^~~~ >>> BUILDSTDERR: | | >>> BUILDSTDERR: | PyObject* {aka _object*} >>> BUILDSTDERR: /builddir/build/BUILD/COPASI-Build-197/build/copasi/bindings/python/copasi_wrapper.cpp:18828:55: error: too few arguments to function 'PyObject* _wrap_new_CCopasiMessage__SWIG_0(PyObject*, Py_ssize_t, PyObject**)' >>> BUILDSTDERR: 18828 | return _wrap_new_CCopasiMessage__SWIG_0(self, args); >>> >>> >>> libprelude >>> >>> BUILDSTDERR: _prelude.cxx: At global scope: >>> BUILDSTDERR: _prelude.cxx:19775:5: error: invalid conversion from ‘PyObject* (*)(PyObject*, PyObject*)’ {aka ‘_object* (*)(_object*, _object*)’} to ‘hashfunc’ {aka ‘long int (*)(_object*)’} [-fpermissive] >>> BUILDSTDERR: 19775 | _wrap_IDMEFValue_getType, /* tp_hash */ >>> BUILDSTDERR: | ^~~~~~~~~~~~~~~~~~~~~~~~ >>> BUILDSTDERR: | | >>> BUILDSTDERR: | PyObject* (*)(PyObject*, PyObject*) {aka _object* (*)(_object*, _object*)} >>> >>> >> These two are due to a bug in the way overloaded constructors (or >> functions) are handled by SWIG for Python when one of the >> constructors/functions contain varargs. It occurs when the first parsed >> constructor/function is not one of the vararg constructors/functions. I'll >> work out a fix and commit it in due course. >> >> > Fixed now in commit 83ea2280e2e99ecafa2e3d2e041548a2f02aa19b. Jitka, > thanks for testing and reporting this before the release went out. > > Hi William, > > I check the fix and it works for COPASI, but libprelude still fails with > error: > > make[3]: Leaving directory '/builddir/build/BUILD/libprelude-4.1.0/bindings/python' > _prelude.cxx: In function ‘int IDMEFValue_to_SWIG(PyObject*, const Prelude::IDMEFValue&, void*, PyObject**)’: > _prelude.cxx:5886:58: warning: enum constant in boolean context [-Wint-in-bool-context] > 5886 | else if ( t == IDMEF_DATA_TYPE_UINT32 || IDMEF_DATA_TYPE_INT ) > | ^~~~~~~~~~~~~~~~~~~ > _prelude.cxx: At global scope: > _prelude.cxx:19775:5: error: invalid conversion from ‘PyObject* (*)(PyObject*, PyObject*)’ {aka ‘_object* (*)(_object*, _object*)’} to ‘hashfunc’ {aka ‘long int (*)(_object*)’} [-fpermissive] > 19775 | _wrap_IDMEFValue_getType, /* tp_hash */ > | ^~~~~~~~~~~~~~~~~~~~~~~~ > | | > | PyObject* (*)(PyObject*, PyObject*) {aka _object* (*)(_object*, _object*)} > error: command 'g++' failed with exit status 1 > > > BTW, COPASI is still not successfully build, because building of R > bindings fails with similar error like libsbml and libsedml > > The R package could not be created, the following error occured > > * installing *source* package 'COPASI' ... > ** R > ** inst > ** byte-compile and prepare package for lazy loading > Error in loadNamespace(name) : there is no package called 'CCopasiTask' > Error : unable to load R code in package 'COPASI' > ERROR: lazy loading failed for package 'COPASI' > > > The error is related to commit '[R] Improve handling of enums > (4236b1ec9)'. > The R enum handling is indeed broken and Richard's patch at https://github.com/swig/swig/pull/1328 fixes it again. The patch has had some recent additions which I'll review next as it needs to go into the 4.0.0 release. I'll reply when it has been committed to master. William |
|
From: William S F. <ws...@fu...> - 2019-03-19 07:13:02
|
On Fri, 15 Mar 2019 at 10:22, Jitka Plesnikova <jpl...@re...> wrote:
>
> Hi William,
>>
>> I check the fix and it works for COPASI, but libprelude still fails with
>> error:
>>
>> make[3]: Leaving directory '/builddir/build/BUILD/libprelude-4.1.0/bindings/python'
>> _prelude.cxx: In function ‘int IDMEFValue_to_SWIG(PyObject*, const Prelude::IDMEFValue&, void*, PyObject**)’:
>> _prelude.cxx:5886:58: warning: enum constant in boolean context [-Wint-in-bool-context]
>> 5886 | else if ( t == IDMEF_DATA_TYPE_UINT32 || IDMEF_DATA_TYPE_INT )
>> | ^~~~~~~~~~~~~~~~~~~
>> _prelude.cxx: At global scope:
>> _prelude.cxx:19775:5: error: invalid conversion from ‘PyObject* (*)(PyObject*, PyObject*)’ {aka ‘_object* (*)(_object*, _object*)’} to ‘hashfunc’ {aka ‘long int (*)(_object*)’} [-fpermissive]
>> 19775 | _wrap_IDMEFValue_getType, /* tp_hash */
>> | ^~~~~~~~~~~~~~~~~~~~~~~~
>> | |
>> | PyObject* (*)(PyObject*, PyObject*) {aka _object* (*)(_object*, _object*)}
>> error: command 'g++' failed with exit status 1
>>
>>
>> BTW, COPASI is still not successfully build, because building of R
>> bindings fails with similar error like libsbml and libsedml
>>
>> The R package could not be created, the following error occured
>>
>> * installing *source* package 'COPASI' ...
>> ** R
>> ** inst
>> ** byte-compile and prepare package for lazy loading
>> Error in loadNamespace(name) : there is no package called 'CCopasiTask'
>> Error : unable to load R code in package 'COPASI'
>> ERROR: lazy loading failed for package 'COPASI'
>>
>>
>> The error is related to commit '[R] Improve handling of enums
>> (4236b1ec9)'.
>>
>
> Hi Jitka
>
> I don't see this building COPASI, I get a mysterious error:
>
> [100%] Built target libCOPASIUI
> make[1]: Leaving directory '/builddir/build/BUILD/COPASI-Build-197/build'
> BUILDSTDERR: make: *** [Makefile:166: all] Error 2
> BUILDSTDERR: error: Bad exit status from /var/tmp/rpm-tmp.n6gWrW (%build)
> RPM build errors:
> BUILDSTDERR: Bad exit status from /var/tmp/rpm-tmp.n6gWrW (%build)
> Child return code was: 1
> EXCEPTION: [Error()]
> Traceback (most recent call last):
> File "/usr/lib/python3.7/site-packages/mockbuild/trace_decorator.py",
> line 96, in trace
> result = func(*args, **kw)
> File "/usr/lib/python3.7/site-packages/mockbuild/util.py", line 700, in
> do
> raise exception.Error("Command failed: \n # %s\n%s" % (command,
> output), child.returncode)
> mockbuild.exception.Error: Command failed:
> # /usr/bin/systemd-nspawn -q -M eb37f14f60ab4ca881e5c60d21589579 -D
> /var/lib/mock/fedora-rawhide-x86_64/root -a --capability=cap_ipc_lock
> --bind=/tmp/mock-resolv.xi8y7j4f:/etc/resolv.conf --setenv=TERM=vt100
> --setenv=SHELL=/bin/bash --setenv=HOME=/builddir --setenv=HOSTNAME=mock
> --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin --setenv=PROMPT_COMMAND=printf
> "\033]0;<mock-chroot>\007" --setenv=PS1=<mock-chroot> \s-\v\$
> --setenv=LANG=en_GB.UTF-8 -u mockbuild bash --login -c /usr/bin/rpmbuild
> -bb --target x86_64 --nodeps /builddir/build/SPECS/COPASI.spec
>
> and the R output you show above isn't in the log. I'm using
> COPASI-4.24.197-6.fc30.src.rpm
> <https://jplesnik.fedorapeople.org/swig-4/COPASI/COPASI-4.24.197-6.fc30.src.rpm>
> that you provided. Do you have a source package that replicates the R
> problem? I'll try the libsbml and libsedml packages next to diagnose the R
> enum problem. This isn't as easy to debug as it looks like I need to build
> two independent packages and I really don't know how they depend on each
> other :(.
>
> William
>
>
> Hi,
>
> I am not able to reproduce your error. If you can give me whole build.log,
> it will be useful.
>
> I uploaded the latest source rpm on web and it still failed on R bindings.
> To get the R error and save some time, just disable some bindings:
> mock -r fedora-rawhide-x86_64 --no-clean --define "with_python3 0"
> --define "with_perl 0" --define "with_mono 0" --rebuild
> COPASI-4.24.197-8.fc31.src.rpm
>
>
> Few days ago, I tested building of libsedml, libsbml and COPASI with
> changes related to #1328 and they were build successfully.
>
> So, the last build issue, which I have, is test error in nordugrid-arc
>
> BUILDSTDERR: ERROR: test_cancel (__main__.JobSupervisorTest)
> BUILDSTDERR: ----------------------------------------------------------------------
> BUILDSTDERR: Traceback (most recent call last):
> BUILDSTDERR: File "./JobSupervisorTest.py", line 72, in test_cancel
> BUILDSTDERR: arc.JobControllerPluginTestACCControl.cancelStatus = True
> BUILDSTDERR: File "/builddir/build/BUILD/nordugrid-arc-5.4.3/python/python/arc/compute.py", line 186, in __setattr__
> BUILDSTDERR: orig_attr.fset(value)
> BUILDSTDERR: TypeError: in variable 'Arc::JobControllerPluginTestACCControl::cancelStatus' of type 'bool'
>
>
Jitka, #1328 is now merged into master.
William
|
|
From: William S F. <ws...@fu...> - 2019-03-21 08:13:28
|
On Tue, 19 Mar 2019 at 07:12, William S Fulton <ws...@fu...> wrote: > > > On Fri, 15 Mar 2019 at 10:22, Jitka Plesnikova <jpl...@re...> > wrote: > >> >> > So, the last build issue, which I have, is test error in nordugrid-arc >> >> BUILDSTDERR: ERROR: test_cancel (__main__.JobSupervisorTest) >> BUILDSTDERR: ---------------------------------------------------------------------- >> BUILDSTDERR: Traceback (most recent call last): >> BUILDSTDERR: File "./JobSupervisorTest.py", line 72, in test_cancel >> BUILDSTDERR: arc.JobControllerPluginTestACCControl.cancelStatus = True >> BUILDSTDERR: File "/builddir/build/BUILD/nordugrid-arc-5.4.3/python/python/arc/compute.py", line 186, in __setattr__ >> BUILDSTDERR: orig_attr.fset(value) >> BUILDSTDERR: TypeError: in variable 'Arc::JobControllerPluginTestACCControl::cancelStatus' of type 'bool' >> >> The nordugrid-arc wrappers use a class called StaticPropertyWrapper which implements static variable wrappers in a customised way. Without going into too many details StaticPropertyWrapper.__setattr__ calls the setter directly via the low-level set function that SWIG generates. This stopped working when we switched to using fastunpack for function calls by default. I've fixed it in https://github.com/swig/swig/commit/826f1448b838bc3efadf2f1cc93e614426e104dd William |
Thanks for helping keep SourceForge clean.
X