make error building llvm/clang 3.2 on Linux

I'm attempting to build a native build of clang from the 3.2 source
distribution tarballs, but I ran into this build error that's got me
really puzzled. My platform is Linux - 32-bit Ubuntu (12.04) running
on a PC. Here's the (abbreviated) output from make:

I'm continuing this here in llvm-dev since the thread was started here,
but, in hindsight, it may have been better in cfe-dev, because the
problem seems to be related to clang.

I turned on "verbose" mode in make (VERBOSE=1 TOOL_VERBOSE=1) and found
that it is clang, not gcc, that is being used at this point in the make.
Based on the command issued (particularly with the --sysroot options),
I surmised that I'm picking up the wrong <mman.h>. The one in the
specified sysroot dir doesn't have a #include <features.h> (which is not
being found). So where is the mman.h being picked up??? Well, I find
it at /usr/include/i386-linux-gnu/sys, and, lo and behold, there is a
#include <features.h> at line 23, just at the location reported with
the error. And why is clang looking in "/usr/include/i386-linux-gnu"?
Because I had defined the C_INCLUDE_PATH environment variable with this
directory. When I reset this (and LIBRARY_PATH and CPLUS_INCLUDE_PATH)
to empty, I can proceed with the make.

Here's the problem - I have to have these environment variables defined
to allow gcc to work (without them, I can't even get through configure).
Ubuntu 11.10, 12.04, and perhaps later versions, put things in
"non-standard" locations, and this is the workaround - see
"http://gcc.gnu.org/ml/gcc/2012-02/msg00314.html" for details. That's
fine, but clang apparently uses these environment variables, too, and,
based on my results, I really don't think I want clang to pick these
up, at least not when clang has sysroot specified (as it is in the
make).

Unfortunately, the make later reverts back to using gcc (actually g++),
and it breaks again without the environment variables being defined
with the appropriate directories.

So is there an easy way to have gcc/g++ use these variables and not
clang? That should allow me to get through a build (make) cleanly.

Thanks,
Mike

Hi Michael, you don't need compiler-rt to use clang. If you don't need it, I
suggest you don't bother building it.

Ciao, Duncan.

Just in case someone is having similar problems and/or following this
thread, here's my final "solution" (at least, for now).

In my bash build script, prior to configure, I set the C_INCLUDE_PATH
and CPLUS_INCLUDE_PATH to empty strings, and then set some other
environment variables instead:

export C_INCLUDE_PATH=
export CPLUS_INCLUDE_PATH=

SYSTEM_INCLUDE_PATH="/usr/include/i386-linux-gnu"

export CC=gcc
export CXX=g++
export CFLAGS="-isystem ""${SYSTEM_INCLUDE_PATH}"""
export CXXFLAGS="-isystem ""${SYSTEM_INCLUDE_PATH}"""

This allowed me to build (configure and make) without error.

It's not pretty, it's not perfect, but it seems to work.

Since the LIBRARY_PATH environment variable is still set in this
"solution", I'm slightly concerned that I may be picking up incorrect
libraries with clang (I'm not sure whether clang actually uses this
variable), but everything so far, including the testsuite (with a
subsequent "make check-all"), does seem to compile, link, and run
without problems.

Note that I did try to do the same with LIBRARY_PATH (using
SYSTEM_LIBRARY_PATH="/usr/lib/i386-linux-gnu"
export LDFLAGS="-L""${SYSTEM_LIBRARY_PATH}"""
instead), but configure still choked when running gcc - it couldn't
find the crt*.o libraries. Here's the relevant output from the
config.log file:

Hi Michael, you don't need compiler-rt to use clang. If you don't need it, I
suggest you don't bother building it.

Thanks for the advice.

I realize that clang doesn't need it, but I was going to investigate
compiler-rt for use in my own project(s), so I was compiling the works.
That may be a little premature, since I still have a lot to grok with
just LLVM, where my primary interest lies (specifically, in developing
a compiler). I'm interested in clang because, thus far, amongst all
the compilers I know of, it has the best C++11 support.

Anyway, I seem to have found a build setup that works.

Thanks,
Mike

Michael,

This behavior repeats itself on Debian Linux when I update GCC 4.7.2 to anything above the current pathways of the Sid branch release of GCC/Libstdc++ collection.

I’ve tested it twice with their latest updates for the 4.7.2 branch in Experimental and nothing on there end changes and from prior issues with this someone either has to update the pathways for these directory structures in LLVM/Clang or don’t even bother first building LLVM/Clang with anything newer than

gcc-4.7.2-5 and all that includes with gcc-4.7-base, etc.

This is fine with me because I’d rather let Debian muck with all the llvm-toolchain-3.2 attempts they continue to try:

http://qa.debian.org/developer.php?login=pkg-llvm-team@lists.alioth.debian.org

before I update any release from them. I’ve just stuck with 4.7.2-5 and building trunk once and then configuring with cmake the necessary paths in the newest trunk to make everything build under /usr/local

  • Marc Driftmeyer

Following up just in case anyone is looking at this in the future in an attempt to solve a similar issue.
I can now successfully build gcc-4.8.0 (and llvm/compiler-rt/clang/test-suite 3.2) on Ubuntu 12.04 (x86, 32-bit, desktop edition) without setting any environment variables (C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, LIBRARY_PATH). So the ideal solution is to not use a locally built gcc-4.7 on Ubuntu 12.04, especially to build LLVM 3.2.
- Michael