llvm-config returns wrong pathes #15072
Description
| Bugzilla Link | 14700 |
| Resolution | DUPLICATE |
| Resolved on | Mar 10, 2013 09:04 |
| Version | 3.2 |
| OS | Linux |
| Reporter | LLVM Bugzilla Contributor |
Extended Description
we use non-standard directory structures for development binaries.
all other pathes are based on --prefix=/usr
we move the llvm-* executables from /usr/bin to /root/development (as your build system ignores the standard --bindir) so a normal user has no access to the development tools. works fine for every tool we tried so far (with --bindir and / or --sbindir) but not with llvm.
--prefix: "/root" instead of "/usr"
--libdir: "/root/lib" instead of "/usr/lib64"
--ldflags: "-L/root/lib -l..." instead of "-L/usr/lib64 -l..."
--libfiles: all prefixed with "/root/lib" instead of "/usr/lib64"
--bindir: "/root/bin" instead of "/root/develop"
--includedir: "/root/include" instead of "/usr/include"
--cpflags: "-I/root/include -D..." instead of "/usr/include -D..."
moving llvm-config to another path results in replacing the "/root" with the new path.
as far i can see, you just use the path where llvm-config is started as prefix and append standard-values like /include, /bin and even worse /lib on 64bit.
just adding /lib on a 64bit system might be ok somtimes, but as far as i know we are not alone with /lib64 (see bug 8324)
i hoped to have this issue fixed with 3.2.
we'd really like to be able to build the mesa drivers to support faster graphics, but luckily this is the only place where we need llvm. (btw: mesa has a hardcoded 3.1 dependency which can be fixed by a simple sed -e "s@3.1@3.2@g" but fails later with including DataTypes.h)
btw:
i guess llvm-config is static linked to some of the libs despite i say --disable-static as a configure option. same with llvm-tblgen and clang-tblgen - at least ldd does not show libLLVM-3.2svn.so and the executables are bigger than expected.
none of the clang utilties lists libclang.so with ldd, i assume static linking here too.
and last but not least:
the clang includes are partialy in subdirectories under /usr/includ/clang, but most are in /usr/lib/clang/3.2/include where they really don't belong.