XRT
XRT copied to clipboard
Xilinx
Fix build issues when creating deb packages
Problem solved by the commit
Fixed build failures for build_deb_edge.sh
How problem was solved, alternative solutions (if any) and why they were rejected
- debian packaging skills is outdated and I just synchronise it with the latest packaging script
- Fix the bug in dkms-edge.cmake introduced after the removal of cu_plram.c
- Update to build on jammy by default
Risks (if any) associated the changes in the commit
Most changes are specific to debian packaging and so it should be safe for other usage. The dkms-edge.cmake is an obvious bug after a removal of the cu_plram.c and so the fix is pretty straightforward too.
What has been tested and how, request additional testing if necessary
Tested to generate .deb file in 2022.1 branch head. If we need to cherrypick the change to master branch. Probably we need to test it too since I am not sure if there are other changes in master branch that require packaging script change.
Documentation impact (if any)
If there are document on how to create .deb files. We should update it and remove the need of the sysroot, as well as mentioning we are building jammy by default now.
@stsoe During the enablement in jammy, the latest version of XRT packaged is 2.13.466. As far as I know it should be coming from the 2022.1 branch
Hi @hkhonming, one query did you use cross compilation for testing this? (host - x64 or amd64) because when I tested on amd64 host it fails if I don't provide sysroot
@rbramand-xilinx The original script depends on the setup of sbuild chroot & the xilinx sysroot. I am removing the sysroot since XRT itself actually just depends on standard libraries. In this case, you will still need to setup a standard sbuild chroot in arm64 architecture.
@rbramand-xilinx The original script depends on the setup of sbuild chroot & the xilinx sysroot. I am removing the sysroot since XRT itself actually just depends on standard libraries. In this case, you will still need to setup a standard sbuild chroot in arm64 architecture.
@hkhonming I am confused, you are saying that sbuild chroot in arm64 is needed but removed sysroot option, how does that work? Also we would like to do cross compilation mostly, so we need to provide sysroot flag right?
@rbramand-xilinx The original script depends on the setup of sbuild chroot & the xilinx sysroot. I am removing the sysroot since XRT itself actually just depends on standard libraries. In this case, you will still need to setup a standard sbuild chroot in arm64 architecture.
@hkhonming I am confused, you are saying that sbuild chroot in arm64 is needed but removed sysroot option, how does that work? Also we would like to do cross compilation mostly, so we need to provide sysroot flag right?
The original setup used sbuild-createchroot to pull the sysroot to the chroot environment. Since there are no specific dependencies on Xilinx packages. You can just use normal mk-sbuild jammy/focal --arch=arm64 to create the chroot. Then sbuild should be able to build XRT through qemu.
Ref: https://packaging.ubuntu.com/html/setting-up-sbuild.html
I am confused. 2022.1 did not support jammy. Is this meant for master?
I was just about asking the same. Is there someone expected to also add some documentation about how to use this?
Hi, I will send a fresh PR for master and address comments on this PR. This PR is mainly for Edge platforms. Regarding documentation, at present we are using this internally and I will create a confluence page with steps on creating packages using the script. We can add the steps to XRT docs based on marketing ask
Hi, I will send a fresh PR for master and address comments on this PR. This PR is mainly for Edge platforms. Regarding documentation, at present we are using this internally and I will create a confluence page with steps on creating packages using the script. We can add the steps to XRT docs based on marketing ask
This is open-source code and we need also some documentation on how to build this on Edge platforms. This is what we are looking at right now on our ZCU102.
Why a new PR? Just go on working on it.
Globally open-sourcing tends to increase the software quality.
@Ralender: could you add your perl issues here?
Hi @hkhonming , You can close this PR as https://github.com/Xilinx/XRT/pull/7148 is merged to master XRT, Users can use master XRT branch to build debian packages.