make fails
71GA opened this issue · 26 comments
I download and run make. It fails:
┌───┐
│ $ │ ziga > ziga--virtual > ghdl-yosys-plugin
└─┬─┘ /dev/pts/0
└─> make
yosys-config --exec --cxx -c --cxxflags -o ghdl.o src/ghdl.cc -fPIC -DYOSYS_ENABLE_GHDL -I/usr/include -O
make: yosys-config: No such file or directory
make: *** [Makefile:24: ghdl.o] Error 127
Documantation says only: make...
Actually, documentation says:
- Get and install Yosys.
- Get sources, build and install GHDL.
- Get and build ghdl-yosys-plugin: make.
Running make is step 3. 1 and 2 need to be done first.
I have yosys and ghdl installed. I am on Debian 11:
┌───┐
│ $ │ ziga > ziga--virtual > ghdl-yosys-plugin
└─┬─┘ /dev/pts/0
└─> yosys -V
Yosys 0.9 (git sha1 1979e0b)
┌───┐
│ $ │ ziga > ziga--virtual > ghdl-yosys-plugin
└─┬─┘ /dev/pts/0
└─> ghdl --version
GHDL 1.0.0 (Debian 1.0.0+dfsg-3) [Dunoon edition]
Compiled with GNAT Version: 10.2.1 20210110
mcode code generator
Written by Tristan Gingold.
Copyright (C) 2003 - 2021 Tristan Gingold.
GHDL is free software, covered by the GNU General Public License. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
What am I missing?
What's the output of which yosys-config?
Does src/ghdl.cc exist in your cloned repo?
It looks like yosys-config is missing:
┌───┐
│ $ │ ziga > ziga--virtual > ghdl-yosys-plugin
└─┬─┘ /dev/pts/0
└─> which yosys-config
How come? You mean cloned repo for the ghdl-yosis-plugin? It exists:
┌───┐
│ $ │ ziga > ziga--virtual > src
└─┬─┘ /dev/pts/1
└─> pwd
/home/ziga/Downloads/ghdl-yosys-plugin/src
┌───┐
│ $ │ ziga > ziga--virtual > src
└─┬─┘ /dev/pts/1
└─> ls
ghdl.cc Makefile.inc
So:
- Need to find out why yosys-config is missing in your package (I guess installed through apt).
- Or, do you have docker/podman? We have ready to use containers.
- Or, you can build Yosys from sources.
@71GA install package yosys-dev through apt. See https://packages.debian.org/buster/yosys-dev and https://packages.debian.org/buster/amd64/yosys-dev/filelist.
This helped to move things forward. Now there was another error:
┌───┐
│ $ │ ziga > ziga--virtual > ghdl-yosys-plugin
└─┬─┘ /dev/pts/1
└─> make
yosys-config --exec --cxx -c --cxxflags -o ghdl.o src/ghdl.cc -fPIC -DYOSYS_ENABLE_GHDL -I/usr/include -O
In file included from src/ghdl.cc:19:
/usr/share/yosys/include/kernel/yosys.h:80:12: fatal error: tcl.h: No such file or directory
80 | # include <tcl.h>
| ^~~~~~~
compilation terminated.
make: *** [Makefile:24: ghdl.o] Error 1
I managed to fix this one by i nstalling tcl-dev. Now the next error:
┌───┐
│ $ │ ziga > ziga--virtual > ghdl-yosys-plugin
└─┬─┘ /dev/pts/1
└─> make
yosys-config --exec --cxx -c --cxxflags -o ghdl.o src/ghdl.cc -fPIC -DYOSYS_ENABLE_GHDL -I/usr/include -O
src/ghdl.cc:30:10: fatal error: ghdl/synth.h: No such file or directory
30 | #include "ghdl/synth.h"
| ^~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:24: ghdl.o] Error 1
I have already installed all the packages that Debian 11 offers regarding the ghdl i.e.:
┌───┐
│ $ │ ziga > ziga--virtual > ghdl-yosys-plugin
└─┬─┘ /dev/pts/1
└─> sudo apt install ghdl{,-common,-gcc,-llvm,-mcode}
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
ghdl is already the newest version (1.0.0+dfsg-3).
ghdl-common is already the newest version (1.0.0+dfsg-3).
ghdl-gcc is already the newest version (1.0.0+dfsg-3).
ghdl-llvm is already the newest version (1.0.0+dfsg-3).
ghdl-mcode is already the newest version (1.0.0+dfsg-3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
This does not solve the last error. Any idea what now?
That seems to be a packaging issue, or a disabled feature. See the MSYS2 package: https://packages.msys2.org/package/mingw-w64-x86_64-ghdl-llvm?repo=mingw64. There are 5 header files. However, on Debian, there is a single one: https://packages.debian.org/bullseye/amd64/ghdl-common/filelist. libghw.h and vhpi_user.h were added recently, but synth.h and synth_gates.h have been there for several months already.
I wonder if Debian packagers are disabling synthesis features, and that's why these headers are not installed by make install.
You can pick those headers from https://github.com/ghdl/ghdl/tree/master/src/synth/include. However, chances are they will not match your version of GHDL. You might try with ghdlsynth.h and ghdlsynth_gates.h from https://github.com/ghdl/ghdl/tree/v1.0.0/src/synth. Yet, you would need to pick a version of this repo (ghdl-yosys-plugin) which matches the state back then. At that point, you'll be better using containers or building GHDL from sources.
There you are: https://salsa.debian.org/electronics-team/ghdl/ghdl/-/blob/master/debian/rules. Debian packagers are disabling libghdl through configure option --disable-libghdl. Synthesis through ghdl-yosys-plugin depends on libghdl. That's why the headers are not available, and the plugin would not work, even if you built it.
Hence, you need to wait until the ghdl package is updated in Debian with that feature enabled. Or you can build it yourself or use containers, as commented before.
@andreasbombe, is there any specific reason for libghdl to be disabled in Debian packages? Unlike GHDL simulation, libghdl/synthesis require a minimum version of GCC/GNAT (I think it was 8), so you might have disabled it some months/years ago because previous versions of Debian did not have a recent enough compiler?
@eine That is a shame that they dissabled it... Let's hope @andreasbombe will tell us what he knows. I really really hope these features will be available on Debian 11! I want to use this plugin...
I tested it and exactly the same problem is on Ubuntu 21.04... I think a lot of developpers are on these two platforms.
@eine Meanwhile on Debian 11 I compiled ghdl (1.0.0) myself. It compiled. Then I tried compiling the ghdl-yosis-plugin and I get this error:
┌───┐
│ $ │ ziga > ziga--virtual > ghdl-yosys-plugin-master
└─┬─┘ /dev/pts/0
└─> make
yosys-config --exec --cxx -c --cxxflags -o ghdl.o src/ghdl.cc -fPIC -DYOSYS_ENABLE_GHDL -I/usr/local/include -O
src/ghdl.cc: In function ‘void import_module(Yosys::RTLIL::Design*, GhdlSynth::Module)’:
src/ghdl.cc:634:30: error: ‘ID’ has not been declared
634 | module->set_bool_attribute(ID::blackbox);
| ^~
src/ghdl.cc:654:59: error: no match for call to ‘(Yosys::hashlib::pool<Yosys::RTLIL::IdString>) (std::string)’
654 | module->avail_parameters(to_str(get_param_name(m, idx)));
| ^
src/ghdl.cc:992:12: error: ‘struct Yosys::RTLIL::Module’ has no member named ‘addModFloor’
992 | module->addModFloor(to_str(iname), IN(0), IN(1), OUT(0), id == Id_Smod);
| ^~~~~~~~~~~
make: *** [Makefile:24: ghdl.o] Error 1
It looks like it is still not working... Do I have to pass that missing ID or is the source code messed up?
@Xiretza I don't understand what you are saying... Yosys 0.9 is the latest version: https://github.com/YosysHQ/yosys/tags There hasn't been a newer release since 0.9... It is the latest release.
Yes, you'll need to build it from source. We're all waiting for a new release (see YosysHQ/yosys#2733), but it hasn't happened yet.
Why would anyone build source code on top of the development release and not the latest stable release!? My opinion is that it is not wise... Surely you can implement newer features faster, but Linux distribution users will not be able to use them for half a decade...
I tested it and exactly the same problem is on Ubuntu 21.04... I think a lot of developpers are on these two platforms.
Ubuntu is Debian plus some non-free software. Therefore, it's not surprising that the same problems exist. Moreover, I wouldn't say that most GHDL users or hardware developers use Debian/Ubuntu. Fedora/CentOS, Arch Linux and Windows (MSYS2) are very used. In fact, packaging in any of those environments is in better shape than on Debian. However, AFAIAA, Debian is the only one that supports installing all three backends at the same time.
Meanwhile on Debian 11 I compiled ghdl (1.0.0) myself. It compiled. Then I tried compiling the ghdl-yosis-plugin and I get this error
As commented above, and as suggested by @Xiretza, you need to ensure that the versions of Yosys, GHDL and ghdl-yosys-plugin were taken at the same point in time (more or less). If you are using GHDL and Yosys from 3 months ago, you need to pick a version of this repo from three months ago.
Why would anyone build source code on top of the development release and not the latest stable release!?
Because all of these are usable but experimental tools. There is no stability guarantee in the "stable releases". In the case of GHDL, stable releases are as stable as the master branch. Arch Linux and MSYS2, which are some of the most used environments, are rolling releases. Therefore, not only the tools are moving, the environments are continuously moving too.
My opinion is that it is not wise... Surely you can implement newer features faster,
Your opinion is sensible, but there are further political, economical, and other human factors to take into account when understanding the release flow of an open source project.
but
Linuxdistribution users will not be able to use them for half a decade...
Maybe, that is the point...
@eine Well choosing an unstable roling release as the pinnacle of developpment is not wise in my oppinion. I managed to make everything work. But I had to compile development versions for (a) yosys, (b) ghdl and (c) ghdl-yosis-plugin.
If we are gonna compile everything ourselves at the end what's the point? We might as well use Slackware... Arch Linux is much better, but still... as a developper I can't be dependant on something so time consumming as Arch Linux or Slackware... it takes 70% of my time to just take care of my operating system... This multiplies if I am a system administrator and I have to set up development machines for an entire team of developpers. When some package breaks a rolling releasee system you spend a month setting everything up again...
To me it is stupid as it lowers (no, it actually kills) productivity.
Rolling release should only be used in order to draw attention of as much beta testers as possible (that's what users of those systems actually are) in order to get to the stable release at some point (period).
But ok... Not a debate for here. Problem "solved".
@71GA, please, take the following as a constructive dialogue.
Well choosing an unstable roling release as the pinnacle of developpment is not wise in my oppinion.
You are asking about a feature which is explicitly advertised as experimental everywhere (in the README, in the docs, in package descriptions). This is not about using GHDL for simulation, which has been available for almost 20y, and is stable and robust in almost any packaging system you can think of.
In this context, as you said, rolling releases are a mechanism for drawing the attention of as many beta testers and potential contributors/developers. That is what we need in order to remove the "experimental" adjective. Every user who tries to use GHDL for synthesis, finds a bug and reports it, is contributing per se. If someone is not willing to spend a few hours understanding the project, they are unlikely to report bugs. Furthermore, using rolling releases is what allows users to report a bug, have it fixed in less than 24h and have the upstream updated in 48h. We cannot offer that "quality of service" with periodic releases.
There is a certain type of developers who are packagers. They take care of following the development of the tools and deciding which changes are relevant for their target audience and which need to be tweaked. Each distribution/environment has different criteria for deciding what is worth an update and which features to enable. Arch, MSYS2, Fedora, Conda, Bazel, Yast, NIX, brew... all providing the same tool, but all different. See https://github.com/hdl/packages.
On the very end of that spectrum, there are Debian and all the systems based on it. Debian is known for being probably the most slow distribution with regard to updating packages, precisely because of its robustness (both from a technical and philosophical point of view). The latest stable release of Debian is 10, Buster. The GHDL version in Debian Buster is 0.35, from 2018/11/29: https://packages.debian.org/buster/ghdl. That is, users of Debian stable should expect a delay of at least 4 years in having experimental features available. That is probably the reason to pick Debian in the first place. Yet, some users don't want such stability in Debian, so they use the testing Debian 11 Bullseye. It turns out that even so, it has some months of delay. Therefore, you might want to further use unstable Debian Sid. At that point, it would be equivalent to a rolling release.
Overall, you cannot blame us for your decisions with regard to the environment you picked for experimental (open source) EDA tooling. Debian has many strong assets; that is not one of them. Nevertheless, you could have direct support and a working solution in less than 5h, for free. Time and effort devoted by volunteers, i.e. who did it for free. I would like you to think about a similar situation with any vendor tool, free or paid.
I managed to make everything work. But I had to compile development versions for (a) yosys, (b) ghdl and (c) ghdl-yosis-plugin.
With no sharpness, you compiled everything from sources because you wanted to. We did not say that is the recommended procedure for end-users. I explained that you can use containers. Very precisely, we build and test GHDL on Debian Bullseye containers periodically: https://github.com/ghdl/docker/actions/runs/840679585. We generate "package" containers for each of the backends: ghdl/pkg:bullseye-mcode, ghdl/pkg:bullseye-llvm-9, and ghdl/pkg:bullseye-gcc-9.1.0. Those are built once a week. Hence, you might have extracted one of those packages, along with installing the dependencies. Alternatively, you might have used another distribution with libghdl and synth enabled by default.
Yet, it is really nice that you built the tools from scratch, since that provides you some insight about what packaging is about. You might ask how is it that we test GHDL on Debian containers (3 after every push, and another 3 weekly) and still, the DEB packages are "so outdated" in Debian. The answer is easy: bandwidth. We, developers and maintainers of GHDL, know how to build and test GHDL on 20-30 different scenarios; but we don't know about Debian packaging. On the other hand, Debian packagers know about DEB packaging, but they cannot tightly follow all the tools they need to handle. Therefore, do you want to avoid end-users having to build Yosys, GHDL and ghdl-yosys-plugin from scratch? Help us! You can build a bridge between us and Debian packagers by opening issues here and there. We have fluent communication with Arch, Fedora and MSYS2 packagers, but that is not the case with Debian. See ghdl/ghdl#901.
2-3 years ago, GHDL packaging in Debian was barely usable (or removed), containers did not exist, MSYS2 packages did not exist, Arch/AUR packages were limited. 2 years ago, synthesis of VHDL with open source tools was neither possible nor thinkable by any sane mind. We are now having this dialogue because several users decided to turn their frustration into action. So, once again, I invite you to think about it and hopefully help us make the first contact easier for future Debian users.
Nicely said... I understand.
@71GA Can you please help me building ghdl-yosys-plugin? I am using Ubuntu22.04 (on windows) and I am getting this error:
yosys-config --exec --cxx -c --cxxflags -o ghdl.o src/ghdl.cc -fPIC -DYOSYS_ENABLE_GHDL -I/usr/include -O -DGHDL_VER_HASH=""90c5411""
src/ghdl.cc:30:10: fatal error: ghdl/synth.h: No such file or directory
30 | #include "ghdl/synth.h"
| ^~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:27: ghdl.o] Error 1
I have read the whole discussion and what I understood is that I should build ghdl, yosys and ghdl-yosys-plugin from source. Actually I am not sure if I understand the "from source" word, Is this mean that I have to clone the repo for each of them and build it using the make file? for example not using sudo apt install ghdl for building ghdl but clone ghdl and build it from the make file, is what I understand correct or not?
@tgingold okay, I did that for ghdl and yosys, I installed them from sources but I still get the same error, I even tried to uninstall ghdl by sudo apt remove ghdl and sudo apt autoclean && sudo apt autoremove to be sure that the ubuntu package is uninstalled but I don't know why I am getting the same error.
Is there any environment variable I should update or add? any clue or tip?
I can find the synth.h file but it seems that the makefile doesn't see it.
@tgingold I have cloned this ghdl
ghdl --version gives me this:
GHDL 1.0.0 (Ubuntu 1.0.0+dfsg-6) [Dunoon edition] Compiled with GNAT Version: 10.3.1 20211117 mcode code generator Written by Tristan Gingold.
I just cloned the repo, then I run ./configure and then I run make, I didn't set any parameters.
I am new with these stuff and even with ubuntu, sorry for that.
I hope that this help you to help me.
@tgingold Thanks a lot, it is working now.