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
