Sylvain,
That sounds exactly like what was happening to me! Thank you :D
-Dave
On Tue, Jul 5, 2016 at 9:20 AM, Sylvain Munaut <246...@gmail.com> wrote:
> See the thread :
>
> "The AttributeError problem now that I have modified a working OOT"
>
> My guess is that you encountered something
See the thread :
"The AttributeError problem now that I have modified a working OOT"
My guess is that you encountered something similar.
So the SWIG process went fine and without any error, but if the .so
that was generated from your C++ code can't be loaded because of
undefined symbols, then th
Well poop. I can't remember what was causing the issues (it was about a
month ago). If I run across it again I'll copy off the code before fixing
it so that I can show it here.
On Sun, Jul 3, 2016 at 5:59 PM, Dave NotTelling wrote:
> Sylvain,
>
> I'll attempt to gin something up tomorrow.
Sylvain,
I'll attempt to gin something up tomorrow. Thanks!
-Dave
On Sun, Jul 3, 2016 at 5:01 AM, Sylvain Munaut <246...@gmail.com> wrote:
> Hi,
>
> > It's always
> > something that's not quite 100% right in my C++ code, but it's seriously
> > painful to debug as I have to resort to comme
Hi,
> It's always
> something that's not quite 100% right in my C++ code, but it's seriously
> painful to debug as I have to resort to commenting code out and trying again
> over and over.
SWIG doesn't even look at the C++ source code, only the public headers.
> Is there a way to have SWIG tel
I have been making lots of OOT modules for various purposes and have run
into the same issue several times. I'll build a C++ module, compile it
with 'cmake ..' 'make' 'make install' and 'ldconfig'. After all that I
import the module to Python (ipython shell) and find that the module (top
level mo
