Re: PyLucene for python3-dbg and libjcc3.so (Debian)

2021-07-29 Thread Andi Vajda


> On Jul 29, 2021, at 14:51, Erik Groeneveld - Seecr  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 .
> 


PyLucene for python3-dbg and libjcc3.so (Debian)

2021-07-29 Thread Erik Groeneveld - Seecr
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.

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.

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?

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 .