Bug 1544964

Summary: american-fuzzy-lop-clang-fast requires llvm-4.0, doesn't work with 5.0
Product: [Fedora] Fedora Reporter: Fabian Giesen <fabiang>
Component: american-fuzzy-lopAssignee: Richard W.M. Jones <rjones>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 27CC: nmavrogi, p, rjones
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: american-fuzzy-lop-2.49b-4.fc27 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1547444 (view as bug list) Environment:
Last Closed: 2018-03-06 17:21:46 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1547444    
Bug Blocks:    

Description Fabian Giesen 2018-02-13 21:25:08 UTC
Description of problem:

The afl-clang-fast binary fails to compile any C files if llvm-5.0 is installed, due to an unresolved symbol in the llvm pass .so.

Version-Release number of selected component (if applicable):

american-fuzzy-lop-clang-fast.x86_64 2.49b-3.fc27

How reproducible:

Always

Steps to Reproduce:
1. Install clang-5.0 and american-fuzzy-lop-clang
2. Try to compile any C/C++ program with afl-clang-fast (a "hello, world" suffices)

Actual results:

Compilation fails with a ld.so error trying to resolve a symbol from LLVM.

Expected results:

Compilation should work.

Additional info:

1. The package should probably contain a dependency on the LLVM major version the afl-clang-fast instrumentation pass was built against, since the LLVM API is not stable between major versions.
2. It would be nice if there were an updated version of the package for the new LLVM 5.0 based Clang.

Comment 1 Richard W.M. Jones 2018-02-13 21:59:02 UTC
The problem seems to be that clang 5 was pushed to Fedora 27 without
rebuilding dependencies ...

Unfortunately it seems as if the clang package doesn't export
any 'clang(major)' symbol as is the case with GCC:

$ rpm -q --provides -f /usr/bin/clang
clang = 6.0.0-0.4.rc1.fc28
clang(x86-64) = 6.0.0-0.4.rc1.fc28

$ rpm -q --provides -f /usr/bin/gcc
bundled(libiberty)
gcc = 7.2.1-6.fc28
gcc(major) = 7           <---------
gcc(x86-64) = 7.2.1-6.fc28
liblto_plugin.so.0()(64bit)

Comment 2 Fabian Giesen 2018-02-14 00:44:21 UTC
Oh, forgot to mention this in the original report: it works fine if I manually downgrade to clang and llvm 4.0.1.

Comment 3 Richard W.M. Jones 2018-02-21 10:38:23 UTC
*** Bug 1547414 has been marked as a duplicate of this bug. ***

Comment 4 Richard W.M. Jones 2018-02-21 10:41:11 UTC
I've submitted a new build of afl which should build against the
new clang and hence fix the problem.

Unfortunately this is going to keep happening in future so I will
file a bug against clang to add a ‘clang(major)’ symbol.

Comment 5 Fedora Update System 2018-02-21 10:45:07 UTC
american-fuzzy-lop-2.49b-4.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-0b9a899afe

Comment 7 Fedora Update System 2018-02-21 17:18:01 UTC
american-fuzzy-lop-2.49b-4.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-0b9a899afe

Comment 8 Fedora Update System 2018-03-06 17:21:46 UTC
american-fuzzy-lop-2.49b-4.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.