Bug 2239047 - Firefox build fails with clang 17 due to change in output of clang++ -print-search-dirs
Summary: Firefox build fails with clang 17 due to change in output of clang++ -print-s...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: 39
Hardware: Unspecified
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Gecko Maintainer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 2238728 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-09-14 23:58 UTC by Adam Williamson
Modified: 2023-09-20 13:45 UTC (History)
6 users (show)

Fixed In Version: firefox-117.0.1-2.fc40 firefox-117.0.1-2.fc39
Clone Of:
Environment:
Last Closed: 2023-09-17 00:15:19 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Adam Williamson 2023-09-14 23:58:04 UTC
Firefox build fails on F39 and Rawhide at the moment. I believe this is due to https://bugzilla.redhat.com/show_bug.cgi?id=2239046 . Firefox's build/moz.configure/bindgen.configure tries to figure out where libclang will be by running `clang++ -print-search-dirs` then parsing the output (in the `bindgen_libclang_path` function). I wrote a script with the essence of that function to tell us what the 'candidate' dirs it decides on are, for the clang 16 output vs the clang 17 output, and this was the result:

16 candidates: /usr/lib64
17 candidates: /usr/bin/../lib

so with clang 16 it looks for libclang in /usr/lib64 (and finds it), but with clang 17 it looks for libclang in /usr/lib (and does not find it). This is all tested on x86_64 but it's probably the same on all 64-bit arches.

I'm currently testing whether this avoids the problem:

# https://bugzilla.redhat.com/show_bug.cgi?id=2239046
# with clang 17 upstream's detection fails, so let's just tell it
# where to look
echo "ac_add_options --with-clang-path=%{_libdir}" >> .mozconfig

Reproducible: Always

Comment 1 Adam Williamson 2023-09-15 00:05:58 UTC
On a quick test it looks like that *does* avoid the problem, so I'm trying official builds for F39 and Rawhide now. Fingers crossed.

Comment 2 Adam Williamson 2023-09-15 01:11:27 UTC
er, well, it works if you do --with-libclang-path , not --with-clang-path ! builds are running.

Comment 3 Fedora Update System 2023-09-15 03:14:46 UTC
FEDORA-2023-16d55c9e85 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-16d55c9e85

Comment 4 Fedora Update System 2023-09-15 04:13:37 UTC
FEDORA-2023-16d55c9e85 has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 5 Fedora Update System 2023-09-15 05:24:34 UTC
FEDORA-2023-6bdc468df7 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-6bdc468df7

Comment 6 Fedora Update System 2023-09-16 01:47:58 UTC
FEDORA-2023-6bdc468df7 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-6bdc468df7`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-6bdc468df7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 7 Fedora Update System 2023-09-17 00:15:19 UTC
FEDORA-2023-6bdc468df7 has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 8 Tulio Magno Quites Machado Filho 2023-09-20 13:45:03 UTC
*** Bug 2238728 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.