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

Martijn Otto via cfe-dev cfe-dev at lists.llvm.org
Mon Feb 3 02:17:02 PST 2020

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

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

[ 79%] Linking CXX shared library
/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
  // 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?

More information about the cfe-dev mailing list