stdarg.h standard header

Patch per subject; not really that much to say about it, except that
the __gnuc_va_list thing is ugly but unavoidable.

After this come float.h and limits.h, which are more complicated if we
want to implement
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2007-December/000560.html.
I don't know how to hack the preprocessor to add something like that,
though; would someone who knows that code better mind doing that?

And after that, we're done with standard headers for C, at least for
compiling programs using the standard library on Ubuntu. For
freestanding programs, we'll also need out own stdint.h. And we still
need to finish the SSE and Altivec intrinsics headers (if someone has
some compact examples using those headers, that would be nice for
testing).

-Eli

t.txt (1.92 KB)

Here a very simple program, t.cc:

#include <clang/Basic/SourceManager.h>

int main(int argc, char** argv) {
  using namespace clang;
  SourceManager source_mgr;

}

Compiling command (taken almost one-to-one from clang executable linking):
g++ -o /dev/null \
t.cc \
-lclangCodeGen \
-lclangAnalysis \
-lclangRewrite \
-lclangSEMA \
-lclangAST \
-lclangParse \
-lclangLex \
-lclangBasic \
-lLLVMCore \
-lLLVMSupport \
-lLLVMSystem \
-lLLVMBitWriter \
-lLLVMBitReader \
-lLLVMCodeGen \
-lLLVMTarget \
-lpthread \
-ldl \
-lm \
-lelf

Result:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib/libLLVMBitReader.a(Deserialize.o):
In function `llvm::Deserializer::~Deserializer()':
Deserialize.cpp:(.text+0xe1): undefined reference to
`llvm::BumpPtrAllocator::~BumpPtrAllocator()' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib/libLLVMBitReader.a(Deserialize.o):
In function `llvm::Deserializer::~Deserializer()':
Deserialize.cpp:(.text+0x181): undefined reference to
`llvm::BumpPtrAllocator::~BumpPtrAllocator()' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib/libLLVMBitReader.a(Deserialize.o):
In function `llvm::Deserializer::Deserializer(llvm::BitstreamReader&)':
Deserialize.cpp:(.text+0x20c): undefined reference to
`llvm::BumpPtrAllocator::BumpPtrAllocator()' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib/libLLVMBitReader.a(Deserialize.o):
In function `llvm::Deserializer::Deserializer(llvm::BitstreamReader&)':
Deserialize.cpp:(.text+0x300): undefined reference to
`llvm::BumpPtrAllocator::BumpPtrAllocator()' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib/libLLVMBitReader.a(Deserialize.o):
In function `llvm::Deserializer::ReadUIntPtr(unsigned long&, unsigned int
const&, bool)': Deserialize.cpp:(.text+0x9bb): undefined reference to
`llvm::BumpPtrAllocator::Allocate(unsigned long, unsigned long)' collect2: ld
returned 1 exit status

What am I doing wrong?

Try putting your libraries in the following order: -lclangCodeGen
-lclangAnalysis -lclangRewrite -lclangSEMA -lclangAST -lclangParse
-lclangLex -lclangBasic -lLLVMBitWriter -lLLVMBitReader -lLLVMCodeGen
-lLLVMTarget -lLLVMSupport -lLLVMCore -lLLVMSystem -lpthread -ldl -lm

I'm not entirely sure how clang avoids running into this; I don't know
very much about linker magic.

-Eli

In the llvm side of things, we use llvm-config to wrangle the library dependencies and figure out what order to link things it. llvm-config works by nm'ing the libraries and building a dependence graph. It should work with clang, but I don't think anyone has tried making it work. It would require rebuilding the llvm-config database after the clang libs are built.

-Chris