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:

Previous
From: Magnus Hagander
Date:
Subject: Re: BGWORKER_BYPASS_ALLOWCONN used nowhere (infra part of on-linechecksum switcher)
Next
From: Pierre Ducroquet
Date:
Subject: Re: Build fails with different versions of clang and LLVM