On 18.07.2024 14:54, Tamas K Lengyel wrote: > On Thu, Jul 18, 2024 at 7:17 AM Jan Beulich <jbeul...@suse.com> wrote: >> On 26.06.2024 00:47, Tamas K Lengyel wrote: >>> +cd xen >> >> This looks to suggest that the expectation is for the script to be invoked >> from the root of a xen.git clone. Imo something like >> >> cd $(dirname $0)/../../xen >> >> would be more flexible. > > No, it will be invoked after a git clone is made, so you have to enter > the xen folder that was just cloned.
Yet the suggested alternative would still work then, wouldn't it? And it would permit easier use of the script from outside of that very specific environment, e.g. when wanting to re-invoke it without running a full cloning process every time. >>> +make clang=y -C tools/include >>> +make clang=y -C tools/fuzz/x86_instruction_emulator libfuzzer-harness >> >> In how far is it a requirement to have "clang=y" here? Wasn't this question >> even asked before? I'm not even sure whether mid- or long-term we mean to >> retain that functionality. Overrides of tool chain (components) may better >> be done using CC= and friends. Plus perhaps by whoever is invoking this >> script? > > It is an absolute requirement to use clang=y here as oss-fuzz uses a > specific clang as compiler for C/C++ projects. The CC environment > variables are already set by the oss-fuzz docker environment but it's > insufficient for a successful clang build. Without clang=y the > following error is encountered: > > gcc: error: unrecognized debug output level 'line-tables-only' > gcc: error: unrecognized argument to '-fsanitize=' option: 'fuzzer-no-link' Could you add a sentence to this effect to the description? Jan
