`Make` in virtualenv still links against system python

Description

I noticed that when make-ing cocotb, the virtual environment is not respected by parts of the makefiles. This results in libsim.so being linked to the wrong libpython.so

I have the following system:

• Ubuntu 18.04
• Python 3.6 installed system-wide (executable in /usr/bin/, libpython /usr/lib/x86_64-linux-gnu/)
• Python 3.7 (alt)installed under /usr/local/ with libpython installed under /usr/local/lib/
• venv created from Python 3.7.

I ~double~ triple checked that the paths are correct when activating the virtualenv (python -c "import sys; print(sys.path)" gives me the path with the virtualenv path in the front. In fact even when I start a simulation it reports the correct python path in the log output: cocotb.gpi gpi_embed.c:103 in embed_init_python Using virtualenv at /home/stefan/.venvs/cocotb37/bin/python

But when I enable debug logging, I can see that it actually uses a different python path: regression.py:131 in initialise Python Path [...],/usr/lib/python36.zip,/usr/lib/python3.6,/usr/lib/python3.6/lib-dynload

So I dug deeper into the build of the cocotb native libraries. Checking the libraries that simulator.so is linked against, I can see that it is linked a gainst the Python 3.6 lib 🤨:

ldd cocotb/build/libs/x86_64/libsim.so 
	[...]
	libpython3.6m.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0 (0x00007f519fc32000)
	[...]

Again, I triple checked that I ran the cocotb native libray build in the correct (py 3.7) virtual env. But somewhere in the makefiles it picks up the wrong path.

My suspicion is that maybe somewhere where a shell is spawned to get the python excutable and library paths, it does not get the environment variables passed.

Steps to reproduce

1. Start e.g. with Ubuntu 18.04
2. Install a second python (e.g. python 3.7) that is different from the system python under /usr/local/ prefix. (if building from source use --enable-shared in the configure step)
3. Create a virtualenv with the secondary python.
4. clone cocotb
5. run make in cocotb folder
6. check the libraries that simulator.so is linked against with ldd cocotb/build/libs/x86_64/simulator.so

Expected results:

libsim.so should be linked against the libpython of the secondary python installation (in my case that would be the one in /usr/local/lib/

Actual result:

libsim.so is linked against the default python under /usr/lib/x86_64-linux-gnu/

[themperek]

Could you check if something like this would works for you?

PYLIBS:=$(shell $(PYTHON_BIN) -c 'from __future__ import print_function; from distutils import sysconfig; import os; print("-l"+os.path.splitext(sysconfig.get_config_var("LDLIBRARY"))[0][3:])')

[StefanD986]

Yes that does the trick!