http://llvm.org/bugs/show_bug.cgi?id=14700

             Bug #: 14700
           Summary: llvm-config returns wrong pathes
           Product: tools
           Version: 3.2
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: llvm-config
        AssignedTo: [email protected]
        ReportedBy: [email protected]
                CC: [email protected]
    Classification: Unclassified


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 "[email protected]@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.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs

Reply via email to