Re: [C++-sig] Boost Python Question - Multiple Classes and Modules not appearing as attribute
Hi, "Cplusplus-sig" schrieb am 09.09.2016 02:33:57: > Hi, > > And here is yet another person who seems to encounter the same issue: > http://stackoverflow.com/questions/9140572/c-boost-python-2-problems > > -Jon Python expects an init function for extension modules named initNAME where NAME is the name of the extension module, i.e. NAME.so. (see https://docs.python.org/2/extending/extending.html) BOOST_PYTHON_MODULE is boost.python's macro for automagically giving you such an init function. So in the directives - in the boost.python wrapper code: BOOST_PYTHON_MODULE(NAME) - in the Jamroot file: python-extension NAME (or maybe if you compile without bjam, in your g++ link step the -o Parameter: g++ -shared -oNAME.so -Wl,-h -Wl,NAME.so ... # don't know if the SONAME setting (-Wl,-h -Wl,NAME.so) must also match as # Python dlopen()s the extension) NAME must be consistent. Holger Landesbank Baden-Wuerttemberg Anstalt des oeffentlichen Rechts Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz HRA 12704 Amtsgericht Stuttgart ___ Cplusplus-sig mailing list Cplusplus-sig@python.org https://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Boost Python Question - Multiple Classes and Modules not appearing as attribute
Hi, Thanks for the response. However, this example doesn’t work for me either if I set the shared object file to zoo.so. It doesn’t find the animal attribute: http://pyengr.readthedocs.io/en/latest/inter/bpy Can you explain why? Thanks. Jon > On Sep 9, 2016, at 4:07 AM, Holger Joukl wrote: > > Hi, > > "Cplusplus-sig" > schrieb am 09.09.2016 02:33:57: > >> Hi, >> >> And here is yet another person who seems to encounter the same issue: >> http://stackoverflow.com/questions/9140572/c-boost-python-2-problems >> >> -Jon > > Python expects an init function for extension modules named initNAME > where NAME is the name of the extension module, i.e. NAME.so. > (see https://docs.python.org/2/extending/extending.html) > > BOOST_PYTHON_MODULE is boost.python's macro for automagically giving you > such > an init function. > > So in the directives > - in the boost.python wrapper code: BOOST_PYTHON_MODULE(NAME) > - in the Jamroot file: python-extension NAME > (or maybe if you compile without bjam, in your g++ link step the -o > Parameter: > g++ -shared -oNAME.so -Wl,-h -Wl,NAME.so ... > # don't know if the SONAME setting (-Wl,-h -Wl,NAME.so) must also match as > # Python dlopen()s the extension) > > NAME must be consistent. > > Holger > > Landesbank Baden-Wuerttemberg > Anstalt des oeffentlichen Rechts > Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz > HRA 12704 > Amtsgericht Stuttgart > > ___ > Cplusplus-sig mailing list > Cplusplus-sig@python.org > https://mail.python.org/mailman/listinfo/cplusplus-sig ___ Cplusplus-sig mailing list Cplusplus-sig@python.org https://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Boost Python Question - Multiple Classes and Modules not appearing as attribute
On 09.09.2016 09:29, Jon Lederman wrote: > Hi, > > Thanks for the response. However, this example doesn’t work for me either if > I set the shared object file to zoo.so. It doesn’t find the animal attribute: > > http://pyengr.readthedocs.io/en/latest/inter/bpy > > Can you explain why? It's impossible to help you with so few details. Please describe *exactly* what you are doing. As I suggested already, the easiest thing is to come up with a minimal self-contained test case, then describe in detail how you compile it (what platform, what compiler command, etc.) so we can attempt to reproduce your observations. Stefan -- ...ich hab' noch einen Koffer in Berlin... ___ Cplusplus-sig mailing list Cplusplus-sig@python.org https://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Boost Python Question - Multiple Classes and Modules not appearing as attribute
Hi,
Let me be more explicit:
If my BOOST thing is: BOOST_PYTHON_MODULE(opus_encoder_strategy) and my
Makefile is like this:
all: opus_encoder_strategy.so
opus_encoder_strategy.so: opus_encoder_strategy.o
${CC} ${CInc} ${CLinkFlags} $^ -o $@
opus_encoder_strategy.o: opus_encoder_strategy.cpp
${CC} ${CFLAGS} ${CInc} opus_encoder_strategy.cpp -o
opus_encoder_strategy.o
and I build the name of the .so file to be opus_encoder_strategy.so, then I am
able to access the embedded class.
HOWEVER, if I change the BOOST thing to BOOST_PYTHON_MODULE(opus_strategy) and
my make file to this:
all: opus_strategy.so #lv2strategy.so
opus_strategy.so: opus_strategy.o
${CC} ${CInc} ${CLinkFlags} $^ -o $@
opus_strategy.o: opus_encoder_strategy.cpp
${CC} ${CFLAGS} ${CInc} opus_encoder_strategy.cpp -o opus_strategy.o
it doesn’t work.
NOTE that I am matching the BOOST thing to the name of the .so file, this case
opus_strategy.so
It seems that it is looking at something else like the actual name of the cpp
file or cpp file? This makes no sense to me and there is no documentation on
how to properly use this.
I am using python 3. Is this an issue. The documentation needs substantial
improvement and clarification.
Please advise ASAP.
-Jon
> On Sep 9, 2016, at 4:07 AM, Holger Joukl wrote:
>
> Hi,
>
> "Cplusplus-sig"
> schrieb am 09.09.2016 02:33:57:
>
>> Hi,
>>
>> And here is yet another person who seems to encounter the same issue:
>> http://stackoverflow.com/questions/9140572/c-boost-python-2-problems
>>
>> -Jon
>
> Python expects an init function for extension modules named initNAME
> where NAME is the name of the extension module, i.e. NAME.so.
> (see https://docs.python.org/2/extending/extending.html)
>
> BOOST_PYTHON_MODULE is boost.python's macro for automagically giving you
> such
> an init function.
>
> So in the directives
> - in the boost.python wrapper code: BOOST_PYTHON_MODULE(NAME)
> - in the Jamroot file: python-extension NAME
> (or maybe if you compile without bjam, in your g++ link step the -o
> Parameter:
> g++ -shared -oNAME.so -Wl,-h -Wl,NAME.so ...
> # don't know if the SONAME setting (-Wl,-h -Wl,NAME.so) must also match as
> # Python dlopen()s the extension)
>
> NAME must be consistent.
>
> Holger
>
> Landesbank Baden-Wuerttemberg
> Anstalt des oeffentlichen Rechts
> Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz
> HRA 12704
> Amtsgericht Stuttgart
>
> ___
> Cplusplus-sig mailing list
> Cplusplus-sig@python.org
> https://mail.python.org/mailman/listinfo/cplusplus-sig
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Boost Python Question - Multiple Classes and Modules not appearing as attribute
On 09.09.2016 10:00, Jon Lederman wrote:
> Hi,
>
> Let me be more explicit:
>
> If my BOOST thing is: BOOST_PYTHON_MODULE(opus_encoder_strategy) and my
> Makefile is like this:
>
> all: opus_encoder_strategy.so
>
> opus_encoder_strategy.so: opus_encoder_strategy.o
> ${CC} ${CInc} ${CLinkFlags} $^ -o $@
>
>
> opus_encoder_strategy.o: opus_encoder_strategy.cpp
> ${CC} ${CFLAGS} ${CInc} opus_encoder_strategy.cpp -o
> opus_encoder_strategy.o
>
> and I build the name of the .so file to be opus_encoder_strategy.so, then I
> am able to access the embedded class.
>
> HOWEVER, if I change the BOOST thing to BOOST_PYTHON_MODULE(opus_strategy)
> and my make file to this:
>
> all: opus_strategy.so #lv2strategy.so
>
>
> opus_strategy.so: opus_strategy.o
> ${CC} ${CInc} ${CLinkFlags} $^ -o $@
>
>
> opus_strategy.o: opus_encoder_strategy.cpp
> ${CC} ${CFLAGS} ${CInc} opus_encoder_strategy.cpp -o opus_strategy.o
>
> it doesn’t work.
>
> NOTE that I am matching the BOOST thing to the name of the .so file, this
> case opus_strategy.so
>
> It seems that it is looking at something else like the actual name of the cpp
> file or cpp file? This makes no sense to me and there is no documentation on
> how to properly use this.
> I am using python 3. Is this an issue. The documentation needs substantial
> improvement and clarification.
The name of the original source file is indeed irrelevant. The symptom
you describe seems to suggest that the Python interpreter is getting
confused. Are you sure the it sees the correct module at all ? (Does the
`__file__` attribute look correct ?) Perhaps you have also a
'opus_strategy.py' file in your path so your extension module isn't
loaded at all after the renaming ?
(Note that the exercise of putting together a minimal self-contained
test case, which I've been trying to suggest (still in vain, it seems),
would allow you to eliminate any such issues. All it requires is a bit
of debugging discipline...)
Stefan
--
...ich hab' noch einen Koffer in Berlin...
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig
