(In reply to comment #1)
> Full build log here:
> https://launchpadlibrarian.net/129750443/buildlog_ubuntu-quantal-i386.mesa_9.
> 1~git1301281053.87592c~gd~q_FAILEDTOBUILD.txt.gz
> 
> Note that the two libraries are missing, but
> /usr/lib/llvm-3.2/lib/libLLVM-3.2.so.1 is available.

A libLLVM-3.2.so symlink is needed at build time. The Ubuntu/Debian llvm-3.2-dev package has one at /usr/lib/*-linux-gnu/libLLVM-3.2.so but not at /usr/lib/llvm-3.2/lib/libLLVM-3.2.so. Maybe Mesa's configure should try actually linking -lLLVM-3.2 or -lLLVMTarget instead of looking for the files.

Whoops, resolved accidentally.

(In reply to comment #1)
> (In reply to comment #1)
> > Full build log here:
> > https://launchpadlibrarian.net/129750443/buildlog_ubuntu-quantal-i386.mesa_9.
> > 1~git1301281053.87592c~gd~q_FAILEDTOBUILD.txt.gz
> > 
> > Note that the two libraries are missing, but
> > /usr/lib/llvm-3.2/lib/libLLVM-3.2.so.1 is available.
> 
> A libLLVM-3.2.so symlink is needed at build time. The Ubuntu/Debian
> llvm-3.2-dev package has one at /usr/lib/*-linux-gnu/libLLVM-3.2.so but not
> at /usr/lib/llvm-3.2/lib/libLLVM-3.2.so. Maybe Mesa's configure should try
> actually linking -lLLVM-3.2 or -lLLVMTarget instead of looking for the files.

This seems like a good idea, but I am not sure how to implement it.  There are AC_CHECK_LIB and AC_SEARCH_LIBS macros, but there doesn't seem to be a way to pass extra library paths to it, so I think this would fail if the shared objects were not in one of the paths in LD_LIBRARY_PATH.

(In reply to comment #3)
> There are AC_CHECK_LIB and AC_SEARCH_LIBS macros, but there doesn't seem to be
> a way to pass extra library paths to it, so I think this would fail if the
> shared objects were not in one of the paths in LD_LIBRARY_PATH.

That should be fine, /usr/lib/*-linux-gnu/ is in the default linker search path.

http://www.gnu.org/software/autoconf-archive/ax_ext_have_lib.html looks  like a potential solution.

LLVM_CONFIG="/usr/bin/llvm-config-3.2" ./configure $SWITCHES
is your friend.

Mesa's build system supports and should only support officially supported builds of upstream projects - LLVM's cmake and auto* build systems do not have a switch to add a "-3.2" suffix to llvm-config.
Sorry, but we cannot support billions of (user-modified) cases by modifing build system each time - It is hard enough to support official builds.

If people or in this bad case even distributions think they must modify and mess up things it is their own problem and they should read and understand configure to find a simple solution:
"  ac_cv_path_LLVM_CONFIG="$LLVM_CONFIG" # Let the user override the test with a path
[...]
LLVM_CONFIG=$ac_cv_path_LLVM_CONFIG"

Johannes, I totally fail to see how your rant explains this problem at all.

That said, creating the libLLVM*.so symlinks in /usr/lib/llvm-3.2/lib/ as well in the downstream LLVM packages might not be the worst way to resolve this problem. Fabio, maybe you can prod the downstream LLVM maintainer(s) to that effect.

I still think Mesa configure should test what we actually want to do — link a certain shared library — rather than if a certain file is in a certain directory.

(In reply to comment #7)
> Johannes, I totally fail to see how your rant explains this problem at all.

Michel, thanks to making me thinking on this issue a second time.

First I thought it was an error because llvm-config was not found ...

But it does not matter for question whether it is Mesa's problem:

We can either make configure to find libs with an own compile/link function and shoot possibility to try whether it is a shared lib because 
"$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS $LLVM_LDFLAGS conftest.$ac_ext -l$LIB"
succeeds on shared and static libs and we do not know which and where $LIB was found (LLVM_LDFLAGS or compiler's default search path) to try whether it is shared

or

we let current implementation and fail if it doesn't work on stupid systems and preserve runtime functionality.

Because I want to preserve runtime functionality I am voting for:
RESOLVED / NOTOURBUG

Would it be possible to update mesa to accept llvm config and llvm library locations as switches rather than it being an environmental variable?

Note that I am getting the same error when changing configure.ac to use llvm-config-3.2, when configuring with --with-llvm-prefix=/usr/lib/llvm-3.2 or when using ac_cv_path_LLVM_CONFIG=llvm-config-3.2 , all worked before.

Some time ago I filed a bug in debian requesting a un-suffixed llvm-config to be always available:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697497

I suggest to remove this configure check since it prevents building on an otherwise working setup. Better risking of failing during make rather than during configure if the make would then succeed.

Closing it because arbitrary changing of library names downstream (libLLVM-$VERSION.so to libLLVM-$VERSION.so.1) without creating a symlink in right place (e. g. /usr/lib/llvm-$VERSION/lib/libLLVM-$VERSION.so in case of Ubuntu/Debian) is not task of Mesa build system to handle (esp. if path to libLLVM-$VERSION.so cannot be determinated easily - comment #9).

Also other developers have not contradicted for a week and it is better to "[...] preserve runtime functionality" instead of making it compiling.

But you can patch it downstream:
-AC_CHECK_FILE("$LLVM_LIBDIR/lib$LLVM_SO_NAME.so", llvm_have_one_so=yes,)
+AC_CHECK_FILE("$ARBITRARY_LLVM_LIBDIR/lib$LLVM_SO_NAME.so", llvm_have_one_so=yes,)

(In reply to comment #12)
> I suggest to remove this configure check since it prevents building on an
> otherwise working setup. Better risking of failing during make rather than
> during configure if the make would then succeed.

There are actually two reason for that check.  The first is to determine which build system (auto* or CMake was used to build LLVM).  This is necessary, because with auto* LLVM builds a single shared library and with CMake it builds one shared library for each component, so we need to figure out which linker flags to use.

The second reason is to prevent users from getting confused when they have linker errors resulting from missing shared libraries.

I agree with Michel, that it would be better to try to link to libraries rather than just test that the files exist.  However, I spent some time investigating the ax_ext_have_lib solution proposed by Matt, and I don't think it will work for us, because it automatically adds the library to $(LIBS) and the path to $(LDFLAGS), which I'm not sure is what we want.  Also, there is no way to specify an action to perform if the libraries are found, which we need in order to add the libraries to LLVM_LIBS.

Until someone can come up with a good solution for checking for libraries via linking, my preference is to keep the check as is.  I think it is more important to give users a useful error when something fails than it is to support customized distro installed.  Distro maintainers usually have the knowledge to work around these issues, while some users may not.