Hi Erik,
On Fri, 30 Jul 2021, Erik Groeneveld - Seecr wrote:
Hi Andy,
Thanks for your answer. I can now formulate my question.
We use at least 3 extensions generated by JCC and we use shared mode.
Thus, you need shared mode.
My actual question is.
Why does JCC generate extensions that use the shared library
“libjcc3.so, while all that is needed is also in jcc/_
jcc3.cpython-37m-x86_64-linux-gnu.so? In short, what is the use of
libjcc3.so?
The code in that .so is not the same code in libjcc3.so which contains the
global registry of java objects shared between the python VM and the java
VM, iirc. That piece needs to be unique for the process, thus the extra
shared library, which is not a python extension, actually, but a plain
shared library.
The point is that generated extensions always link to libjcc3.so,
regardless if these extensions are build for debug or not. Why does JCC do
that?
It's is just a name. When you expect to use multiple incompatible versions
of this library, you need to use a link flag such as 'rpath' (I don't
remember the exact syntax) that builds into the libraries using libjcc3.so
the full path of where the correct version of this library is installed (or
you switch your LD_LIBRARY_PATH at runtime to guide the dynamic linker to
pickup the right one at extension load time).
For macosx, you can see on line 377 in jcc's setup.py that I'm setting
@rpath/libjcc%s.dylib, which is a similar trick for its linker to achieve
this.
On linux, you need to make a similar change, or use the right version
of LD_LIBRARY_PATH at runtime.
On Linux, to see where the dynamic linker is going to pickup libjcc3.so
from, you can use the 'ldd' utility (on macosx, the similar utility is
called 'otool').
Andi..
Best regards,
Erik
On Thu, 29 Jul 2021 at 18:47, Andi Vajda <va...@apache.org> wrote:
On Jul 29, 2021, at 14:51, Erik Groeneveld - Seecr <e...@seecr.nl>
wrote:
L.S.,
We make Debian packages for JCC and PyLucene.
When building debug extensions for JCC and Lucene, we run into the
problem
that JCC links the generated extension against libjcc3.so.
That is the case if you use 'shared mode' which is the default but is
optional. Shared mode lets you load more than one jcc-built extension in a
given python process.
However, libjcc3.so defines Python objects and because the Python object
header defines additional fields in DEBUG mode, there need to be a
separate
version of libjcc3.so to run with python3-dbg.
Then you need to link that against a dbg version of jcc too. You should
not mix shared libraries built with different python defines.
However, it looks like it is sufficient if the generated extension links
against _jcc3.cpython-37m-x86_64-linux-gnu.so, because all sources
compiled
into libjcc3.so are also in this shared library.
This means that the debug version should link against the ...-37dm-...
version.
This would require some changes in the way JCC generates new extensions.
Is my reasoning correct or do I miss some things?
I don't know what all these extra suffixes mean but you should not mix
shared libraries built with different defines (ie debug and non debug). If
you don't need shared mode then you can skip the shared library mess
altogether, otherwise you have to get it right: use a dbg version jcc to
build a dbg version of pylucene.
Andi..
Best regards,
Erik
--
Seecr helpt informatieprofessionals met het consistent integreren en
verbinden van decentrale metadata zodat zij zich helemaal kunnen
focussen
op de inhoud.
Meer weten? Kijk op seecr.nl <https://seecr.nl>.
--
Seecr helpt informatieprofessionals met het consistent integreren en
verbinden van decentrale metadata zodat zij zich helemaal kunnen focussen
op de inhoud.
?? Meer weten? Kijk op seecr.nl <https://seecr.nl>.
