On Fri, 15 May 2015 16:41:35 +0000 Daniel Sanders <daniel.sand...@imgtec.com> wrote: > Package: cmake > Version: 3.0.2-1 > Severity: important > > Dear Maintainer, > > I'm an LLVM developer attempting to recurse the compiler on Debian Jessie > (mips) using the big-endian N32 ABI and I've noticed a couple problems with > find_library(). > > I haven't tested this with Debian's clang package since clang-3.4 and > clang-3.5 > both have issues with big-endian N32 which have recently been fixed. Instead, > I'm using LLVM's upstream trunk. > $ # Get source > $ svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm.src > $ svn co http://llvm.org/svn/llvm-project/cfe/trunk clang.src > $ # Build clang with gcc > $ mkdir build.gcc.n32 > $ pushd build.gcc.n32 > $ CFLAGS='-mips64r2 -mabi=n32' CXXFLAGS='-mips64r2 -mabi=n32' \ > cmake ../llvm.src/ -GNinja -DCMAKE_BUILD_TYPE=Release \ > -DCMAKE_INSTALL_PREFIX=$PWD/../install.gcc.n32 > (There's a mistake here but it's not relevant to the bug. I've forgotten to > supply LLVM_EXTERNAL_CLANG_SOURCE_DIR to tell it where to find the clang > source). > > If you inspect CMakeCache.txt at this stage, you will find the following > variables for libraries that weren't found: > DL_LIBRARY_PATH:FILEPATH=DL_LIBRARY_PATH-NOTFOUND > PTHREAD_LIBRARY_PATH:FILEPATH=PTHREAD_LIBRARY_PATH-NOTFOUND > yet N32 versions of these libraries are installed at: > /lib32/libdl.so.2 and /usr/lib32/libdl.so > /lib32/libpthread.so and /usr/lib32/libpthread.so > So I was expecting it to find these. > I've poked around with a slightly modified cmake (it had debug output to print > the search paths) and found that it wasn't searching these paths. > Interestingly, it seems there is N32-related code in cmake but it depends on > the compiler defining __sgi. Modifying cmake to activate this code didn't > help much but the resulting search path seemed closer to being correct. > > You'll also find this variable: > LIBXML2_LIBRARIES:FILEPATH=/usr/lib/mips-linux-gnu/libxml2.so > which is an O32 library rather than an N32 library. > $ file /usr/lib/mips-linux-gnu/libxml2.so > /usr/lib/mips-linux-gnu/libxml2.so: symbolic link to libxml2.so.2.9.1 > $ file /usr/lib/mips-linux-gnu/libxml2.so.2.9.1 > /usr/lib/mips-linux-gnu/libxml2.so.2.9.1: ELF 32-bit MSB shared object, > MIPS, MIPS-II version 1 (SYSV), dynamically linked, > BuildID[sha1]=d287c8baff04ea7d0364e2508ebc19276828f3f0, stripped > I expected it to fail to find libxml2 because no N32-compiled version is > available. > > If you then build, it fails while linking: > $ ninja > FAILED: : && /usr/bin/c++ -mips64r2 -mabi=n32 -fPIC > -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings > -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long > -Wno-maybe-uninitialized -Wno-comment -std=c++11 -ffunction-sections > -fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing -O3 > -DNDEBUG -Wl,-allow-shlib-undefined -Wl,-O3 -Wl,--gc-sections > tools/clang/tools/c-index-test/CMakeFiles/c-index-test.dir/c-index-test.c.o > -o bin/c-index-test lib/libclang.so.3.7 /usr/lib/mips-linux-gnu/libxml2.so > -Wl,-rpath,"\$ORIGIN/../lib" && : > /usr/lib/mips-linux-gnu/libxml2.so: error adding symbols: File in wrong format > It has attempted to link the O32 libxml2.so with the otherwise N32 > c-index-test binaries.
Yes, this behavior is expected. In Debian there is a "Multiarch" + "Multi-C" (aka, the one is called multilib in Debian) For multiarch, we install libraries into /usr/lib/<triplet>, so we can install libraries for multi architectures. For Mulit-C, we have C libraries (only libc) into /usr/lib32 (N32) /usr/lib64 (N64). So if you try to use multi-C to build program on mips systems, you can only use libc, aka libxml doesn't exists here. We haven't N32 system yet, while we are working on N64(el) system. > > -- System Information: > Debian Release: 8.0 > APT prefers testing > APT policy: (500, 'testing')
