Arch Linux User Repository

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.

When I run makepkg -s, after the decompression process, I get the output:

==> Entering fakeroot environment...
==> Starting package()...
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.
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.
This is a fresh install.
Running in batch mode...
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on
Copyright (c) 1986-2023 Xilinx, Inc.  All rights reserved.
INFO  - User has accepted the EULAs.
...

After that I aborted the installation as it was installing under the path /home/$USERNAME/Downloads/. What am I doing wrong?

In case someone wants to try and get Vitis packaged as well, here is the current state of my attempt to do so.

First step is straightforward: Change xsetup options:

--product Vitis \
--edition 'Vitis Unified Software Platform'

Note that Vitis includes Vivado.

Then xsetup issues warnings:

WARN  - 
######## Execution of Pre/Post Installation Tasks Failed ########
Warning: Xilinx software was installed successfully, but an unexpected status was returned from the following post installation task(s) Error: The SDK needs a python installed 
INFO  - Installation completed successfully.For the complete setting to use Versal ACAP tools, please run the script "installLibs.sh" under /build/vivado/pkg/vivado/opt/Xilinx/Vitis/2022.2/scripts, which requires the root privilege. 

OK, so let's add python to makedepends and optdepends.

A look at the mentioned installLibs.sh reveals that it would use the system's package manager to install some dependencies. Extend optdepends accordingly:

gcc git graphviz make net-tools openssl python

Next round. Providing python turns out to be sort of a curse: The installer runs a postinstall script that hardcodes library paths into some ELF binaries, so now those contain $pkgdir. This must be corrected:

# Only remove $pkgdir in the to-be-stored strings, i.e. 2nd, 3rd occurrence,
# but leave $pkgdir where needed to find files
_relocator=$pkgdir/opt/Xilinx/Vitis/${pkgver}/data/emulation/qemu/comp/qemu/relocate_sdk.sh
sed -i -e "/^\\\${PYTHON}/{;s|$pkgdir||2;s|$pkgdir||2;}" "$_relocator"
# Run the fixed relocator
"$_relocator"
# Now remove the remaining traces of $pkgdir
sed -i -e "s|$pkgdir||g" "$_relocator"

Next round. Despite the fixed script, three ELF files still contain $pkgdir (though chrpath does not reveal those). I have not found out why and how yet, so I binary-patched those remaining ELFs, replacing $pkgdir with a same-length representation of /. This hack is not meant to stay; the issue should be investigated and resolved with higher-level tools.

Of course the resulting package is more gigantic than ever. Updated comments:

# This package is huge. The download alone is a barely-compressed 90GB .tar.gz (extracts to ~90GB)
# and the final zstd-compressed package is another 73GB. Reserve at least 360GB in total for building.
#
# It can also take up to 8 hours to build, being mostly limited by I/O and single-thread
# performance. `namcap` takes another 50 minutes and 128G in `$TMPDIR`,
# make sure you're not running that automatically.

Does it work? Not yet: Trying to start Vitis HLS aborts because of a missing arch command. (And the Model Composer requires MatLab.) Vivado starts up however.

@bionade24: what do you mean? Which directory, and which "unnecessary curl duplication step"?

Could you maybe change the PKGBUILD to assume the Vivado tarball already being inside the folder? This would enforce avoiding the whole unnecessary curl duplication step.

can we install Vitis along with vivado/vitis_hls?

Vivado crashes with the following error when opening block designs (on my Manjaro OS).

libGL error: MESA-LOADER: failed to open swrast: /opt/Xilinx/Vivado/2022.2/lib/lnx64.o/Default/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /usr/lib/dri/swrast_dri.so) (search paths /usr/lib/dri, suffix _dri)
libGL error: failed to load driver: swrast
Prism-ES2 Error : GL_VERSION (major.minor) = 1.4

It seems that /usr/lib/dri/swrast_dri.so (from mesa package version 22.2.3-1) requires newer libstdc++.so. This could be fixed by replacing the shipped version of libstdc++ with system's installed version,

mv $pkgdir/opt/Xilinx/Vivado/${pkgver}/lib/lnx64.o/Default/libstdc++.so.6 $pkgdir/opt/Xilinx/Vivado/${pkgver}/lib/lnx64.o/Default/libstdc++.so.6.old
ln -s /usr/lib/libstdc++.so.6 $pkgdir/opt/Xilinx/Vivado/${pkgver}/lib/lnx64.o/Default/libstdc++.so.6

or simply removing these files, the dynamic linker would then load default libstdc++.so.6 from /usr/lib.

rm $pkgdir/opt/Xilinx/Vivado/${pkgver}/lib/lnx64.o/Default/libstdc++.so*

Seems like the package size reduction is indeed due to removed/missing Versal part data:

2022.1:

49G /opt/Xilinx/Vivado/2022.1/data/parts/xilinx/devint/vault/versal
60G /opt/Xilinx/Vivado/2022.1/data/parts

2022.2:

12G /opt/Xilinx/Vivado/2022.2/data/parts

Don't know whether Versal should be installed or not by default...

@xiretza compare output of pacman -Ql of the two packages? the /opt/Xilinx/Vivado/$pkgver/data/parts directory contains about 60GB of data, that is my prime candidate for being missing

I've updated to 2022.2, but something weird has happened this time - even though the download archive grew from 70GB to 90GB, the package shrunk from ~60GB to 20. I gave it a quick smoke test and everything seems to be working okay, but I'm fairly confident Xilinx broke something here. Please let me know if you find out what it is.

@MrJake222: makepkg doesn't know about the AUR, you either have to build and install dependency AUR packages manually or use an AUR helper that does it for you.