Peter Maydell <peter.mayd...@linaro.org> wrote:
> On Fri, 10 Feb 2023 at 14:21, Juan Quintela <quint...@redhat.com> wrote:
>>
>> Peter Maydell <peter.mayd...@linaro.org> wrote:
>> > Fails to build the user-mode emulators:
>>
>> This is weird.
>
>> > https://gitlab.com/qemu-project/qemu/-/jobs/3749435025
>> >
>> > In file included from ../authz/base.c:24:
>> > ../authz/trace.h:1:10: fatal error: trace/trace-authz.h: No such file
>> > or directory
>> > 1 | #include "trace/trace-authz.h"
>>
>> This series only have one change for traces:
>>
>> diff --git a/util/trace-events b/util/trace-events
>> index c8f53d7d9f..16f78d8fe5 100644
>> --- a/util/trace-events
>> +++ b/util/trace-events
>> @@ -93,6 +93,7 @@ qemu_vfio_region_info(const char *desc, uint64_t 
>> region_ofs, uint64_t region_siz
>>  qemu_vfio_pci_map_bar(int index, uint64_t region_ofs, uint64_t
>> region_size, int ofs, void *host) "map region bar#%d addr
>> 0x%"PRIx64" size 0x%"PRIx64" ofs 0x%x host %p"
>>
>>  #userfaultfd.c
>> +uffd_detect_open_mode(int mode) "%d"
>>  uffd_query_features_nosys(int err) "errno: %i"
>>  uffd_query_features_api_failed(int err) "errno: %i"
>>  uffd_create_fd_nosys(int err) "errno: %i"
>>
>> Rest of trace mentions are for the removal of migration.multifd.c.orig
>>
>> And I don't play with authentication at all.
>>
>> This is Fedora 37.
>>
>> > https://gitlab.com/qemu-project/qemu/-/jobs/3749435094
>> > In file included from ../authz/simple.c:23:
>> > ../authz/trace.h:1:10: fatal error: trace/trace-authz.h: No such file
>> > or directory
>>
>> Problem is that this trace file is not generated, but I can think how
>> any change that I did can influence this.
>>
>> > 1 | #include "trace/trace-authz.h"
>> >
>> >
>> > https://gitlab.com/qemu-project/qemu/-/jobs/3749434963
>> > In file included from ../authz/listfile.c:23:
>> > ../authz/trace.h:1:10: fatal error: trace/trace-authz.h: No such file
>> > or directory
>> > 1 | #include "trace/trace-authz.h"
>>
>> Looking at the ouptut of these, they are not informatives at all.
>>
>> I am going to try to compile linux-user without system, and see if that
>> brings a clue.
>
> Yes, I suspect this is a "user-mode only build" specific failure
> (you may need --disable-system --disable-tools to see it).

git-bisect is my friend O:-)

And yes, the problem was in my PULL request.

Again, I don't know why it fails.

diff --git a/tests/bench/meson.build b/tests/bench/meson.build
index daefead58d..7477a1f401 100644
--- a/tests/bench/meson.build
+++ b/tests/bench/meson.build
@@ -3,9 +3,11 @@ qht_bench = executable('qht-bench',
                        sources: 'qht-bench.c',
                        dependencies: [qemuutil])
 
+if have_system
 xbzrle_bench = executable('xbzrle-bench',
                        sources: 'xbzrle-bench.c',
                        dependencies: [qemuutil,migration])
+endif
 
 executable('atomic_add-bench',
            sources: files('atomic_add-bench.c'),

This make it works.

And no, I still not have a single clue how creating a new executable in
tests/bench/ can make trace files not to be generated somewhere else.

> meson.build only puts authz into trace_events_subdirs "if have_block"
> (which is to say "if have_system or have_tools"). However the
> bit of meson.build that says "subdir('authz') does not have
> the same condition on it -- it's just been put in the list without
> any condition on it. So I think that in a build-only-user-emulators
> config meson will not generate trace events for the subdirectory
> but will try to build it, which falls over.
>
> Contrast 'block', 'nbd', 'scsi', which are all guarded by
> 'if have_block' for their subdir() lines, to match the guard on
> the trace_events_subdirs. OTOH 'io' is also mismatched-guards...
>
> Why this only shows up with your pullreq I have no idea.

xbzrle_bench.
Notice that dependency on migration.

As said, I compile every user and system targets that compile in fedora
before I submit a PULL request.
But it is getting clear than that is not enough anymore.

Sorry about the noise.

Will resubmit the PULL requset.

Later, Juan.


Reply via email to