Updated to 2020.1 and moved the digilent utilities to optdepends, thanks yuyichao.
Search Criteria
Package Details: vivado 2024.1-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/vivado.git (read-only, click to copy) |
---|---|
Package Base: | vivado |
Description: | FPGA/CPLD design suite for AMD devices |
Upstream URL: | https://www.xilinx.com/products/design-tools/vivado.html |
Licenses: | custom |
Submitter: | xiretza |
Maintainer: | VitalyR (leuko) |
Last Packager: | leuko |
Votes: | 17 |
Popularity: | 0.108400 |
First Submitted: | 2019-06-18 22:23 (UTC) |
Last Updated: | 2024-07-16 13:19 (UTC) |
Dependencies (13)
- cpio (cpio-gitAUR)
- gtk3 (gtk3-no_deadkeys_underlineAUR, gtk3-classic-xfceAUR, gtk3-patched-filechooser-icon-viewAUR, gtk3-classicAUR)
- inetutils (inetutils-gitAUR, busybox-coreutilsAUR)
- lib32-libpng12
- libpng12
- libxcrypt-compat
- ncurses5-compat-libsAUR
- xorg-xlsclients
- digilent.adept.runtimeAUR (optional)
- digilent.adept.utilitiesAUR (optional)
- fxloadAUR (optional)
- matlabAUR (matlab-supportAUR) (optional) – Model Composer
- qt4AUR (optional) – Model Composer
Required by (12)
- avnet-bdf-git (optional)
- csky-cpu-wujian100-open (optional)
- csky-cpu-wujian100-open-doc (optional)
- csky-cpu-wujian100-open-fpga (optional)
- csky-cpu-wujian100-open-sdk (optional)
- csky-cpu-wujian100-open-simulation (optional)
- csky-cpu-wujian100-open-soc (optional)
- csky-cpu-wujian100-open-test (optional)
- tcl-prompt-git (optional)
- vivado-boards-git
- xrt (optional)
- xrt-bin (optional)
Sources (2)
Latest Comments
« First ‹ Previous 1 .. 6 7 8 9 10 11 12 13 14 Next › Last »
xiretza commented on 2020-06-09 20:22 (UTC)
yuyichao commented on 2020-06-09 12:38 (UTC)
Also note that at least digilent.adept.runtime
digilent.adept.utilities
and fxload
should be optional dependencies. They should only be needed for anyone that want to use this to manipulate digilent devices.
xiretza commented on 2020-05-19 09:26 (UTC)
@leuko: yeah, the installer does some weird shenanigans with LD_LIBRARY_PATH
, those warnings show up even without the custom LD_PRELOAD
trickery this package uses. From what I can tell they can be safely ignored, all files in the package are still owned by root.
leuko commented on 2020-05-19 08:46 (UTC) (edited on 2020-05-19 08:47 (UTC) by leuko)
FYI: After Starting package()...
I got the following errors, but the installation completed successfully:
ERROR: ld.so: object 'ERROR: ld.so: object 'libfakeroot.solibfakeroot.so' from ' from LD_PRELOADLD_PRELOAD cannot be preloaded ( cannot be preloaded (cannot open shared object filecannot open shared object file): ignored.
): ignored.
ERROR: ld.so: object 'libfakeroot.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object 'libfakeroot.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
Running in batch mode...
4VRDriver commented on 2020-05-15 21:44 (UTC)
Something I have noticed while building this package (just in case someone has the same problem): because of the huge size of the package I hadn't enough space on my ext4-drive and thought it would be a good idea to run "makepkg" on a second NTFS drive that had enough space - the build will fail saying you have run out of space regardless of the real free space. So building on a NTFS drive is not a good idea at all.
yuyichao commented on 2020-05-11 17:30 (UTC)
exactly which executables should receive this special handling?
the ones
that have the associated desktop entry
i.e. vivado
, docnav
(and vivado_hls
that is missing the desktop entry).
xiretza commented on 2020-05-11 15:49 (UTC)
@yuyichao: I understand your usecase, but I'm hesitant to add wrapper scripts to /usr/bin
(symlinks aren't enough) - exactly which executables should receive this special handling? Everyone's usecase is probably a little different. Instead, I can suggest creating your own wrappers in /usr/local/bin
, which should be on the PATH by default, maybe even with a separate sourced file that defines the current version to make upgrading easier.
yuyichao commented on 2020-05-11 14:08 (UTC)
sourcing
the setting file puts a bit too many scripts on PATH
and creating a few wrapper scripts serves as a intermediate level of command line support. It's at least useful in my workflow (not necessarily general I guess) since I launch almost everything for a project from command line but I don't really need more than the "default programs" that have the associated desktop entry.
xiretza commented on 2020-05-11 13:48 (UTC) (edited on 2020-05-11 13:53 (UTC) by xiretza)
@yoyichao: ah, thanks, I hadn't noticed the SDK disappearing. I applied the change locally, but since it only removes a useless file, I won't push a package update yet (the cost for users of either rebuilding or ignoring the package is greater than the benefit imho). As for putting binaries on the path - that's exacatly what those shell scripts are for. If you want the tools to always be on your path, source /opt/Xilinx/Vivado/2019.2/settings64.sh
in your shell's init script (e.g. .bashrc
).
Edit: oh, and regarding the update: I'd rather not package those unless absolutely necessary, it would increase the build time even more with no benefit for most users. This also aligns with Xilinx's update recommendations.
Pinned Comments
leuko commented on 2024-01-14 21:14 (UTC) (edited on 2024-01-14 21:15 (UTC) by leuko)
PKGBUILD
cannot download Vivado, you have to download Vivado before executing thePKGBUILD
. Refer toPKGBUILD
.