Package Details: yosys-git 0.10+25.r10984.a0f5ba850-1

Git Clone URL: (read-only, click to copy)
Package Base: yosys-git
Description: A framework for RTL synthesis
Upstream URL:
Keywords: fpga
Licenses: custom:ISC
Conflicts: yosys
Provides: yosys
Submitter: sebo
Maintainer: thasti
Last Packager: thasti
Votes: 16
Popularity: 0.84
First Submitted: 2015-10-05 19:00 (UTC)
Last Updated: 2021-10-12 17:12 (UTC)

Latest Comments

xiretza commented on 2022-01-06 19:56 (UTC)

@widlarizer: This is the Arch user repository. Of course nobody can stop you from using it on another distribution, but if you're requesting support from the volunteer maintainers around here, please have the decency to be upfront about being on an unsupported system.

widlarizer commented on 2022-01-06 11:32 (UTC)

I apologize, all my issues turned out to have nothing to do with the PKGBUILD. I didn't have base-devel because of Manjaro. Object files are deleted at the start of the build as the Makefile compiler detection step does that deliberately. And enabling max jobs in MAKEFLAGS should be correctly done in makepkg.conf. Thank you for maintaining this package

thasti commented on 2022-01-05 05:49 (UTC)

bison and flex are included in base-devel, which are a general prerequisite for AUR packages [1], [2].

I'm not sure about your comment regarding the deletion of object files. This does not happen in the PKGBUILD (i.e. if it happens, it does so in the upstream build system).

[1] [2]

widlarizer commented on 2022-01-05 00:12 (UTC) (edited on 2022-01-05 00:18 (UTC) by widlarizer)

bison and flex are missing from build-time dependencies.

Furthermore, it deletes object files, which is not the PKGBUILD's job, but the user's choice to cleanbuild, if I am not mistaken

EDIT: wait, is this building object files in a single thread?

thasti commented on 2020-10-20 17:43 (UTC)

Added, sorry for missing that earlier!

xiretza commented on 2020-10-20 06:26 (UTC)

Sorry to bug you again, but could you also switch to a versioned provides (provides=("yosys=$pkgver"))?

thasti commented on 2020-10-19 18:07 (UTC)

Absolutely. I'm test-building this and will push it here soon.

xiretza commented on 2020-10-19 15:59 (UTC)

Hey, would you be open to adding upstream's YOSYS_VER to $pkgver? Something like this:

pkgver() {
    cd "${srcdir}/yosys"
    printf "%s.r%s.%s" "$(make echo-yosys-ver)" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"

Resulting in e.g. 0.9+3624.r10271.ac0bd2ff. Combined with provides=("yosys=$pkgver"), this would allow other packages to specify a minimum required yosys revision, e.g. depends=('yosys>=0.9+3468'), which is sometimes necessary due to the infrequency of upstream releases.

thasti commented on 2020-09-30 05:40 (UTC)

I confirm. A recent change in the upstream makefile requires new flags to steer the python installation. I'm testing a fix and will be pushing it here soon.

The breaking upstream commit is 9266d20afc7f3571ffee5edc27afe19dc54bb356.

kbeckmann commented on 2020-09-29 22:17 (UTC) (edited on 2020-09-30 06:56 (UTC) by kbeckmann)

Edit: This issue is now fixed upstream!

I'm not able to build this anymore. I am getting the following error (tried building inside a clean docker):

mkdir: cannot create directory ‘/usr/lib/python3.8/site-packages/pyosys’: Permission denied

Trying to figure out which change that broke it, as I was able to build just fine a few weeks ago, but I haven't found it yet.

Edit: Seems to be caused by the commit e8c9e541a735894a974aaebfb88dfaa9aa3e0f31

ignilux commented on 2020-05-19 23:35 (UTC)

Well, after a couple of hours down the pwmconfig / lm_sensors rabbit hole, it looks like it was indeed a thermal issue. In the end I wound up applying fresh thermal paste and cleaning out the fans, closing everything but the single terminal running the build, and manually setting all fans to max. The CPU somehow STILL managed to get up to 80+ C during the process. Looks like I have some more investigating to do, but the build did succeed.

Anyway, thanks for helping me troubleshoot!

thasti commented on 2020-05-19 16:41 (UTC)

Okay, I'm running a similar setup here, so the amount of RAM appears not to be the issue. Normally efficient CPU usage is a good thing, and other processes that need CPU time should still receive it. One option you could explore is reducing the number of utilized CPUs (configured in /etc/makepkg.conf using MAKEFLAGS=jX, at least on Arch Linux).

Given that I don't see how software could cause a full reboot otherwise, can you rule out a thermal problem? Watching lm-sensors might be helpful here. I have no other good ideas how to get more specific debug output for your problem, at least nothing specific to yosys/abc comes to mind.

ignilux commented on 2020-05-19 16:33 (UTC)

Hi thasti, thanks for the quick reply. I'm running a Core i7 with 8 GB RAM, and an 8.8 GB swap partition located on the same SSD as the filesystem. It seemed like a reasonable explanation, though, so I went ahead and tried the build while monitoring htop. Memory usage never exceeded about 3.7 / 8 GB, and at the time of the crash it was down around 2.4 GB.

What I did find surprising was that all four physical and all four logical cores were pegged at 100% usage for the entire process. Could this be a problem, or is the kernel simply dynamically allocating anything unused by other processes to gcc?

thasti commented on 2020-05-19 16:04 (UTC)

Hi ignilux. Is it possible your machine is killing processes due to insufficient RAM being available during the build process? I just tried building the package and had no issues during compilation of abc.

You could try to monitor RAM usage during the build process (using htop or something similar), or perhaps keep an eye on dmesg during this phase of the build (to see if the out-of-memory killer kicks in). Creating and using a swap file might help out in that case - I don't know whether Manjaro uses one by default or not.

ignilux commented on 2020-05-19 15:31 (UTC)

I'm having issues building this from Pamac in a fresh install of Manjaro. Mirrors and package databases are up to date, and the build will consistently fail at the same point. This happens from both the UI and from command line. The failure is in the form of an immediate reboot with no warning or delay, with seemingly nothing wrong once logged back in.

Unfortunately neither journalctl nor the Pamac log seem to have any information that might be helpful, but I did happen to notice that the last few lines printed to the screen are something like:

[94%] abc ... compiling src/misc/zlib
[94%] abc ... compiling src/misc/bzlib

I'd be happy to provide more information if anyone can guide me on how to produce it, and I'd appreciate any and all help I can get.

thasti commented on 2020-05-05 16:24 (UTC)

Thanks for making me aware xiretza, incorporated and also updated the upstream URL for the yosys repo to point to YosysHQ.

xiretza commented on 2020-05-05 15:43 (UTC)

yosys now uses a vendored fork of ABC, so the source needs to be changed to

marzoul commented on 2020-03-19 22:32 (UTC)

@xiretza The patch is working good, should be worth adding it to the PKGBUILD. Thanks !

xiretza commented on 2020-03-19 21:39 (UTC) (edited on 2020-03-19 21:47 (UTC) by xiretza)

@marzoul: this happens because the Makefile.conf is left over from a previous build; the yosys Makefile doesn't handle this possibility for echo-*-rev targets and prints the information anyway. A quick fix is to add a make config-clean in prepare(). If you want to avoid these kinds of problems entirely in the future, consider building packages in a clean chroot:

Edit: here's a patch

marzoul commented on 2020-03-19 21:27 (UTC)

Hi, The package does not build, could you check ?

==> Starting prepare()... error: pathspec '[Makefile.conf] CONFIG := gcc [Makefile.conf] ENABLE_LIBYOSYS=1 [Makefile.conf] ENABLE_PYOSYS=1 ed90ce2' did not match any file(s) known to git ==> ERROR: A failure occurred in prepare().

thasti commented on 2020-01-06 21:12 (UTC)

I checked today and since the pull request has been accepted upstream, the PKGBUILD modification concerning BOOST_PYTHON_LIB is not required anymore.

xiretza commented on 2019-12-29 19:29 (UTC)

The package has some messed up paths (for example, yosys-config --exec echo --cxxflags contains -I/usr/local/share/yosys/include), so here's a patch that fixes the make options (and additionally removes the python patch, which has become unnecessary):

diff --git a/PKGBUILD b/PKGBUILD
index 1ef6caf..e888ce5 100644
@@ -27,8 +27,7 @@ build(){
     make config-gcc
     echo "ENABLE_LIBYOSYS=1" >> Makefile.conf
     echo "ENABLE_PYOSYS=1" >> Makefile.conf
-    echo "BOOST_PYTHON_LIB=-lboost_python38 -lpython3.8" >>Makefile.conf
-    make
+    make PREFIX="/usr"

 pkgver() {
@@ -38,7 +37,7 @@ pkgver() {

 package() {
     cd ${srcdir}/yosys
-    make PREFIX=$pkgdir/usr/ PYTHON_PREFIX=$pkgdir/usr/ install
+    make PREFIX="/usr" PYTHON_PREFIX="$pkgdir/usr" DESTDIR="$pkgdir" install

     install -D -m 644 \
     "${srcdir}/LICENSE" \

swedishhat commented on 2019-11-26 17:00 (UTC)

It looks like @grahamedgecombe's PR has been approved and is just waiting to be merged. I'm going to update the PKGBUILD with @vogelchr's fix for now and then revert back when upstream merges in the fix.

grahamedgecombe commented on 2019-11-19 21:53 (UTC)

I've submitted a pull request to fix this upstream:

potatoe commented on 2019-11-17 23:01 (UTC) (edited on 2019-11-17 23:11 (UTC) by potatoe)

I think the linking problems are maybe due to a change in python-config (a script in /usr/bin included with python) in 3.8, specifically: which dropped the -lpython3.8 from the output of python-config --ldflags. The new way seems to be to call python-config with an extra flag --embed to include the python library in addition to the regular --ldflags, per .

So I guess that might mean it's an upstream issue, yosys's Makefile's usage of python-config (or $(PYTHON_EXECUTABLE)-config, rather) could be updated to be compatible with python 3.8? It will need a few extra fallbacks around trying calls with and without --embed to continue working on both 3.8 and older ones (which don't support passing an --embed flag), though.

thasti commented on 2019-11-17 12:11 (UTC)

Is it expected that building against boost_python3 now requires this additional linker flag? I wonder whether this is to be considered a bug in the yosys Makefile (in which case I would file an issue with yosys upstream) or an unintended change in the behavior of boost-libs after updating to Python3.8.

vogelchr commented on 2019-11-17 12:01 (UTC)

Adding this to the PKGBUILD's build() allows makepkg to build yosys successfully.

echo "BOOST_PYTHON_LIB=-lboost_python38 -lpython3.8" >>Makefile.conf

Not adding the -lpython3.8 for me results in a huge amount of unresolved symbols, and I cannot see -lpython being added to the build command when manually running "make PRETTY=0".

thasti commented on 2019-11-16 18:45 (UTC)

@gnurise: It looks like it. It appears as if the yosys Makefile tries to do it's check for which libboost to use, but runs into the same compilation errors you get when providing the correct library manually. Not quite sure where to flag this, but boost-libs could be the best fit I believe.

It appears to me that building any C program with -lboost_python is broken as it stands now.

gururise commented on 2019-11-16 18:33 (UTC)

@thasti wonder if this has something to do with the recent upgrade in Arch to Python 3.8? I tried:

export BOOST_PYTHON_LIB=/lib/

But ended up with a bunch of compilation errors complaining about symbols not found.

thasti commented on 2019-11-16 09:14 (UTC) (edited on 2019-11-16 10:04 (UTC) by thasti)

@gnurise: Can't reproduce with current git master. For me, no modifications of the PKGBUILD are required. Are you sure boost is installed and functional on your system?

EDIT: Actually can reproduce after updating other packages. Potentially something in boost library contents changed. Will investigate.

gururise commented on 2019-11-16 08:04 (UTC) (edited on 2019-11-16 08:05 (UTC) by gururise)

Compile fails:

echo 'CONFIG := gcc' > Makefile.conf

[Makefile.conf] CONFIG := gcc

[Makefile.conf] ENABLE_LIBYOSYS=1

[Makefile.conf] ENABLE_PYOSYS=1

Makefile:323: *** BOOST_PYTHON_LIB could not be detected. Please define manualy. Stop.

novenary commented on 2019-07-05 08:56 (UTC) (edited on 2019-07-05 09:00 (UTC) by novenary)

@swedishhat: I just checked, yosys does indeed require extra/boost as a makedepend, and extra/boost-libs as a runtime dependency (according to ldd output). The readme on github also mentions the dependency. namcap also complains about it: yosys-git E: Dependency boost-libs detected and not included (libraries ['usr/lib/', 'usr/lib/'] needed in files ['usr/lib/python3.7/site-packages/pyosys/'])

novenary commented on 2019-07-02 18:17 (UTC) (edited on 2019-07-02 18:18 (UTC) by novenary)

Installing extra/boost allows the build to complete, I haven't checked whether the runtime libs are required and I won't have access to a computer until this weekend. I believe namcap can detect missing dependencies on shared libraries if you'd like to check that yourself.

swedishhat commented on 2019-07-02 18:09 (UTC)

@streetwalrus: did you resolve this? If not, try installing extra/boost-libs to see if that resolves the dependency problem.

swedishhat commented on 2019-07-02 18:04 (UTC)

@marzoul: is this duplication part of the AUR build or is it a part of the Yosys project on Github?

novenary commented on 2019-06-29 06:26 (UTC)

Build is failing for me because of a missing dependency on boost.

passes/cmds/ fatal error: boost/algorithm/string/predicate.hpp: No such file or directory
   27 | #  include <boost/algorithm/string/predicate.hpp>
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:595: passes/cmds/plugin.o] Error 1
make: *** Waiting for unfinished jobs....

marzoul commented on 2019-06-27 22:02 (UTC)

I freshly recompiled this package, last time was in October 2018. The package size got from 23 MB to 57 MB. I'm sensitive to this. Digging a bit I saw that there is a that is installed 3 times. All identical. Could you please deduplicate this ? Symlinks surely should be fine.

thasti commented on 2019-05-20 20:25 (UTC)

Would you consider enabling compilation of libyosys and pyosys (python bindings) for this AUR? I recently got some changes merged to make these features build for non-debian systems. My patch to do that can be found here:

I believe this would introduce an additional dependency on boost. Regards!

swedishhat commented on 2019-02-04 08:47 (UTC) (edited on 2019-02-04 08:48 (UTC) by swedishhat)

@Un1Gfn: I added abc to the sources (per your gist) and it looks like it's doing the trick:

Pulling ABC from
+ test -d abc
+ cd abc
+ make DEP= clean

swedishhat commented on 2019-02-04 07:48 (UTC) (edited on 2019-02-04 08:44 (UTC) by swedishhat)

@cyrozap: xdot should now be listed as an optional dependency since yosys can build happily without it.

cyrozap commented on 2017-12-17 12:13 (UTC)

xdot should be added as a either a dependency or an optional dependency, as it's required for the "show" command to work.

grahamedgecombe commented on 2017-12-09 21:20 (UTC) (edited on 2017-12-09 21:20 (UTC) by grahamedgecombe)

The prefix and destdir need to be specified separately for commands like yosys-config --datdir to work:

diff --git a/PKGBUILD b/PKGBUILD
index [`8a04531`]( 100644
@@ -20,7 +20,7 @@ sha512sums=('SKIP'
     cd ${srcdir}/yosys
     make config-gcc
-    make
+    make PREFIX=/usr

 pkgver() {
@@ -30,7 +30,7 @@ pkgver() {

 package() {
     cd ${srcdir}/yosys
-    make PREFIX=$pkgdir/usr/ install
+    make PREFIX=/usr DESTDIR="$pkgdir" install

     install -D -m 644 \
     "${srcdir}/LICENSE" \

sebo commented on 2016-09-24 06:38 (UTC)

Hi arturo182, thank you for your feedback. Actually, AUR packages assume base-devel is installed (which includes flex and bison). See "Installing Packages" in .

arturo182 commented on 2016-09-23 18:54 (UTC)

I get "bison: command not found" and "flex: command not found" when trying to install, probably need to add those two as dependencies :)

sebo commented on 2016-05-08 20:27 (UTC)

Should be fixed now. Just FYI: the old PKGBUILD was using clang to build actually, not gcc. I changed the toolchain used from clang to gcc and also changed the build script to follow the README's installation instructions. The package now builds on my machine at least.

sebo commented on 2016-05-08 19:59 (UTC)

Thanks for reporting. I was able to reproduce. I'll try to narrow it down and then report to Clifford.

cyrozap commented on 2016-05-08 19:36 (UTC)

I'm getting this message when I try to build with GCC 6.1.1: I'm not sure whether this is just an issue on my computer, with the package, or with the Yosys source.