This will at least update the version string on the title page
when the book source changes. It may not be entirely accurate
since rust.texi may have uncommitted changes. But previously,
it was basically only ever updated on the first build or after
'make clean'.
On gcc 4.5.1 (fedora 14 i686) rust_test_runtime.cpp fails to compile
with the following error:
rt/test/rust_test_runtime.cpp:57:61: error: passing NULL to non-pointer argument 3 of ‘void rust_task::start(uintptr_t, uintptr_t, uintptr_t, size_t)’
The explicit cast works around the error.
This change is thanks to Peter Hull, who independently resolved
the 2.8 vs 2.8svn issue this way. His patch checked the version
string against a fixed set of options, which is easier to read
and simpler to adjust in the future.
(cherry picked from commit 83cc297561a78ad13fcd1c2943f17ace81c725b8)
Ubuntu ships the llvm bindings in /usr/lib/ocaml/llvm/ but Fedora
is installing them directly in /usr/lib/ocaml so we need to check
there as well.
The patch is untested; Fedora 14, the current beta, includes llvm 2.7.
It does add an unnecessary -I directive, but should at least have a
better chance of working on Fedora 15.
(cherry picked from commit 8af7360bd3de851668a133ae6ba4419e3722c6aa)
The LLVM project recently released version 2.8, and updated
the SVN tree version to 2.9svn, obsoleting the simple check
for 'llvm-config --version' returning 2.8svn.
With this commit we instead check for the substrings 2.8 and 2.9
in the output of 'llvm-config --version', since we (currently)
support both the svn and released varieties of those versions.
A stable release also complicates our check for the ocaml bindings.
Previously we looked in `llvm-config --libdir`/ocaml which is
appropriate for local compiles, but distribution packagers are
likely to put the bindings in the default search path, e.g.
/usr/lib/ocaml/llvm. We now fall back to trying variations on
the standard library path returned by 'ocamlc -config' if we
don't find it under 'llvm-config --libdir'.
With this change, rust builds against LLVM 2.8 as packaged
in Ubuntu 10.10 as well as LLVM 2.9svn compiled locally.
(cherry picked from commit b606b65756f087c403180abd5418fe7dce469758)