conda-forge / conda-forge/python-feedstock

INSTSONAME in Makefile does not point to a .so file?

Open
#181 13 comments 0 reactions 0 assignees View on GitHub
Dominant language
Shell
Stars
47
Forks
112
Avg merge
2d 9h
Merged PRs (30d)
18

Description

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?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.