On Thu, Jul 18, 2024 at 9:03 AM Jan Beulich <jbeul...@suse.com> wrote: > > 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.
This script is specifically made for that one environment and is not intended to be invoked from anywhere else. I don't think we need to complicate this needlessly. > > >>> +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? Sure. Thanks, Tamas
