Hi, On 2018-03-13 15:29:33 -0700, Andres Freund wrote: > On 2018-03-14 10:32:40 +1300, Thomas Munro wrote: > > I decided to try this on a CentOS 7.2 box. It has LLVM 3.9 in the > > 'epel' package repo, but unfortunately it only has clang 3.4. > > That's a bit odd, given llvm and clang really live in the same repo...
I don't really live in the RHEL world, but I wonder if https://developers.redhat.com/blog/2017/10/04/red-hat-adds-go-clangllvm-rust-compiler-toolsets-updates-gcc/ is relevant? Appears to be available on centos too https://www.softwarecollections.org/en/scls/rhscl/devtoolset-7/ I checked it out and supporting 3.4 would be a bit painful due to not being able to directly emit module summaries. We could support that by building the summaries separately using LLVM, but that'd be either slower for everyone, or we'd need somewhat finnicky conditionals. > > clang: error: unknown argument: '-fexcess-precision=standard' > > clang: error: unknown argument: '-flto=thin' > > > > Ok, so I hacked src/Makefile.global.in to remove -flto=thin. > > I think I can get actually rid of that entirely. Err, no, not really. Would increase overhead due to separate module summary generation, so I'd rather not do it. > > It looks > > like -fexcess-precision-standard is coming from a configure test that > > was run against ${CC}, not against ${CLANG}, so I hacked the generated > > src/Makefile.global to remove that too, just to see if I could get > > past that. > > Yea, I'd hoped we could avoid duplicating all the configure tests, but > maybe not :(. I've mostly done that now (not pushed). I've created new PGAC_PROG_VARCC_VARFLAGS_OPT(compiler variable, flag variable, testflag) function, which now is used to implement PGAC_PROG_CC_CFLAGS_OPT and PGAC_PROG_CC_VAR_OPT (similar for CXX). That makes it reasonable to test the variables clang recognizes separately. Greetings, Andres Freund
