Bug 2238728

This might have another root cause.
This is what I'm getting:

$ podman run -it --rm fedora:rawhide bash
# dnf install -y clang-devel
...
# ll /usr/lib64/libclang.so
lrwxrwxrwx. 1 root root 14 Aug 23 00:00 /usr/lib64/libclang.so -> libclang.so.17
# rpm -q clang-devel
clang-devel-17.0.0~rc3-1.fc40.x86_64

Looking at the last rust build on rawhide, it used clang-libs-16.0.6-3.fc39.
I expected that building with rust would be using clang16-libs instead.

rust-1.72.0-1.fc40.x86_64 does require libLLVM-16.so()(64bit), but I don't see which package is providing this in these Firefox builds.
How can this happen?

(In reply to Tulio Magno Quites Machado Filho from comment #1)
> rust-1.72.0-1.fc40.x86_64 does require libLLVM-16.so()(64bit), but I don't
> see which package is providing this in these Firefox builds.
> How can this happen?

One should not confuse libclang with libLLVM. :o)

Is this being caused by mixing clang 17 with a rust built with clang 16?

Can it be caused by latest clang-17.0.0 updates? Because previous Firefox 117.0 build from 2023-08-30 are okay.

I managed to get how Firefox is looking for libclang:

INFO: checking for libclang for bindgen... 
DEBUG: Executing: `/usr/bin/clang++ -print-search-dirs`
DEBUG: Trying "libclang.so" in "/usr/bin/../lib"
DEBUG: Trying "libclang.so.*" in "/usr/bin/../lib"
INFO: not found
ERROR: Could not find libclang to generate rust bindings for C/C++. Please install the necessary packages, run `mach bootstrap`, or use --with-libclang-path to give the path containing it.

Which means it's aborting without checking all the paths because the output is:

# /usr/bin/clang++ -print-search-dirs
programs: =/usr/bin:/usr/bin/../lib/gcc/x86_64-redhat-linux/13/../../../../x86_64-redhat-linux/bin
libraries: =/usr/bin/../lib/clang/17:/usr/bin/../lib/gcc/x86_64-redhat-linux/13:/usr/bin/../lib/gcc/x86_64-redhat-linux/13/../../../../lib64:/lib/../lib64:/usr/lib/../lib64:/lib:/usr/lib

The Rust build only uses clang to compile its bundled wasi-libc. That shouldn't have any effect on Rust dependents.

It could be a problem if a proc-macro mixed clang-17 with rust+llvm16, since they would be loaded in the same process, but it seems your build problems are happening well before anything like that.

I tried local build in VM Fedora 39 and /usr/bin/clang++ doesn't start but throws:

/lib64/libclang-cpp.so.17: undefined symbol llvm::opt::ArgList::hasFlagNoClaim(llvm::opt::OptSpecifier,...)

So it fails at 'checking for clang for bindgen... /usr/bin/clang++' stage.
But /usr/lib64/libclang.so symlink is present.

Okay, updated F39 and clang++ issue looks solved. But Firefox still fails to pick up libclang.

(In reply to Tulio Magno Quites Machado Filho from comment #4)
> I managed to get how Firefox is looking for libclang:
> 
> INFO: checking for libclang for bindgen... 
> DEBUG: Executing: `/usr/bin/clang++ -print-search-dirs`
> DEBUG: Trying "libclang.so" in "/usr/bin/../lib"
> DEBUG: Trying "libclang.so.*" in "/usr/bin/../lib"
> INFO: not found
> ERROR: Could not find libclang to generate rust bindings for C/C++. Please
> install the necessary packages, run `mach bootstrap`, or use
> --with-libclang-path to give the path containing it.
> 
> Which means it's aborting without checking all the paths because the output
> is:
> 
> # /usr/bin/clang++ -print-search-dirs
> programs:
> =/usr/bin:/usr/bin/../lib/gcc/x86_64-redhat-linux/13/../../../../x86_64-
> redhat-linux/bin
> libraries:
> =/usr/bin/../lib/clang/17:/usr/bin/../lib/gcc/x86_64-redhat-linux/13:/usr/
> bin/../lib/gcc/x86_64-redhat-linux/13/../../../../lib64:/lib/../lib64:/usr/
> lib/../lib64:/lib:/usr/lib

I don't see '/usr/bin/../lib' path in the '/usr/bin/clang++ -print-search-dirs' output at all which means Firefox gets the library list from different source.

Tulio Magno Quites Machado Filho how did you manage to get the DEBUG output from Firefox build?
Thanks.

(In reply to Martin Stransky from comment #9)
> Tulio Magno Quites Machado Filho how did you manage to get the DEBUG output
> from Firefox build?

First I tried to build it using mock, i.e.:

$ mock -r fedora-rawhide-x86_64 --rebuild firefox-117.0.1-1.fc40.src.rpm

Then I found the following log: /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/firefox-117.0.1/objdir/instrumented/config.log

I think this is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=2239047

See my response in https://bugzilla.redhat.com/show_bug.cgi?id=2239046#c2.

*** This bug has been marked as a duplicate of bug 2239047 ***

Aha - I didn't realize you were all struggling down the same furrow over here when I fixed it :) I did look for existing bug reports before I started digging, but I was looking for *firefox* bugs not *clang* bugs. D'oh.

Anyhow, you were most of the way there - the problem *was* the output of `/usr/bin/clang++ -print-search-dirs` changing. `bindgen.configure` does some parsing on the output to generate its list of candidates, which is why the debug output doesn't exactly match the clang++ output. It parses `/usr/bin/../lib/clang/17` into `/usr/bin/../lib` and tries that; the other items in the output all get discarded because they don't match what it's looking for (it looks for items ending in clang/(anumber) and strips those elements out, basically).

The practical way to fix this was just to bypass all this stuff and pass --with-libclang-path=%{_libdir} and *tell* the build process where to find the library. Per the clang devs, all this detection logic is wrong anyway.