Package Details: vitis 2024.2-1

Git Clone URL: https://aur.archlinux.org/vitis.git (read-only, click to copy)
Package Base: vitis
Description: FPGA/CPLD design suite for Xilinx devices
Upstream URL: https://www.xilinx.com/products/design-tools/vitis.html
Licenses: custom
Conflicts: vivado
Provides: vivado
Submitter: Freed
Maintainer: Freed (ccorn)
Last Packager: ccorn
Votes: 4
Popularity: 0.054634
First Submitted: 2023-04-21 03:30 (UTC)
Last Updated: 2024-11-24 10:15 (UTC)

Required by (13)

Sources (2)

Latest Comments

1 2 Next › Last »

pldubouilh commented on 2024-10-05 21:52 (UTC)

Builds and works fine - quick trick to save (a lot of) time with the final step when packaging, you can avoid the zstd pkg compression stage by building a simple tar archive with PKGEXT='.pkg.tar' makepkg

vanbwodonk commented on 2024-09-09 02:01 (UTC)

@ccorn: Thank you for the reply.

My problem is fixed when I rebuild pkg with last git commit. Some changes happen when I first build Vitis 2024.1. So maybe that's the problem.

ccorn commented on 2024-09-06 08:53 (UTC)

@vanbwodonk: I can start Vitis normally, but I have only tested that superficially. If you have more detailed crash experiences, please share them.

Recent days have seen a Boost version upgrade, and lots of packages depending on boost-libs needed to be rebuilt. Some rebuilds were not available at the time of the boost-libs upgrade, and the affected packages ceased to function. (I usually rebuild such packages myself, not waiting for official releases.)

Vitis also uses Boost, but brings its own versions and sets LD_LIBRARY_PATH and PATH for its tools accordingly. I have witnessed no Boost-related problems with Vitis so far. But I do not use Vitis heavily, so that statement does not weigh much.

Problems usually arise when Vitis invokes an external (i. e. Archlinux-native) tool (like a browser) which expects a library from Archlinux but finds the older version shipped with Vitis instead. We had that issue with libstdc++.so.6 and solved it by changing all libstdc++.so.6 in Vitis into links to the Archlinux version. Which works because libstdc++.so.6 is reasonably backwards-compatible. For other libraries, we might need a different approach.

Try to start Vitis from the console (e.g. /opt/Xilinx/Vitis/2024.1/bin/vitis) so that you have stderr output available. If you find crash-related output there, please post it here.

vanbwodonk commented on 2024-09-03 13:22 (UTC)

I can no longer open Vitis after updating my computer today. I could still open Vitis last Friday. Anyone else experience the same thing?

JHT213 commented on 2024-07-01 06:34 (UTC) (edited on 2024-07-01 09:59 (UTC) by JHT213)

Can I modify the PKGBUILD to install more subtools by adding --config /path/install.txt, like what vivado aur package says in its PKGBUILD. I like this package better, so I prefer to build this package:)

Edit: Succeed!

ccorn commented on 2024-06-27 03:28 (UTC)

With 2024.1 there are now libstdc++.so.6 confusion issues.

Have to fix those. Will take another couple of days.

ccorn commented on 2024-06-26 12:42 (UTC) (edited on 2024-06-26 15:23 (UTC) by ccorn)

@RolandMetivier: Thanks. I am currently building 2024.1, examining the logs, and tuning the PKGBUILD.

Turns out that the Vivado subtree now needs some lopper-related pkgdir removal as well.

Will push the update when things look good. Might take another day or so because this package is so abhorrently huge.

Note: I use find-libdeps and find-libprovides to identify external dependencies. Will update depends and optdepends accordingly.

This assumes that the tools set up their library paths correctly. Which should be the case for the apps invoked by means of *.desktop files.

Some old (opt)depends seem to be no longer needed (and will be commented out):

  • cpio
  • ncurses5-compat-libs (edit: still requested in installLibs.sh)
  • libxcrypt-compat (edit: needed by the setup tools)
  • libpng12
  • lib32-libpng12
  • qt4

There are some dependencies on gtk3 libs now, but also some on gtk2. Therefore I have tentatively added gtk3 to depends (instead of optdepends).

As always, feedback will be much appreciated. But be patient, as it might take several days to build and test changes on this enormous package.

RolandMetivier commented on 2024-06-14 02:50 (UTC) (edited on 2024-06-14 02:56 (UTC) by RolandMetivier)

!debug should probably be defined in the "options" too in the PKGBUILD now.

EDIT: https://aur.archlinux.org/packages/linphone-desktop-appimage#comment-965273 says to do it for large packages like these.

ccorn commented on 2023-12-05 10:57 (UTC)

@ouras: Thanks!

The PKGBUILD snippet that you have quoted adjusts paths in scripts, not in symbolic links. I have now added handling of symlinks as well: Roughly, if any symlink in $pkgdir points into $pkgdir, it is turned into a relative symlink.

As to LD_LIBRARY_PATH: This gets set by the Vitis startup script using ldlibpath.sh. That is supposed to select a distro-specific lib subdir. In our case, the script hallucinates a Default subdirectory. Providing a Default symlink to Ubuntu should have the same effect as your fix. So we now scan the $pkgdir tree for Ubuntu subdirs, and if there is no Default sibling, symlink it to Ubuntu. This augments both /opt/Xilinx/Vitis/2023.2/tps/lnx64/cmake-*/libs.

Will push the update soon if it works out well. Feedback much appreciated, particularly because this package is so awfully huge.

ouras commented on 2023-12-05 06:52 (UTC)

When generating a platform component in Vitis, I was getting an error about libssl and libcrypto:

22:05:33 ERROR : cmake: /usr/lib/libssl.so.10: version `libssl.so.10' not found (required by cmake)
22:05:33 ERROR : cmake: /usr/lib/libcrypto.so.10: version `libcrypto.so.10' not found (required by cmake)

Not sure the right way to fix it, but my workaround was to modify my Vitis desktop entry (/usr/share/applications/Vitis\ 2023.2.desktop) so that the Exec key is:

Exec=env LD_LIBRARY_PATH=/opt/Xilinx/Vitis/2023.2/tps/lnx64/cmake-3.24.2/libs/Ubuntu:$LD_LIBRARY_PATH /opt/Xilinx/Vitis/2023.2/bin/vitis

1 2 Next › Last »