[cfe-dev] [10.0.0 Release] Release Candidate 1 is here

[Martijn Otto via cfe-dev]

On Thu, 2020-01-30 at 14:38 -0500, Hans Wennborg via cfe-dev wrote:
> Hello everyone,
> 
> It took a bit longer than planned due to master being a somewhat
> unstable at the branch point, but Release Candidate 1 has now been
> tagged as llvmorg-10.0.0-rc1.
> 
> Source code and docs are available at 
> https://prereleases.llvm.org/10.0.0/#rc1
> 
> Pre-built binaries will be added there as they become available.
> 
> Please file bug reports for any issues you find as blockers of
> https://llvm.org/pr44555
> 
> Release testers: please start your engines, run the script, share
> your
> results, and upload binaries.
> 
> Release Candidate 2 was previously scheduled for February 2. Because
> of the late RC1, I've pushed this back a bit to the 11th.
> 
> Thanks,
> Hans
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

I didn't open any bugs yet, because as of yet I'm not sure the problem
isn't on my side.

I checked out the release branch (release/10.x) and configured to build
clang with compiler-rt enabled:

cmake -B build -S llvm -DCMAKE_BUILD_TYPE=Release
-DCMAKE_INSTALL_PREFIX=/usr/lib/llvm-10
-DLLVM_ENABLE_PROJECTS='clang;libcxx;libcxxabi;compiler-rt'

When I then build the program, it results in a linker error:

[ 79%] Linking CXX shared library
../../../../lib/clang/10.0.0/lib/linux/libclang_rt.hwasan-x86_64.so
/usr/bin/ld: CMakeFiles/RTHwasan_dynamic.x86_64.dir/hwasan.cpp.o:
relocation R_X86_64_PC32 against undefined symbol `__ehdr_start' can
not be used when making a shared object; recompile with -fPIC

Looking at the offending code, it mentions that it is supposed to be a
"statically linked executable":

  // In the non-static code path we call dl_iterate_phdr here. But at
this point
  // libc might not have been initialized enough for dl_iterate_phdr to
work.
  // Fortunately, since this is a statically linked executable we can
use the
  // linker-defined symbol __ehdr_start to find the only relevant set
of phdrs.
  extern ElfW(Ehdr) __ehdr_start;

Clearly, some of these assumptions aren't holding true and it's trying
to use this inside a shared object.

If I build clang without compiler-rt I do not get any linker errors and
the compiler works as expected. Is this a new bug or am I doing
something wrong?