[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Where to install arch-dependent eBPF *.o files?



Le jeudi 11 septembre 2025, 00:05:43 heure d’été d’Europe centrale Matthias Klose a écrit :
> On 9/10/25 23:48, Bastien Roucaries wrote:
> > Le mercredi 10 septembre 2025, 22:40:59 heure d’été d’Europe centrale Jérémy Lal a écrit :
> >> Le mer. 10 sept. 2025 à 21:49, Simon Josefsson <simon@josefsson.org> a
> >> écrit :
> >>
> >>> Hi.  Recent NSD support XDP and install some eBPF *.o files.  Upstream
> >>> puts them in /usr/share/nsd/ which lintian complains about.
> >>>
> >>> E: nsd: arch-dependent-file-in-usr-share
> >>> [usr/share/nsd/xdp-dns-redirect_kern.o]
> >>> N:
> >>> N:   This package installs an ELF binary in the /usr/share hierarchy,
> >>> which is
> >>> N:   reserved for architecture-independent files.
> >>>
> >>> Where is the appropriate place for these files?  I tried
> >>> /usr/libexec/nsd/ instead but got:
> >>>
> >>> E: nsd: binary-from-other-architecture
> >>> [usr/libexec/nsd/xdp-dns-redirect_kern.o]
> >>> N:
> >>> N:   This ELF binary appears to have been built for an architecture other
> >>> than
> >>> N:   the one of the binary package being tested. This may occur when a
> >>> N:   pre-built binary is shipped in the package or when an attempt to
> >>> N:   cross-compile didn't work.
> >>>
> >>> FWIW, file(1) on such objects (built on amd64) says:
> >>>
> >>> xdp-dns-redirect_kern.o: ELF 64-bit LSB relocatable, eBPF, version 1
> >>> (SYSV), with debug_info, not stripped
> >>>
> >>> Should we use /usr/lib/nsd?
> >>> /usr/lib/x86_64-linux-gnu/nsd/?
> >>> /usr/lib/bpf/?
> >>> /usr/lib/bpf/nsd/?
> >>> /usr/lib/x86_64-linux-gnu/bpf/?
> >>> /usr/lib/x86_64-linux-gnu/bpf/nsd/?
> >>>
> >>
> >> Not a specialist, but eBPF ELF files are bytecode for a virtual machine...
> >> I'm interested in the correct answer, because somehow it's related to WASM.
> >>
> > Talk to this a debian multiarch BoF at debian, it is a virual so we must create a arch triplet for this, it is likely a candidate for an specific arch none long term.
> > 
> > for me it is ebpf-none-v1 or
> > 
> > so /usr/lib/ebpf-none-v1/
> 
> the shortest triplet is bpf, also used by the GNU toolchain. Why would 
> there be a reason to version these at this point?
due to file but if GNU toolchain use bpf we could use bpf
> 
> 

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: