Bug 181871 – oss-fuzz jsc build is broken: StringImpl.h:27:10: fatal error: 'unicode/ustring.h' file not found

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[David Kilzer (:ddkilzer)]

Title:  jsc build broken
GitHub:  <https://github.com/google/oss-fuzz/issues/1093>

Step #4: FAILED: /usr/local/bin/clang++   -DBUILDING_JSCONLY__ -DBUILDING_WITH_CMAKE=1 -DHAVE_CONFIG_H=1 -DSTATICALLY_LINKED_WITH_WTF -I. -I../../Source/JavaScriptCore -I../../Source/JavaScriptCore/.. -I../../Source/JavaScriptCore/API -I../../Source/JavaScriptCore/ForwardingHeaders -I../../Source/JavaScriptCore/assembler -I../../Source/JavaScriptCore/b3 -I../../Source/JavaScriptCore/b3/air -I../../Source/JavaScriptCore/bindings -I../../Source/JavaScriptCore/builtins -I../../Source/JavaScriptCore/bytecode -I../../Source/JavaScriptCore/bytecompiler -I../../Source/JavaScriptCore/dfg -I../../Source/JavaScriptCore/disassembler -I../../Source/JavaScriptCore/disassembler/udis86 -I../../Source/JavaScriptCore/disassembler/ARM64 -I../../Source/JavaScriptCore/domjit -I../../Source/JavaScriptCore/ftl -I../../Source/JavaScriptCore/heap -I../../Source/JavaScriptCore/debugger -I../../Source/JavaScriptCore/inspector -I../../Source/JavaScriptCore/inspector/agents -I../../Source/JavaScriptCore/inspector/augmentable -I../../Source/JavaScriptCore/inspector/remote -I../../Source/JavaScriptCore/interpreter -I../../Source/JavaScriptCore/jit -I../../Source/JavaScriptCore/llint -I../../Source/JavaScriptCore/parser -I../../Source/JavaScriptCore/profiler -I../../Source/JavaScriptCore/runtime -I../../Source/JavaScriptCore/tools -I../../Source/JavaScriptCore/wasm -I../../Source/JavaScriptCore/wasm/js -I../../Source/JavaScriptCore/yarr -IDerivedSources/ForwardingHeaders -IDerivedSources/JavaScriptCore -IDerivedSources/JavaScriptCore/inspector -IDerivedSources/JavaScriptCore/runtime -IDerivedSources/JavaScriptCore/yarr -I../../Source/bmalloc -I../../Source/WTF -IDerivedSources -I../../Source/ThirdParty -fdiagnostics-color=always -fcolor-diagnostics -Wno-parentheses-equality -Wno-noexcept-type -Qunused-arguments -Wwrite-strings -Wundef -Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align -Wextra -Wall -O1 -fno-omit-frame-pointer -gline-tables-only -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fsanitize=address -fsanitize-address-use-after-scope  -stdlib=libc++ -DU_STATIC_IMPLEMENTATION  -fno-strict-aliasing -fno-exceptions -std=c++14 -fno-rtti -gsplit-dwarf -g -fPIE -MMD -MT Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.o -MF Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.o.d -o Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.o -c ../../Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp
Step #4: In file included from ../../Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:28:
Step #4: In file included from ../../Source/JavaScriptCore/bytecode/ArrayProfile.h:28:
Step #4: In file included from ../../Source/JavaScriptCore/runtime/ConcurrentJSLock.h:28:
Step #4: In file included from ../../Source/JavaScriptCore/heap/DeferGC.h:29:
Step #4: In file included from ../../Source/JavaScriptCore/heap/Heap.h:24:
Step #4: In file included from ../../Source/JavaScriptCore/runtime/ArrayBuffer.h:35:
Step #4: In file included from ../../Source/WTF/wtf/text/WTFString.h:31:
Step #4: ../../Source/WTF/wtf/text/StringImpl.h:27:10: fatal error: 'unicode/ustring.h' file not found
Step #4: #include <unicode/ustring.h>
Step #4:          ^~~~~~~~~~~~~~~~~~~
Step #4: 1 error generated.
Step #4: ninja: build stopped: subcommand failed.
Finished Step #4
ERROR
ERROR: build step 4 "gcr.io/oss-fuzz/jsc" failed: exit status 1

[David Kilzer (:ddkilzer)]

The WPE and GTK Linux ports are compiling without errors on WebKit's buildbots (scroll to the bottom), although they aren't doing clean builds every time: <https://build.webkit.org/dashboard/>

oss-fuzz folks:  Is the <unicode/ustring.h> header installed with the ICU package(s) on the builder?

It appears that the compiler command for Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp is not including a path to the ICU headers. If so, this may be a CMake configuration issue, and Source/JavaScriptCore/CMakeLists.txt may need something like this for the LLIntOffsetsExtractor target:

set(JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES
    "${ICU_INCLUDE_DIRS}"
)

If I had to guess, it would be to add something like this to Source/JavaScriptCore/CMakeLists.txt:

set(LLIntOffsetsExtractor_SYSTEM_INCLUDE_DIRECTORIES
    "${ICU_INCLUDE_DIRS}"
)

However, I'm not a CMake expert, so I have no idea if that would work.

[David Kilzer (:ddkilzer)]

Created attachment 331769 [details]
Patch v1

[David Kilzer (:ddkilzer)]

(In reply to David Kilzer (:ddkilzer) from comment #1)
> If I had to guess, it would be to add something like this to
> Source/JavaScriptCore/CMakeLists.txt:
> 
> set(LLIntOffsetsExtractor_SYSTEM_INCLUDE_DIRECTORIES
>     "${ICU_INCLUDE_DIRS}"
> )
> 
> However, I'm not a CMake expert, so I have no idea if that would work.

I Guessed Different in Attachment #331769 [details]:

target_include_directories(LLIntOffsetsExtractor SYSTEM PUBLIC ${JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES})

[David Kilzer (:ddkilzer)]

Created attachment 331770 [details]
Patch v2

[David Kilzer (:ddkilzer)]

(In reply to David Kilzer (:ddkilzer) from comment #4)
> Created attachment 331770 [details]
> Patch v2

Just fixed the title of the bug in the ChangeLog; no other changes.

[JF Bastien]

Comment on attachment 331770 [details]
Patch v2

rs=me if that works. Thanks!

[David Kilzer (:ddkilzer)]

(In reply to JF Bastien from comment #6)
> Comment on attachment 331770 [details]
> Patch v2
> 
> rs=me if that works. Thanks!

Abhishek confirmed via email that this fixed the build.  Landing shortly.

[David Kilzer (:ddkilzer)]

Committed r227233: <https://trac.webkit.org/changeset/227233>

[Radar WebKit Bug Importer]

<rdar://problem/36669691>

[Konstantin Tokarev]

This change is correct. It could have been SYSTEM PRIVATE to match PRIVATE on previous line, but for executable target it actually makes no difference.

[David Kilzer (:ddkilzer)]

(In reply to Konstantin Tokarev from comment #10)
> This change is correct. It could have been SYSTEM PRIVATE to match PRIVATE
> on previous line, but for executable target it actually makes no difference.

Landed this change in:

Committed r227453: <https://trac.webkit.org/changeset/227453>

Thanks!