On 18 Jun 2024, at 17:57, Ross Burton via lists.openembedded.org 
<ross.burton=arm....@lists.openembedded.org> wrote:
> 
> I went to have a quick look at this but can’t built bpftool:
> 
> ERROR: bpftool-native-1.0-r0 do_compile: oe_runmake failed
> ERROR: bpftool-native-1.0-r0 do_compile: 
> ExecutionError('/work/ross/build/tmp/work/aarch64-linux/bpftool-native/1.0/temp/run.do_compi)
> ERROR: Logfile of failure stored in: 
> /work/ross/build/tmp/work/aarch64-linux/bpftool-native/1.0/temp/log.do_compile.1052635
> Log data follows:
> | DEBUG: Executing shell function do_compile
> | NOTE: make -j 64 V=1 -C 
> /work/ross/build/tmp/work-shared/qemuarm64/kernel-source/tools/bpf/bpftool 
> O=/work/ross/build/tmp/work/aarcn
> | make: Entering directory 
> '/work/ross/build/tmp/work-shared/qemuarm64/kernel-source/tools/bpf/bpftool'
> | gcc: error: unrecognized command-line option ‘-fcanon-prefix-map’; did you 
> mean ‘-fmacro-prefix-map=’?
> |
> | Auto-detecting system features:
> | ...                         clang-bpf-co-re: [ OFF ]
> | ...                                    llvm: [ OFF ]
> | ...                                  libcap: [ OFF ]
> | ...                                  libbfd: [ OFF ]
> |
> | make -C 
> /work/ross/build/tmp/work-shared/qemuarm64/kernel-source/tools/lib/bpf 
> OUTPUT=/work/ross/build/tmp/work/aarch64-linux/bpfto\
> | 
> DESTDIR=/work/ross/build/tmp/work/aarch64-linux/bpftool-native/1.0/bpftool-1.0/libbpf
>  prefix= /work/ross/build/tmp/work/aarchs
> | make[1]: Entering directory 
> '/work/ross/build/tmp/work-shared/qemuarm64/kernel-source/tools/lib/bpf'
> | gcc: error: unrecognized command-line option ‘-fcanon-prefix-map’; did you 
> mean ‘-fmacro-prefix-map=’?
> | gcc: error: unrecognized command-line option ‘-fcanon-prefix-map’; did you 
> mean ‘-fmacro-prefix-map=’?
> 
> Looks like a problem with the host compiler being passed target flags.  Have 
> you seen this?

Yes, bpftool is passing DEBUG_PREFIX_MAP to the host compiler when building 
natively, which won’t work.

I worked around that and had a look.  A less ugly and probably upstreamable 
solution might be to add —sysroot to propagate_cflags in meson.build, and add 
the sysroot to CFLAGS directly in the recipe.  For historical reasons we pass 
the sysroot via CC, but specifying it twice won’t hurt.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200884): 
https://lists.openembedded.org/g/openembedded-core/message/200884
Mute This Topic: https://lists.openembedded.org/mt/106572377/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to