Package Details: yosys-git 0.41+111.r13563.a84e4f44f-1

Git Clone URL: https://aur.archlinux.org/yosys-git.git (read-only, click to copy)
Package Base: yosys-git
Description: A framework for RTL synthesis
Upstream URL: https://yosyshq.net/yosys/
Keywords: fpga
Licenses: custom:ISC
Conflicts: yosys
Provides: yosys
Submitter: sebo
Maintainer: thasti
Last Packager: thasti
Votes: 18
Popularity: 0.006407
First Submitted: 2015-10-05 19:00 (UTC)
Last Updated: 2024-05-31 09:13 (UTC)

Dependencies (11)

Required by (21)

Sources (2)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 Next › Last »

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?

« First ‹ Previous 1 2 3 4 5 6 Next › Last »