conda-forge / conda-forge/python-feedstock

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

Abierto
#181 13 comentarios 0 reacciones 0 asignados Ver en GitHub
Lenguaje dominante
Shell
Estrellas
47
Forks
112
Merge medio
2 d 9 h
PR fusionados (30 d)
18

Descripción

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?

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.