Package Details: vivado 2024.2-1

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 – Vivado edition
Upstream URL: https://www.xilinx.com/products/design-tools/vivado.html
Licenses: custom
Conflicts: vitis, vivado
Submitter: xiretza
Maintainer: VitalyR (leuko)
Last Packager: leuko
Votes: 19
Popularity: 0.21
First Submitted: 2019-06-18 22:23 (UTC)
Last Updated: 2025-03-07 08:57 (UTC)

Pinned Comments

leuko commented on 2024-01-14 21:14 (UTC) (edited on 2024-09-26 06:41 (UTC) by leuko)

PKGBUILD cannot download Vivado, you have to download Vivado before executing the PKGBUILD. Refer to PKGBUILD.

This PKGBUILD is also able to install Vitis with some errors, however there is a standalone package called vitis AUR which seems to be more advanced than the installation in this PKGBUILD.

Latest Comments

« First ‹ Previous 1 .. 8 9 10 11 12 13 14 15 16 Next › Last »

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.

yuyichao commented on 2020-05-10 20:18 (UTC) (edited on 2020-05-11 00:22 (UTC) by yuyichao)

The SDK is gone in the 2019.2 version so the corresponding desktop file can be deleted.

It'll also be nice to allow execution from command line as well. Based on the desktop file, a symlink like ln -s /opt/Xilinx/DocNav/docnav "$pkgdir/usr/bin/xilinx-docnav" should work for docnav while vivado need a shell script like

#!/bin/bash

unset LANG
unset QT_PLUGIN_PATH
. /opt/Xilinx/Vivado/%VERSION%/settings64.sh
exec /opt/Xilinx/Vivado/%VERSION%/bin/vivado "$@"

There also seems to be an updator from December, any idea it can be packaged as well?

xiretza commented on 2020-04-21 18:47 (UTC)

@schui: hm, haven't come across anything like that yet. It might be quickest to work this out via IRC, feel free to message me (user lambda on freenode).

schui commented on 2020-04-21 18:36 (UTC)

@xiretza Oh, my fault. The build process was successful. Thank you!

Unfortunately the application via .desktop nor the shell file doesn't start. The error message: execvp: Exec format error. After some googling I don't find any clue how to fix this. I really need this software for a student project. I'm running Linux 5.6.5-arch3-1 with KDE 5.69.0 / Plasma 5.18.4. Thanks for any advice!

« First ‹ Previous 1 .. 8 9 10 11 12 13 14 15 16 Next › Last »