conda-forge / conda-forge/python-feedstock
INSTSONAME in Makefile does not point to a .so file?
- 主要語言
- Shell
- 星號
- 47
- 分支
- 112
- 平均合併
- 2 天 9 小時
- 30 天內合併 PR
- 18
描述
I'm not sure if it's a python or a conda build thing, so please refer me to the right channel if this is not the right place to address this issue.
After I installed Python 3.6.5 in Linux (through conda from anaconda build hc3d631a_2) I see the following in [environment root]/lib/python3.6/config-3.6m-x86_64-linux-gnu/Makefile:
```
LIBRARY= libpython$(VERSION)$(ABIFLAGS).a
LDLIBRARY= libpython$(VERSION)$(ABIFLAGS).a
BLDLIBRARY= $(LDLIBRARY)
PY3LIBRARY=
DLLLIBRARY=
LDLIBRARYDIR=
INSTSONAME= $(LDLIBRARY)
```
Does this look odd as the INSTSONAME is not a .so? The reason for this is that I think some autoconf script (such as Vim when compiling with python support) would read the INSTSONAME from the Makefile and use that as the dynamic library name. And thus it will try to load the .a instead of .so and failed (?).
Here is the same file for Python 3.5.2 (lib/python3.5/config-3.5m):
```
LIBRARY= libpython$(VERSION)$(ABIFLAGS).a
LDLIBRARY= libpython$(LDVERSION).so
BLDLIBRARY= -L. -lpython$(LDVERSION)
PY3LIBRARY= libpython3.so
DLLLIBRARY=
LDLIBRARYDIR=
INSTSONAME= libpython$(LDVERSION).so.1.0
```
It looks like this is what the python configure.ac is setting:
https://github.com/python/cpython/blob/master/configure.ac
My question is, should the LDLIBRARY point to a .so?
貢獻指南
評估
這個 Issue 還沒有評估資料。