Fix virtualenv support

[mbikovitsky]

This should hopefully solve #80, and perhaps other similar issues lurking about.

The discussion in #80 (comment) is spot on:

Python seems to determine venvs partially based on where the python executable being run is, before resolving symlinks

However, the Python executable for a virtualenv is determined not through the PYTHONEXECUTABLE environment variable, but through argv[0]. Here's the relevant code (all from v3.11.6, the version bundled in oss-cad-suite at the time of writing):

• The base executable is computed here: https://github.com/python/cpython/blob/v3.11.6/Modules/getpath.py#L302-L320
  • This is really convoluted, but AFAICT the highlighted part: 1. sets base_executable to to the value of executable, which was computed a bit higher up from argv[0], and 2. sets executable to the value of PYTHONEXECUTABLE.
  • Then all the way down here base_executable is written back to the config dict.
• Then sys._base_executable is set from the configuration here: https://github.com/python/cpython/blob/v3.11.6/Python/sysmodule.c#L3106.
• When a venv is created the code takes sys._base_executable: https://github.com/python/cpython/blob/v3.11.6/Lib/venv/__init__.py#L130
• And this creates the symlink in the virtualenv's bin directory: https://github.com/python/cpython/blob/v3.11.6/Lib/venv/__init__.py#L292

The end result is that for oss-cad-suite, the venv is now subtly broken:

$ ls -la venv/bin/
total 32
drwxr-xr-x 2 user user 4096 Feb 13 23:47 .
drwxr-xr-x 5 user user 4096 Feb 13 23:47 ..
-rw-r--r-- 1 user user 1998 Feb 13 23:47 activate
-rw-r--r-- 1 user user  924 Feb 13 23:47 activate.csh
-rw-r--r-- 1 user user 2204 Feb 13 23:47 activate.fish
-rw-r--r-- 1 user user 9033 Feb 13 23:47 Activate.ps1
lrwxrwxrwx 1 user user   10 Feb 13 23:47 python -> python3.11
lrwxrwxrwx 1 user user   10 Feb 13 23:47 python3 -> python3.11
lrwxrwxrwx 1 user user   59 Feb 13 23:47 python3.11 -> /opt/oss-cad-suite/libexec/python3.11

python3.11 is a symlink to libexec/python3.11, instead of py3bin/python3 or bin/tabbypy3. And since the interpreter is dynamically linked to libpython3.11.so:

$ ldd /opt/oss-cad-suite/libexec/python3.11
        linux-vdso.so.1 (0x00007ffd6a199000)
        libpython3.11.so.1.0 => /lib/x86_64-linux-gnu/libpython3.11.so.1.0 (0x00007f4b68c00000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4b68a1f000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4b6944b000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4b6942c000)
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f4b69401000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f4b69551000)

Whoops, now running it will load the .so in /lib instead of the one in oss-cad-suite/lib, since there's no wrapper script to set the library path anymore.

The fix, it seems, is simple -- override argv[0] instead of setting PYTHONEXECUTABLE. Luckily ld.so has an --argv0 flag just for this purpose. The first commit in this PR does precisely that.

The second commit resolves any potential symlinks in the wrapper script's path. When called from a venv, the wrapper script will have BASH_SOURCE set to venv/bin/python3 (for example), but we need to find the actual location where oss-cad-suite resides.

On my Debian 12 system, cocotb in a virtualenv with iverilog now work just fine.