Build fails with different versions of clang and LLVM - Mailing list pgsql-hackers
From | Heikki Linnakangas |
---|---|
Subject | Build fails with different versions of clang and LLVM |
Date | |
Msg-id | 2eda6b0f-cf08-b847-c33a-cb0e746d21ef@iki.fi Whole thread Raw |
Responses |
Re: Build fails with different versions of clang and LLVM
Re: Build fails with different versions of clang and LLVM |
List | pgsql-hackers |
Hi! I tried compiling with --with-llvm on my laptop, and got this: > $ make -s > All of PostgreSQL successfully made. Ready to install. > $ make -s install > Invalid Summary Block: version expected > error: can't create ModuleSummaryIndexObjectFile for buffer: Corrupted bitcode > #0 0x00007fbe98032085 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/lib/llvm-3.9/bin/../lib/libLLVM-3.9.so.1+0x707085) > #1 0x00007fbe9803023e llvm::sys::RunSignalHandlers() (/usr/lib/llvm-3.9/bin/../lib/libLLVM-3.9.so.1+0x70523e) > #2 0x00007fbe98030362 (/usr/lib/llvm-3.9/bin/../lib/libLLVM-3.9.so.1+0x705362) > #3 0x00007fbe9771f160 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12160) > #4 0x00007fbe985cfba4 (/usr/lib/llvm-3.9/bin/../lib/libLLVM-3.9.so.1+0xca4ba4) > #5 0x00007fbe985e3318 llvm::WriteIndexToFile(llvm::ModuleSummaryIndex const&, llvm::raw_ostream&, std::map<std::__cxx11::basic_string<char,std::char_traits<char>, std::allocator<char> >, std::map<unsigned long, llvm::GlobalValueSummary*,std::less<unsigned long>, std::allocator<std::pair<unsigned long const, llvm::GlobalValueSummary*>> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >>, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::map<unsignedlong, llvm::GlobalValueSummary*, std::less<unsigned long>, std::allocator<std::pair<unsigned long const,llvm::GlobalValueSummary*> > > > > >*) (/usr/lib/llvm-3.9/bin/../lib/libLLVM-3.9.so.1+0xcb8318) > #6 0x000055d1120f4ac7 (/usr/lib/llvm-3.9/bin/llvm-lto+0x19ac7) > #7 0x000055d1120f5f95 (/usr/lib/llvm-3.9/bin/llvm-lto+0x1af95) > #8 0x000055d1120ea0f0 _init (/usr/lib/llvm-3.9/bin/llvm-lto+0xf0f0) > #9 0x00007fbe96a96f2a __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20f2a) > #10 0x000055d1120ebe8a _init (/usr/lib/llvm-3.9/bin/llvm-lto+0x10e8a) > Stack dump: > 0. Program arguments: /usr/lib/llvm-3.9/bin/llvm-lto -thinlto -thinlto-action=thinlink -o postgres.index.bc postgres/access/brin/brin.bcpostgres/access/brin/brin_pageops.bc [LOT OF FILES REMOVED TO KEEP THIS SHORT] postgres/utils/fmgrtab.bcpostgres/jit/jit.bc > Segmentation fault > Makefile:246: recipe for target 'install-postgres-bitcode' failed > make[2]: *** [install-postgres-bitcode] Error 139 > Makefile:42: recipe for target 'install-backend-recurse' failed > make[1]: *** [install-backend-recurse] Error 2 > GNUmakefile:11: recipe for target 'install-src-recurse' failed > make: *** [install-src-recurse] Error 2 I think this is because I have a funny combination of clang and LLVM: > $ clang --version > clang version 3.8.1-24 (tags/RELEASE_381/final) > Target: x86_64-pc-linux-gnu > Thread model: posix > InstalledDir: /usr/bin > $ llvm-config --version > bash: llvm-config: command not found > $ llvm-config-3.9 --version > 3.9.1 So, I have LLVM 3.9 installed, but no clang 3.9. Only clang 3.8. The autoconf macro in llvm.m4 says: > # Could check clang version, but it doesn't seem that > # important. Systems with a new enough LLVM version are usually > # going to have a decent clang version too. It's also not entirely > # clear what the minimum version is. In light of the above error, I think we should do more. Apparently LLVM 3.9 cannot read bitcode files generated by clang 3.8, so we should at least check that clang version is 3.9 or above. Googling around, the LLVM bitcode format is supposed to be compatible across versions, but I'm not sure I trust that. Perhaps we should check that the LLVM and clang versions match? Instead of searching for any 'clang' program with PGAC_PATH_PROGS, perhaps we should always use "`lvm-config-3.9 --bindir`/clang", throwing an error if it doesn't exist. BTW, I'm surprised that llvm-lto is invoked in the "make install" stage. I would expect it to be done by plain "make" already, and "make install" would just copy the files to the right places. - Heikki
pgsql-hackers by date: