| Age | Commit message (Collapse) | Author |
|---|
|
Now that draw depends on llvm it is very difficult to correctly handle
broken llvm installations. Either the user requests LLVM and it needs to
supply a working installation. Or it doesn't, and it gets no LLVM
accelerate pipe drivers.
|
|
This reverts commit 44703217f73095c4946e06057e399e447b252576.
http://www.llvm.org/bugs/show_bug.cgi?id=6429 has been fixed now. Things
appear to be working reasonably so far.
|
|
LLVM's trunk is totally broken, at least for x86_64.
See http://www.llvm.org/bugs/show_bug.cgi?id=6429
|
|
|
|
|
|
|
|
ad-hoc definitions.
Everybody is using the C99's integer types. Everybody except Microsoft,
which in turns means everybody is including their own definitions of C99
integer types for MSVC, causing duplicate definitions when linking two
projects. This is the case of building Gallium and LLVM with MSVC.
Shipping alternative stdint.h and stdbool.h headers for MSVC allows us
to share a single definition. It also removes clutter from the Gallium
headers.
|
|
LLVM 2.5 is no longer supported on windows.
|
|
Doesn't quite work yet though, as small differences in the compilation flags
used when building LLVM and Mesa cause link failures for STL symbols.
|
|
|
|
Ubuntu 8.10 has llvm-config version 2.2, which doesn't have
nativecodegen. This triggers an exception.
|
|
|
|
|
|
|
