Build fails with different versions of clang and LLVM

On Monday, April 23, 2018 10:33:04 AM CEST Heikki Linnakangas wrote:

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<unsigned
long, 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.bc postgres/access/brin/brin_pageops.bc [LOT OF
FILES REMOVED TO KEEP THIS SHORT] postgres/utils/fmgrtab.bc
postgres/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.

Hi

The bitcode format does not respect strict compatibility rules. LLVM and clang
versions must match if we don't want any surprise.
See for instance
https://stackoverflow.com/questions/15836430/how-stable-is-the-llvm-assembly-language

In your case, this should have worked, but I am not surprised at all that this
failed, I had similar issues when testing 3.9/4.0 on the same system. I
thought the build system already checked for version equality.

Pierre

Hi,

On 2018-04-23 04:33:04 -0400, Heikki Linnakangas wrote:

So, I have LLVM 3.9 installed, but no clang 3.9. Only clang 3.8.

Any specific reason, or just happenstance?

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.

That'll commonly not exist I think. I kinda think we should just wait a
bit till we've collected more experience..

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.

If you can come up with decent make foo, I'm open to changing that, but
I couldn't come up with something neatly encapsulated... It's just an
index over the individual files, so it didn't seem that crazy.

Greetings,

Andres Freund

On 23/04/18 18:28, Andres Freund wrote:

Hi,

On 2018-04-23 04:33:04 -0400, Heikki Linnakangas wrote:

So, I have LLVM 3.9 installed, but no clang 3.9. Only clang 3.8.

Any specific reason, or just happenstance?

Just happenstance. I had clang and llvm 3.8 installed previously. But
PostgreSQL needs llvm 3.9, so I installed that, but I didn't think to
install clang 3.9.

To add to the story: I installed clang 3.9, but I still got the same
error. I now had both clang 3.8 and 3.9 installed, but /usr/bin/clang
still pointed to clang-3.8, so autoconf still picked that up. Only after
removing clang-3.8 altogether, it started working.

For the record, this is on a pretty normal Debian Stretch installation.

- Heikki

Hi,

On 2018-04-23 18:33:30 +0300, Heikki Linnakangas wrote:

To add to the story: I installed clang 3.9, but I still got the same error.
I now had both clang 3.8 and 3.9 installed, but /usr/bin/clang still pointed
to clang-3.8, so autoconf still picked that up. Only after removing
clang-3.8 altogether, it started working.

And CLANG=clang-3.9 to autoconf didn't cure that?

I've experimented a bit w/ this and there seem to be fewer cross-version
issues in newer clang/llvm versions.

Greetings,

Andres Freund

On 23/04/18 18:35, Andres Freund wrote:

Hi,

On 2018-04-23 18:33:30 +0300, Heikki Linnakangas wrote:

To add to the story: I installed clang 3.9, but I still got the same error.
I now had both clang 3.8 and 3.9 installed, but /usr/bin/clang still pointed
to clang-3.8, so autoconf still picked that up. Only after removing
clang-3.8 altogether, it started working.

And CLANG=clang-3.9 to autoconf didn't cure that?

Oh, I'm sure it would have, I didn't try that :-).

I've experimented a bit w/ this and there seem to be fewer cross-version
issues in newer clang/llvm versions.

Good to hear. Nevertheless, I think we should try a bit harder to ensure
that we pick the same version of clang and LLVM. Even if they're
compatible, just seems more straightforward that way. And we now know
there is an incompatibility between 3.8 and 3.9, at least.

- Heikki