conda-forge / conda-forge/python-feedstock

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

Aperta
#181 13 commenti 0 reazioni 0 assegnatari Vedi su GitHub
Lingua principale
Shell
Stelle
47
Fork
112
Merge medio
2g 9h
PR unite (30g)
18

Descrizione

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?

Guida per i contributori

Apri la guida per i contributori

Valutazione

Questa issue non è ancora stata valutata.

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.