Open Bug 1413234 Opened 2 years ago Updated 3 months ago
libclang not detected with toolkit/moz
.configure on linux
On Linux openSUSE Leap 42.2 building Firefox (57.0b9) fails, because "./mach build" doesn't accept the installed /usr/lib64/libclang.so.3.9 This version is needed, because the default libclang isn't new enough to build firefox with stylo. In toolkit/moz.configure only libclang.so.1 is listed. https://dxr.mozilla.org/mozilla-central/source/toolkit/moz.configure#709 Adding "libclang_choices.append('libclang.so.3.9')" seems to fix the build failure for me. A better solution might be the OpenBSD definition of libclang_choices. https://dxr.mozilla.org/mozilla-central/source/toolkit/moz.configure#712 Or a way to specify --with-libclang-path="/usr/lib64/libclang.so.3.9". Currently "--with-libclang-path" only accepts directories. Today on irc in #build I was encouraged to file a bug, because "it looks like the linux logic should indeed be mirroring the openbsd logic" with a reference to https://dxr.mozilla.org/mozilla-central/source/third_party/rust/clang-sys/build.rs#241
The openbsd logic is there because openbsd always adds a number to their .so files, and they can have different values. But either way, --with-libclang-path is not really expected to work with /usr/lib64 as a path. Doesn't suse provide a symbolic link in some llvm directory? For instance, on Debian, the libclang1-3.9 package provides /usr/lib/x86_64-linux-gnu/libclang-3.9.so.1, /usr/lib/llvm-3.9/lib/libclang-3.9.so.1 and /usr/lib/llvm-3.9/lib/libclang.so.1.
(In reply to Mike Hommey [:glandium] from comment #1) > The openbsd logic is there because openbsd always adds a number to their .so > files, and they can have different values. Apparently some Linux distributions do too. =/ Regardless, the configure check is just to make sure that clang-sys will find the appropriate files, so we should make the configure check conform to what clang-sys expects to see. > But either way, --with-libclang-path is not really expected to work with > /usr/lib64 as a path. Doesn't suse provide a symbolic link in some llvm > directory? For instance, on Debian, the libclang1-3.9 package provides > /usr/lib/x86_64-linux-gnu/libclang-3.9.so.1, > /usr/lib/llvm-3.9/lib/libclang-3.9.so.1 and > /usr/lib/llvm-3.9/lib/libclang.so.1. I don't know why --with-libclang-path wouldn't be expected to work. But I don't know the answer to whether symbolic links are provided or not; needinfo'ing the reporter to provide some information there.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
(In reply to Nathan Froyd [:froydnj] from comment #2) [...] > But I > don't know the answer to whether symbolic links are provided or not; > needinfo'ing the reporter to provide some information there. I'm no expert in these topics - please don't rely on my answer. At least in this version of my distro the default libclang package is at version 3.8.0. With the command (For debian users: zypper is used to install packages in openSUSE) zypper if --provides libclang | grep libclang.so this is printed: libclang.so.3.8()(64bit) To use newer versions of libclang the user has to add an additional repository, for example devel:/tools:/compiler This repo offers as libclang: libclang3_8 libclang3_9 libclang4 libclang5 The libclang version of libclang3_8 is 3.8.1 The libclang version of libclang3_9 is 3.9.1 The libclang version of libclang4 is 4.0.1 The libclang version of libclang5 is 5.0.0 These packages provide in the previous order according to zypper: libclang.so.3.8()(64bit) libclang.so.3.9()(64bit) libclang.so.4()(64bit) libclang.so.5()(64bit) and libclang.so.5(LLVM_5.0)(64bit) After installing the libclang3_9 package, the command rpm -q -l libclang3_9 creates the first part of the attached output (libclang3_9-files). The only libclang.so file under /usr/lib or /usr/lib64 is /usr/lib64/libclang.so.3.9 I couldn't find any link to this library and especially no libclang.so.1 The files libclang[something].so.3.9 in the attached output are links to their libclang[something].so.3.9.1 counter part. But there is only one (real) libclang.so.3.9 No libclang.so.3.9.1, no libclang.so.3, no libclang.so.1, no libclang-3.9.so.1 There is no directory starting with llvm under /usr/lib or /usr/lib64. The output of rpm -q --provides libclang3_9 creates the second part of the attached output (libclang3_9-provides). If there is a packaging failure involved, i might try to contact the openSUSE package maintainer. But as a similar logic seems to be accepted for OpenBSD, i'm not sure if it is obviously the distibuters task to follow the Debian way. I hope this helps and want to thank everyone involved.
I'm not sure if, by whom and when the needinfo flag has to be cleared. Please ask, if anything is missing from my side. Another observation in the described environment, that is building with ac_add_options --with-libclang-path="/usr/lib64/" ac_add_options --with-clang-path="/usr/bin/clang-3.9.1" and as described "libclang_choices.append('libclang.so.3.9')" added to https://dxr.mozilla.org/mozilla-central/source/toolkit/moz.configure#709 might be known: If libclang5 (and libLLVM5) are installed in parallel to libclang3_9, the build process fails somewhere in the stylo compiling process. It works for libclang3_9 without other versions locally available.
You need to log in before you can comment on or make changes to this bug.