Overview
Request 763889 accepted
- Add upstream patch to export compiler-rt FuzzedDataProvider header,
required by Envoy 1.12.2:
* compiler-rt-move-fdp.patch
- Created by jaicaa
- In state accepted
-
Package maintainers:
aaronpuchert and
ptesarik
- Supersedes 762116
5-# Copyright (c) 2020 SUSE LLC 6+# Copyright (c) 2020 SUSE LINUX GmbH, Nuernberg, Germany.
You seem to be doing changes from rather old system ...
What do you mean? I am using an updated leap 15.1 with its repo osc 0.165.4.
Then please install spec-cleaner-format_spec_file and/or remove obs-service-format_spec_file - it is reverting this correct changes in unattended matter for you.
As alternative you might run osc with "--noservice" parameter.
The changes to compiler-rt/lib/fuzzer/FuzzerExtFunctions.def seem to indicate that this changes the API of installed libraries, is this intended? I'm not sure if this has unintended side effects.
Nevermind, that doesn't seem to be an issue. However, I don't think there is a reason to patch LLVM here, since all this patch does is add a header. You can just include that header with Envoy for now.
On top of that, I share the concerns of Roman Lebedev from the upstream review.
Yes, we can include the header directly with envoy. We try this first because is less work to apply this upstream patch than doing the envoy side and then redoing it properly in the future.
I was not aware of the upstream concerns. I guess if this is subject to change further sooner rather than later, it may make less sense. I leave it up to you. Thanks!
The header is apparently independent of Clang and delivering it as part of Clang's builtin headers is a pretty strange decision. These headers are supposed to contain the compiler-dependent parts of the standard library, and they are only used when compiling with Clang, not with any other compiler.
However, since the change comes from Google, and Google is a large upstream contributor that has decided that Clang is the only compiler they recognize, I'm not sure if it's subject to change.
The reformatting of the build conditions doesn't seem helpful to me, also I'll probably have to undo the changes to
sed. We want to replace/usr/bin/env, not%{_bindir}/env.I'm still discussing about this header with upstream, because in my opinion there is no reason to deliver this header with Clang.
This is the spec cleaner in action I guess. I agree is not the most helpful formatting sometimes. I did not run explicitly so I guess there should be a way do disable it per project/package?
@pluskalm
Are you aware of any change to run spec cleaner by default in non-minimal way? Or am I running it somehow inadvertently? Thanks!
I think there are different levels of automatic changes, and I don't usually run
spec-cleaner, because it does a little bit too much in my opinion. I'm going with the defaultformat_spec_file. I think. You can probably circumvent it withosc commit --noservice, but that will drop all services.With the package spec-cleaner-format_spec_file installed`, these services run automatically upon osc build:
Run source service: /usr/lib/obs/service/format_spec_file --outdir /home/jcaamano/dev/suse/obs/home:jaicaa:branches:devel:tools:compiler/llvm9/tmpuxemsauj.format_spec_file.service Run source service: /usr/lib/obs/service/source_validator --outdir /home/jcaamano/dev/suse/obs/home:jaicaa:branches:devel:tools:compiler/llvm9/tmpeqxh6ash.source_validator.service
/usr/lib/obs/service/format_spec_file runs: /usr/bin/spec-cleaner -m -f "$i" -i > /dev/null 2>&1
-m stands for minimal. And is doing changes such as replacing /usr/bin with %{_bindir} in that sed command.
Locally, I see no other (standard) option but to uninstall spec-cleaner-format_spec_file. But my guess is that this kind of service might run also server-side.
Hmm, I don't have
spec-cleaner-format_spec_fileinstalled, which makes me use the default implementation offormat_spec_fileinstead. I don't think thespec-cleanerruns on the server, at least I haven't seen it there.