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: > > --- /dev/null > > +++ b/scripts/oss-fuzz/build.sh > > @@ -0,0 +1,23 @@ > > +#!/bin/bash -eu > > +# SPDX-License-Identifier: Apache-2.0 > > Hmm. Aiui this line is supposed to make unnecessary ... > > > +# Copyright 2024 Google LLC > > +# > > +# Licensed under the Apache License, Version 2.0 (the "License"); > > +# you may not use this file except in compliance with the License. > > +# You may obtain a copy of the License at > > +# > > +# http://www.apache.org/licenses/LICENSE-2.0 > > +# > > +# Unless required by applicable law or agreed to in writing, software > > +# distributed under the License is distributed on an "AS IS" BASIS, > > +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > > +# See the License for the specific language governing permissions and > > +# limitations under the License. > > ... all of this text, provided an entry is first put in ./LICENSES/. > > > +################################################################################ > > + > > +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. > > > +./configure --disable-stubdom --disable-pvshim --disable-docs --disable-xen > > Going forward we mean to no longer bundle e.g. qemu in release tarballs, > yet I wonder whether passing a couple of --with-system-...= here wouldn't > be better nevertheless. It largely doesn't matter as long as the configure script completes successfully since we aren't going to compile QEMU. But sure, I can add it. > > > +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' Tamas
