[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [creduce-dev] Close to New C-Reduce Release

In other words, "configure" without extra options fails and so does explicitly choosing g++.

CC=gcc CXX=g++ ./configure

Again, this has always worked.  There is a bug.


On 9/22/15 9:00 PM, John Regehr wrote:
Eric, I was trying to build C-Reduce using g++ and it failed.  This
can't be correct behavior.  This has always worked in the past.


On 9/22/15 8:55 PM, Eric Eide wrote:
John Regehr <regehr@cs.utah.edu> writes:

Current C-Reduce works just fine on OS X but I have three things that we
should fix:

"configure" fails for me on Ubuntu 14.04, see the relevant part of
below.  I don't understand why autoconf is invoking g++ when ostensibly
attempting to check if it can compile/link with LLVM.

tl;dr You need to set CXX at configure time.

The test should use whatever C++ compiler you've specified for building
C-Reduce.  If you haven't specified one, Autoconf's default is g++.

So, for example, from one of my logs today...

$ CXX=/usr/lib/llvm-3.7/bin/clang++ ./configure

In config.log:

configure:15933: checking can compile with and link with LLVM(engine)
configure:15959: /usr/lib/llvm-3.7/bin/clang++ -o conftest -g -O2
T_MACROS -D__STDC_LIMIT_MACROS -g -O2 -fomit-frame-pointer -std=c++11
ity-inlines-hidden -fno-exceptions -fPIC -ffunction-sections
-fdata-sections -W\
cast-qual  conftest.cpp  -lLLVMX86Disassembler -lLLVMX86AsmParser
Gen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMCodeGen -lLLVMScalarOpts
ofileData -lLLVMInstCombine -lLLVMInstrumentation -lLLVMTransformUtils
a -lLLVMX86Desc -lLLVMMCDisassembler -lLLVMX86Info -lLLVMX86AsmPrinter
6Utils -lLLVMMCJIT -lLLVMExecutionEngine -lLLVMTarget -lLLVMAnalysis
imeDyld -lLLVMObject -lLLVMMCParser -lLLVMBitReader -lLLVMMC
upport -L/usr/lib/llvm-3.7/lib  -lz -lpthread -lffi -ledit -ltinfo
-ldl -lm  >&\

I would tend to believe that the failure you saw is correct behavior
for the
test, since the test models how we are going to try to build things
later on
(splatting in LLVM's compilation options, etc.).

We could conceivably change the default for CXX.  That isn't
guaranteed to work
either, but perhaps it is less likely to fail.  I'll give this some
but it seems to me like something we would want to change after the
not before, since the current behavior of CXX is long-standing and
for Autoconf'ed projects.