Need help: libpsl build failure

[rockdaboot]

The libicu dependency fails to build (all of a sudden), the ./configure run says

Step #28: configure: error: Namespace support is required to build ICU.
Step #28: checking for namespace support... no

It looks like this is the ASAN build, so I tried to reproduce locally (infra/helper.py build_fuzzers --sanitizer libpsl) with the latest commit from upstream, and downloading the latest image.

Not to reproduce here :-(

Could someone take a look, please ?. The libicu version is the same since a long time (59.1), so I assume something changed in the environment.

See the current libpsl log at:
https://oss-fuzz-build-logs.storage.googleapis.com/log-496fcc8a-6de3-4198-97e8-410eda12e759.txt

[oliverchang]

Could you please rebuild the libpsl image:

$ python infra/helper.py build_image libpsl

and answer y to

Pull latest base images (compiler/runtime)? (y/N)

And try again? It's possible that a compiler change (in a base image) caused this.

[rockdaboot]

That's what I meant with "downloading the latest image". Sorry for being unprecise.

[rockdaboot]

Just tried it again, same results (only success, issue is not reproducible).

python infra/helper.py build_image libpsl
  #(answering y)
python infra/helper.py build_fuzzers --sanitizer address libpsl
python infra/helper.py build_fuzzers --sanitizer undefined libpsl

[caolanm]

This specific failure in the icu configure affects libpsl, dlplibs and libreoffice. I tweaked the libreoffice build to dump the config.log on failure, because this is not happening locally and the error is...

clang++ -stdlib=libc++ -fsanitize-blacklist=/src/libreoffice/bin/sanitize-blacklist.txt -o conftest -O1 -fno-omit-frame-pointer -gline-tables-only -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fsanitize-coverage=bb,no-prune,trace-pc-guard -O0 -stdlib=libc++ -std=gnu++14 -O2 -fno-strict-aliasing -DU_USE_STRTOD_L=0 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long -DHAVE_GCC_ATOMICS=0 -ffunction-sections -fdata-sections -Wl,--hash-style=gnu -Wl,-Bsymbolic-functions -Wl,--gc-sections conftest.cpp -lpthread -lm >&5
Step #20: /usr/bin/ld: conftest: sh_link of section __sancov_guards' points to discarded section .text._ZN9x_version1fEv' of `/tmp/conftest-7c5cad.o'
Step #20: /usr/bin/ld: final link failed: Bad value
Step #20: clang-8: error: linker command failed with exit code 1 (use -v to see invocation)
Step #20: configure:6771: $? = 1
Step #20: configure: failed program was:
Step #20: | /* confdefs.h /
Step #20: | #define PACKAGE_NAME "ICU"
Step #20: | #define PACKAGE_TARNAME "International Components for Unicode"
Step #20: | #define PACKAGE_VERSION "62.1"
Step #20: | #define PACKAGE_STRING "ICU 62.1"
Step #20: | #define PACKAGE_BUGREPORT "http://icu-project.org/bugs"
Step #20: | #define PACKAGE_URL "http://icu-project.org"
Step #20: | #define STDC_HEADERS 1
Step #20: | #define HAVE_SYS_TYPES_H 1
Step #20: | #define HAVE_SYS_STAT_H 1
Step #20: | #define HAVE_STDLIB_H 1
Step #20: | #define HAVE_STRING_H 1
Step #20: | #define HAVE_MEMORY_H 1
Step #20: | #define HAVE_STRINGS_H 1
Step #20: | #define HAVE_INTTYPES_H 1
Step #20: | #define HAVE_STDINT_H 1
Step #20: | #define HAVE_UNISTD_H 1
Step #20: | #define SIZEOF_VOID_P 8
Step #20: | #define HAVE_LIBM 1
Step #20: | #define HAVE_ELF_H 1
Step #20: | #define HAVE_GETTIMEOFDAY 1
Step #20: | #define HAVE_LIBPTHREAD 1
Step #20: | #define HAVE_INTTYPES_H 1
Step #20: | #define HAVE_DIRENT_H 1
Step #20: | / end confdefs.h. */
Step #20: | namespace x_version {void f(){}}
Step #20: | namespace x = x_version;
Step #20: | using namespace x_version;
Step #20: |
Step #20: | int
Step #20: | main ()
Step #20: | {
Step #20: | f();
Step #20: | ;
Step #20: | return 0;
Step #20: | }
Step #20: configure:6780: result: no
Step #20: configure:6784: error: Namespace support is required to build ICU.

[caolanm]

passing ac_cv_namespace_ok=yes to the icu configure should skip the test and default it to true. I'll try that for LibreOffice and see if it fails somewhere else.

@dtardon FYI wrt the dlplibs build failure

[caolanm]

blast, still fails later...

Step #20: /usr/bin/ld: icuinfo: sh_link of section __sancov_guards' points to discarded section .text._Z10cmd_millisv' of `icuinfo.o'

[oliverchang]

@eugenis @kcc @morehouse any idea what might be causing this?

Step #20: /usr/bin/ld: conftest: sh_link of section __sancov_guards' points to discarded section.text._ZN9x_version1fEv' of `/tmp/conftest-7c5cad.o'
Step #20: /usr/bin/ld: final link failed: Bad value
Step #20: clang-8: error: linker command failed with exit code 1 (use -v to see invocation)

No idea why it doesn't reproduce locally... Only major difference should be the host kernel.

[caolanm]

I was able to reproduce the LibreOffice failure after updating the build image with
python infra/helper.py build_image libreoffice
and https://oss-fuzz-build-logs.storage.googleapis.com/index.html now reports success after adding --disable-release to the icu configure.

When built as a static library without --disable-release icu is adding -ffunction-sections -fdata-sections to CXXFLAGS and -Wl,--gc-sections to LDFLAGS, --disable-release suppresses that so might also help in this libpsl/dlplibs case

[eugenis]

@morehouse Most certainly related to https://reviews.llvm.org/D50483.
That's where sh_link comes from.
Note that ASan enables this logic only when using -fdata-sections, I don't remember why. There is no such condition in SanitizerCoverage.

[morehouse]

That does seem to be the problematic change. I can reproduce locally with BFD linker. One workaround is to use LLD or Gold linkers.

Still looking for a better fix than just reverting the change, since it was done to fix a different problem...

[morehouse]

https://reviews.llvm.org/rL342186 fixes #1789 (comment) for me locally.

@oliverchang Rolling past r342186 will probably fix this.

[Dor1s]

Are we in rush on this or can wait a few days while Chromium rolls clang forward for us?

[oliverchang]

@Dor1s just rolled us past that revision in e348738 so this should be resolved soon.

[inferno-chromium]

green build