Closed llvmbot closed 8 years ago
I have tried to compile Chrome with r284034. While I still see some issues, they seem to be unrelated to the one reported here. It's safe to say that the bug is fixed.
Thank you very much!
Ivan, p[ease try r284034. Thanks!
"
FWIW, gold (the plugin) seems to pass to thinLTO a MemoryBufferRef identified by:
"llvm.
diff --git a/ELF/InputFiles.cpp b/ELF/InputFiles.cpp index e3266f1..661e200 100644 --- a/ELF/InputFiles.cpp +++ b/ELF/InputFiles.cpp @@ -713,7 +713,16 @@ static Symbol createBitcodeSymbol(const DenseSet<const Comdat > &KeptComdats,
template
Extended Description
Consider the following program (the full reproducer is attached):
main.cc uses symbols from two other files: one/timezone.cc and two/timezone.cc (the "timezone" is irrelevant; the meaningful part is that the name are the same, though that paths and contents are different).
The object files are linked through archives: libone.a and libtwo.a:
clang++ -o one/timezone.o -c one/timezone.cc -flto=thin llvm-ar rcsD libone.a one/timezone.o clang++ -o two/timezone.o -c two/timezone.cc -flto=thin llvm-ar rcsD libtwo.a two/timezone.o
clang++ -c main.cc -flto=thin clang++ -o main main.o libone.a libtwo.a -flto=thin -fuse-ld=lld
On top of that, it's ThinLTO, and full (not thin) archives.
This fails with:
$ ./build.sh
undefined symbol: base::CountryCodeForCurrentTimezone() clang-3.9: error: linker command failed with exit code 1 (use -v to see invocation)
Gold links correctly (so, it's not an LTO bug per se) Full LTO (-flto) instead of -flto=thin links correctly Regular (non-lto) build works correctly Thin archives (rcsDT) work correctly.
So, it's a combination of lld + ThinLTO + regular archives + the object name collision.