One question: Did you write the test execution framework in GitHub Actions or did I write it?
--libghdl-name, --libghdl-library-path and --libghdl-include-dir are CLI arguments to the GHDL executable, they don't reflect setting in libghdl if not patched correctly. Executing a testcase like issue2005 doesn't run more elaborate tests like using GHDL's language server. If you execute more tests, you'll see the VHDL sources are not found by libghdl. If these files are not found by libghdl, it's an almost useless installation. > I see this uses pyGHDL and looking at the implementation of the libghdl > search function, it appears to not query the correct path and instead makes a > number of guesses using some incorrect assumptions. This is a good reminder > for me that I need to patch it if it isn't fixed yet by the time I get to > that. Please share your patches at https://github.com/ghdl/ghdl/issues and we can review your findings. Kind regards Patrick Am So., 20. Juli 2025 um 23:11 Uhr schrieb Debian Bug Tracking System <ow...@bugs.debian.org>: > > This is an automatic notification regarding your Bug report > which was filed against the libghdl-5-0-1 package: > > #1103550: Broken libghdl-5-0-1 > > It has been closed by Andreas Bombe <a...@debian.org>. > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Andreas Bombe > <a...@debian.org> by > replying to this email. > > > -- > 1103550: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103550 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > > > ---------- Forwarded message ---------- > From: Andreas Bombe <a...@debian.org> > To: Paebbels <paebb...@gmail.com>, 1103550-d...@bugs.debian.org > Cc: > Bcc: > Date: Sun, 20 Jul 2025 22:56:37 +0200 > Subject: Re: Bug#1103550: Broken libghdl-5-0-1 > Am Sat, Apr 19, 2025 at 12:00:15AM +0200, schrieb Paebbels: > > Package: libghdl-5-0-1 > > Version: 5.0.1+dfsg-1+b1 > > > > Hi, > > > > the libghdl package is broken. According to my research from 4.1.0, > > the paths inside of libghdl haven't been adjusted to find the library > > files of GHDL. I couldn't test this with 5.0.1 because it doesn't > > locate the libghdl.so file. > > The packaged ghdl binaries report the correct paths for libghdl with the > --libghdl-name, --libghdl-library-path and --libghdl-include-dir. In > fact, the test suite contains gna/issue2005 which does a link test > against libghdl. In Debian, the test suite is run during the package > build and through the CI framework using autopkgtest against installed > packages. According to the logs the test suites do in fact run issue2005 > and it always reports "ok." > > > When running ghdl-dom, libghdl-5_0_1.so can't be found. > > Using environment variable GHDL_PREFIX: > > ------------------------------------------------------------------------------------------- > [...] > > Using environment variable GHDL: > > ------------------------------------------------------------------------------------------- > > root@4af06a855805:~/ghdl# GHDL=$(which ghdl) ghdl-dom > > Traceback (most recent call last): > > I see this uses pyGHDL and looking at the implementation of the libghdl > search function, it appears to not query the correct path and instead > makes a number of guesses using some incorrect assumptions. This is a > good reminder for me that I need to patch it if it isn't fixed yet by > the time I get to that. > > However, pyGHDL isn't yet part of the Debian packaging and it is > pyGHDL's inadequate libghdl search function that is failing to find the > library. If pyGHDL were packaged and this issue would still be current, > I would have patched it. Therefore this is not a bug in the Debian > package and I'm closing this bug. > > > Some investigations: > > libghdl is located in /usr/lib/x86_64-linux-gnu, which is a directory > > for multiarch support. > > > > From Debians documentation: > > Multiarch is the term being used to refer to the capability of a > > system to install and run applications of multiple > > different binary targets on the same system. For example running a > > i386-linux-gnu application on an amd64-linux-gnu > > system. This example is the most common case, but many other > > working combinations are possible, such as armel > > and armhf. > > > > Multiarch also simplifies cross-building, where > > foreign-architecture libraries and headers are needed on a system > > during > > building. > > > > GHDL is not cross-compiling. It generates code for the host platform. > > So on x86-64 it generates x86-64 code and on aarch64 it generates > > aarch64 code. Moreover, libghdl doesn't generate any code at all. It > > just supports parsing, analysis, etc. but no code generation. Thus, > > the classification as a multiarch code generator isn't correct, right? > > Libraries need to be installed in multiarch locations to enable > installing and running applications of multiple different binary targets > on the same system, as you quoted above. Not using the multiarch > location in the future would be a regression in terms of multiarch > support. > > > One of the biggest usecases of libghdl is the Python binding via > > pyGHDL/libghdl. Therefore a matching Python package installation is > > required, What is the plan of Debian providing a matching pyGHDL 5.0.1 > > version for libghdl 5.0.1? > > > > Instead of a Debian package providing libghdl, I suggest to provide a > > python3-pyGHDL package containing an embedded and matching > > libghdl-5.0.1.so. This is how we deliver pyGHDL via our GitHub > > pipeline. setup.py can handle this usecase. Just provide the so file > > in pyGHDL/lib/... The so file will become a package resource file. > > I initially did not provide a libghdl package in Debian as I did not see > any user except pyGHDL, which I hadn't enabled. In the meantime the > yosys maintainer asked for libghdl to be provided for the use of the > yosys GHDL plugin. As libghdl is now a package for that use case, it > makes no sense for the future pyGHDL package to embed another copy. > Especially since all that needs to be fixed is just the pyGHDL library > search function, as far as I can see. > > > ---------- Forwarded message ---------- > From: Paebbels <paebb...@gmail.com> > To: sub...@bugs.debian.org > Cc: > Bcc: > Date: Sat, 19 Apr 2025 00:00:15 +0200 > Subject: Broken libghdl-5-0-1 > Package: libghdl-5-0-1 > Version: 5.0.1+dfsg-1+b1 > > Hi, > > the libghdl package is broken. According to my research from 4.1.0, > the paths inside of libghdl haven't been adjusted to find the library > files of GHDL. I couldn't test this with 5.0.1 because it doesn't > locate the libghdl.so file. > > When running ghdl-dom, libghdl-5_0_1.so can't be found. > Using environment variable GHDL_PREFIX: > ------------------------------------------------------------------------------------------- > root@4af06a855805:~/ghdl# GHDL_PREFIX=/usr/lib/ghdl ghdl-dom > Traceback (most recent call last): > File "/usr/local/bin/ghdl-dom", line 5, in <module> > from pyGHDL.cli.dom import main > File "/usr/local/lib/python3.13/dist-packages/pyGHDL/cli/dom.py", > line 48, in <module> > from pyGHDL.libghdl import LibGHDLException > File "/usr/local/lib/python3.13/dist-packages/pyGHDL/libghdl/__init__.py", > line 206, in <module> > libghdl = _initialize() > File "/usr/local/lib/python3.13/dist-packages/pyGHDL/libghdl/__init__.py", > line 187, in _initialize > _libghdl_path = _get_libghdl_path() > File "/usr/local/lib/python3.13/dist-packages/pyGHDL/libghdl/__init__.py", > line 181, in _get_libghdl_path > raise ex > pyGHDL.libghdl.LibGHDLException: Cannot find pyGHDL shared library > 'libghdl-5_0_1.so'. > Tried variable 'GHDL_PREFIX': /usr/lib/ghdl > Checked variable 'GHDL': not set. > Checked variable 'VUNIT_GHDL_PATH': not set. > Tried pyGHDL.lib resource directory: > /usr/local/lib/python3.13/dist-packages/pyGHDL/lib/libghdl-5_0_1.so > Relative to build directory: > /usr/local/lib/python3.13/dist-packages/lib > ------------------------------------------------------------------------------------------- > root@4af06a855805:~/ghdl# GHDL_PREFIX=/usr/lib/ghdl/mcode ghdl-dom > Traceback (most recent call last): > File "/usr/local/bin/ghdl-dom", line 5, in <module> > from pyGHDL.cli.dom import main > File "/usr/local/lib/python3.13/dist-packages/pyGHDL/cli/dom.py", > line 48, in <module> > from pyGHDL.libghdl import LibGHDLException > File "/usr/local/lib/python3.13/dist-packages/pyGHDL/libghdl/__init__.py", > line 206, in <module> > libghdl = _initialize() > File "/usr/local/lib/python3.13/dist-packages/pyGHDL/libghdl/__init__.py", > line 187, in _initialize > _libghdl_path = _get_libghdl_path() > File "/usr/local/lib/python3.13/dist-packages/pyGHDL/libghdl/__init__.py", > line 181, in _get_libghdl_path > raise ex > pyGHDL.libghdl.LibGHDLException: Cannot find pyGHDL shared library > 'libghdl-5_0_1.so'. > Tried variable 'GHDL_PREFIX': /usr/lib/ghdl/mcode > Checked variable 'GHDL': not set. > Checked variable 'VUNIT_GHDL_PATH': not set. > Tried pyGHDL.lib resource directory: > /usr/local/lib/python3.13/dist-packages/pyGHDL/lib/libghdl-5_0_1.so > Relative to build directory: > /usr/local/lib/python3.13/dist-packages/lib > ------------------------------------------------------------------------------------------- > > Using environment variable GHDL: > ------------------------------------------------------------------------------------------- > root@4af06a855805:~/ghdl# GHDL=$(which ghdl) ghdl-dom > Traceback (most recent call last): > File "/usr/local/bin/ghdl-dom", line 5, in <module> > from pyGHDL.cli.dom import main > File "/usr/local/lib/python3.13/dist-packages/pyGHDL/cli/dom.py", > line 48, in <module> > from pyGHDL.libghdl import LibGHDLException > File "/usr/local/lib/python3.13/dist-packages/pyGHDL/libghdl/__init__.py", > line 206, in <module> > libghdl = _initialize() > File "/usr/local/lib/python3.13/dist-packages/pyGHDL/libghdl/__init__.py", > line 187, in _initialize > _libghdl_path = _get_libghdl_path() > File "/usr/local/lib/python3.13/dist-packages/pyGHDL/libghdl/__init__.py", > line 181, in _get_libghdl_path > raise ex > pyGHDL.libghdl.LibGHDLException: Cannot find pyGHDL shared library > 'libghdl-5_0_1.so'. > Checked variable 'GHDL_PREFIX': not set > Tried variable 'GHDL': /usr/bin/ghdl > Checked variable 'VUNIT_GHDL_PATH': not set. > Tried pyGHDL.lib resource directory: > /usr/local/lib/python3.13/dist-packages/pyGHDL/lib/libghdl-5_0_1.so > Tried 'which ghdl': /usr/bin/ghdl > Relative to build directory: > /usr/local/lib/python3.13/dist-packages/lib > ------------------------------------------------------------------------------------------- > > Some investigations: > libghdl is located in /usr/lib/x86_64-linux-gnu, which is a directory > for multiarch support. > > From Debians documentation: > Multiarch is the term being used to refer to the capability of a > system to install and run applications of multiple > different binary targets on the same system. For example running a > i386-linux-gnu application on an amd64-linux-gnu > system. This example is the most common case, but many other > working combinations are possible, such as armel > and armhf. > > Multiarch also simplifies cross-building, where > foreign-architecture libraries and headers are needed on a system > during > building. > > GHDL is not cross-compiling. It generates code for the host platform. > So on x86-64 it generates x86-64 code and on aarch64 it generates > aarch64 code. Moreover, libghdl doesn't generate any code at all. It > just supports parsing, analysis, etc. but no code generation. Thus, > the classification as a multiarch code generator isn't correct, right? > > One of the biggest usecases of libghdl is the Python binding via > pyGHDL/libghdl. Therefore a matching Python package installation is > required, What is the plan of Debian providing a matching pyGHDL 5.0.1 > version for libghdl 5.0.1? > > Instead of a Debian package providing libghdl, I suggest to provide a > python3-pyGHDL package containing an embedded and matching > libghdl-5.0.1.so. This is how we deliver pyGHDL via our GitHub > pipeline. setup.py can handle this usecase. Just provide the so file > in pyGHDL/lib/... The so file will become a package resource file. > > Kind regards > Patrick
