here is a patch for fixing the libdir suffix issue in llvm-config on CMake builds (if using -DLLVM_LIBDIR_SUFFIX=32/64).
It works successfully on my openSUSE i586 (/usr/lib/) and x86_64 (/usr/lib64/) systems.
Please CC me on further discussion.
0001-llvm-config-Support-LLVM_LIBDIR_SUFFIX-on-CMake-buil.patch (904 Bytes)
Rather than using sed, it would be better to change the .in to use @…@ variables to expand the libdir suffix along with the other variables expanded when going from llvm-config.in to llvm-config.
Another attempt didn't work (autoconf is broken then).
Also './configure --libdir=/usr/lib64' does not work because
my $LIBDIR = "$ABS_RUN_DIR/lib"
is hardcoded in tools/llvm-config/llvm-config.in.in
So at least one buildsystem (the one which is easier to understand) has been fixed
/start discussion [Sonntag, 24. April 2011] [02:01:12]
<jobermayr> Hi. Please push this patch: http://susepaste.org/28819300
<jobermayr> I tried it - it works
<nicholas> suse needs this for some reason? who sets LLVM_LIBDIR_SUFFIX, the user?
<jobermayr> Nope. It is set via cmake -DLLVM_LIBDIR_SUFFIX=64 (on x86_64)
<jobermayr> Also fedora needs it
<nicholas> i'm curious, what's the suffix here? is it /usr/lib-ia32 or something?
<jobermayr> Nope. /usr/lib on x86, /usr/lib64 on x86_64
<nicholas> ah ok, thanks.
<jobermayr> But it can also be /usr/lib on x86_64 if you install the additional 32-bit package ...
<impulze> lrwxrwxrwx 1 root root 5 Apr 3 18:21 /usr/lib -> lib64
<impulze> drwxr-xr-x 18 root root 36864 Apr 23 13:54 /usr/lib32
<impulze> drwxr-xr-x 95 root root 122880 Apr 23 14:03 /usr/lib64
<jobermayr> impulze: Is it fedora?
<impulze> just throwing my hat in
<impulze> in case someone wants to know another suffix combination
<nicholas> let me just make sure autoconf substitutes @LLVM_LIBDIR_SUFFIX@ with something sensible (like nothing) and then i'll commit it.
<chandlerc> jobermayr: why does that work for you?
<chandlerc> because you're manually setting it in CMake
<chandlerc> jobermayr: i think you'll have to teach autoconf to substitute that string as well
<jobermayr> Yes. It does not make sense if I install libs via -DLLVM_LIBDIR_SUFFIX=64 in /usr/lib64 (already supported) but llvm-config --libdir tells me /usr/lib ...
<nicholas> indeed, it breaks autoconf builds.
<nicholas> make: *** No rule to make target `/home/nicholas/llvm-commit/Debug+Asserts/lib@LLVM_LIBDIR_SUFFIX/libLLVMipo.a', needed by `/home/nicholas/llvm-commit/Debug+Asserts/bin/opt'. Stop.
<chandlerc> jobermayr: you need to update autoconf/configure.ac at the same time as you do this update; we need both cmake *and* autoconf to work
<chandlerc> nicholas: btw, i also checked and cmake does already track this variable, so it doesn't break cmake builds even when using normal commandlines
<nicholas> chandlerc: yep, i grep'd for it and found that.
<chandlerc> jobermayr: i think this is the wrong way to do this anyways. autoconf sets up libdir to already have the '64' suffix when needed afaict. cmake should do the same
* chandlerc goes back to the standard and implementing f-ing type traits...
<jobermayr> chandlerc: But .../lib is hardcoded ATM (my $LIBDIR = "$ABS_RUN_DIR/lib";). So the 64 suffix in autoconf does not change it ...
<chandlerc> then that's what should be fixed
<chandlerc> (the hard coding)
* chandlerc sighs
<chandlerc> our autoconf is busted too
<chandlerc> so, autoconf provides @LLVM_LIBDIR@
<chandlerc> which, after prefix adjustment, is what the above should be using (mapping prefix -> abs_run_dir)
<chandlerc> but the way autoconf provides @LLVM_LIBDIR@ is actually broken, and doesn't use the system set up by autoconf, instead baking its own incorrect one...
<chandlerc> jobermayr: how many yaks do you feel like shaving? ;]
<chandlerc> basicaly, if you can get your patch to use @LLVM_LIBDIR@, and still be correct w/ CMake, the autoconf fixes can probably wait
<jobermayr> I can also implement a sed "s:my \$LIBDIR = \"\$ABS_RUN_DIR/lib\";:my \$LIBDIR = \"\$ABS_RUN_DIR/lib$LIB_SUFFIX\";:g" in CMakeLists.txt.
<jobermayr> So at least the cmake will be fixed and autoconf runs, too ...
<chandlerc> jobermayr: no, CMake doesn't need to recognize this one sequence of text and change it. =[
* chandlerc sighs
/end discussion [Sonntag, 24. April 2011] [02:50:38]