TRN_ConversionMonitorReady error when I import PDFNetPython

OPERATING SYSTEM: Linux v4-dev 3.13.0-34-generic Ubuntu 14.04 x86_64 GNU/Linux

I have built the PDFNetC wrappers for Python.
The samples run fine.

I have even copied the .so files to /usr/local/lib and updated PATH to find /usr/local/lib.

ubuntu@v4-dev:/usr/local/lib⟫ ls PDFNetC python2.7 python3.4
ubuntu@v4-dev:/usr/local/lib⟫ echo $PATH

When I try to use PDFNetPython from the Python interpreter, I get the following error -

ubuntu@v4-dev:/usr/local/lib⟫ ipython
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
Type “copyright”, “credits” or “license” for more information.

IPython 1.2.1 – An enhanced Interactive Python.
? → Introduction and overview of IPython’s features.
%quickref → Quick reference.
help → Python’s own help system.
object? → Details about ‘object’, use ‘object??’ for extra details.

In [1]: import site

In [2]: site.addsitedir(".")

In [3]: from PDFNetPython import *

ImportError Traceback (most recent call last)
in ()
----> 1 from PDFNetPython import *

/usr/local/lib/ in ()
26 fp.close()
27 return _mod
—> 28 _PDFNetPython = swig_import_helper()
29 del swig_import_helper
30 else:

/usr/local/lib/ in swig_import_helper()
22 if fp is not None:
23 try:
—> 24 _mod = imp.load_module(’_PDFNetPython’, fp, pathname, description)
25 finally:
26 fp.close()

ImportError: ./ undefined symbol: TRN_ConversionMonitorReady

In [4]: from PDFNetPython import *
Segmentation fault (core dumped)
139 ubuntu@v4-dev:/usr/local/lib⟫

The first time I try to import PDFNetPython, it gives me an error. The second time it gave me a segmentation fault.

Even during building the wrappers, unless I restarted the machine, the make command gave me a an error saying virtual memory was exhausted.

Do let me know how to proceed.

We provide pre-built Python bindings, so you should not have to build them yourself.

64bit Linux Python Wrapper:

If you do need to build it for some reason, all the TRN_ConversionMonitorX functions are not officially part of the API yet, and may be removed or changed. I was not aware of any linking problems that this could cause.

It sounds like the that is being loaded for the interpreter is different then the one you use otherwise, so I would double check you are using the same so file everywhere.

Otherwise, I would simply comment out the references to TRN_ConversionMonitorX in Headers/C/TRN_Convert.h and Headers/Impl/Convert.inl, so you don’t need them.