lucene-pylucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <va...@apache.org>
Subject Re: Building jcc 3.0 under linux / anaconda python
Date Sat, 15 Apr 2017 02:19:52 GMT

On Sat, 15 Apr 2017, Rüdiger Meier wrote:

>
>
> On 04/15/2017 12:52 AM, Petrus Hyvönen wrote:
>> Hi,
>> 
>> First, again - many thanks to all of you who made jcc work with python 3,
>> this is a great thing!
>> 
>> Now playing with linux building and I am using anaconda python distribution
>> and it seems like the link library for python is called libpython3.6m.so
>> instead of the libpython3.6 that other python seems to use and setup.py
>> assume. I have another called libpython3.
>> 
>> If I remove this extra_links_args it seems to build fine, as well as if I
>> add a "m" to the end:
>>
>>        elif platform == 'linux':
>>             #kwds["extra_link_args"] = \
>>             #    lflags + ['-lpython%s.%s' %(sys.version_info[0:2])]
>>             kwds["force_shared"] = True    # requires jcc/patches/patch.43
>> 
>> The -m seems to indicate how python was built:
>> http://stackoverflow.com/questions/16675865/difference-between-python3-and-python3m-executables
>> 
>> Not sure if there is a danger in removing this, as long as it builds fine?
>
> Ah, I've had fixed this more complicated like this
> https://github.com/rudimeier/jcc/commit/b4a7987ebeeb96d6c71b7635160f798303715877
>
> But good to know that it works without. Actually I've had really wondered why 
> we such python setup.py would need complicated extra_link_args at all just to 
> link against itself.

It probably depends on the setuptools version and the monkeypatch hackery 
done for linux support, where linking a plain shared library for JCC in 
shared mode (that libjcc.so thing) is harder than it should be.

If removing all this still works, so be it, but older versions of setuptools 
required this up to a point. I'm in favor of getting rid of all this baggage 
at least in the Python 3 case, since we don't have any backwards 
compatibility requirement there.

Andi..

>
> cu,
> Rudi
>
Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message