Bug 2429697

Summary: F44FailsToInstall: libreoffice-core
Product: [Fedora] Fedora Reporter: Fedora Fails To Install <fti-bugs>
Component: libreofficeAssignee: Jonathan Wakely <jwakely>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dtardon, erack, gwync, jwakely, libreoffice-sig, sberg.fun
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libreoffice-26.2.0.1-0.6.fc44 Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2026-01-15 17:05:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2384425, 2429148    

Description Fedora Fails To Install 2026-01-14 19:08:36 UTC 
Hello,

Please note that this comment was generated automatically by https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py
If you feel that this output has mistakes, please open an issue at https://pagure.io/releng/

Your package (libreoffice) Fails To Install in Fedora 44:

can't install libreoffice-core:
  - nothing provides libboost_locale.so.1.83.0()(64bit) needed by libreoffice-core-1:26.2.0.1-0.1.fc44.x86_64
  
If you know about this problem and are planning on fixing it, please acknowledge so by setting the bug status to ASSIGNED. If you don't have time to maintain this package, consider orphaning it, so maintainers of dependent packages realize the problem.


If you don't react accordingly to the policy for FTBFS/FTI bugs (https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/), your package may be orphaned in 8+ weeks.


P.S. The data was generated solely from koji buildroot, so it might be newer than the latest compose or the content on mirrors. To reproduce, use the koji/local repo only, e.g. in mock:

    $ mock -r fedora-44-x86_64 --config-opts mirrored=False install libreoffice-core


P.P.S. If this bug has been reported in the middle of upgrading multiple dependent packages, please consider using side tags: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages

Thanks!
Comment 1 Jonathan Wakely 2026-01-15 04:27:52 UTC 
As well as fixing some code:
https://gerrit.libreoffice.org/c/core/+/197303

I had to disable some failing tests:

# fails with 26.2.0.1 with gcc-16.0.1-2
# Test name: test::ostring::StringLiterals::checkOstr
# equality assertion failed
# - Expected:
# - Actual  : x� ���
sed -i -e '/"_tstr/d' sal/qa/rtl/strings/test_ostring_stringliterals.cxx

That removes these three lines:

    CPPUNIT_ASSERT_EQUAL(""_ostr, rtl::OString(""_tstr));
    CPPUNIT_ASSERT_EQUAL("foobar"_ostr, rtl::OString("foobar"_tstr));
    CPPUNIT_ASSERT_EQUAL("foo\0bar"_ostr, rtl::OString("foo\0bar"_tstr));

I see some warnings during the build which look highly relevant to that code:

In file included from /builddir/build/BUILD/libreoffice-26.2.0.1-build/libreoffice-26.2.0.1/sal/qa/rtl/strings/test_ostring_stringliterals.cxx:17:
/builddir/build/BUILD/libreoffice-26.2.0.1-build/libreoffice-26.2.0.1/include/rtl/string.hxx: In member function ‘rtlunittest::OString::OString<rtlunittest::OStringLiteral<7ul>{rtlunittest::OStringLiteral<7ul>::{unnamed type#1}{.more=rtlunittest::OStringLiteral<7ul>::Data{1073741824, 6, char [7]{(char)102, (char)111, (char)111, (char)98, (char)97, (char)114}}}}>(rtlunittest::detail::OStringHolder<rtlunittest::OStringLiteral<7ul>{rtlunittest::OStringLiteral<7ul>::{unnamed type#1}{.more=rtlunittest::OStringLiteral<7ul>::Data{1073741824, 6, char [7]{(char)102, (char)111, (char)111, (char)98, (char)97, (char)114}}}}> const&)’:
/builddir/build/BUILD/libreoffice-26.2.0.1-build/libreoffice-26.2.0.1/include/rtl/string.hxx:401:9: warning: storing the address of local variable ‘<anonymous>’ in ‘this_5(D)->pData’ [-Wdangling-pointer=]
  401 |         pData(const_cast<rtl_String *>(&holder.literal.str)) {}
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/builddir/build/BUILD/libreoffice-26.2.0.1-build/libreoffice-26.2.0.1/include/rtl/string.hxx:401:63: note: ‘<anonymous>’ declared here
  401 |         pData(const_cast<rtl_String *>(&holder.literal.str)) {}
      |                                                               ^
/builddir/build/BUILD/libreoffice-26.2.0.1-build/libreoffice-26.2.0.1/include/rtl/string.hxx:400:89: note: ‘this’ declared here
  400 |     template<OStringLiteral L> constexpr OString(detail::OStringHolder<L> const & holder):
      |                                                                                         ^
/builddir/build/BUILD/libreoffice-26.2.0.1-build/libreoffice-26.2.0.1/include/rtl/string.hxx: In member function ‘rtlunittest::OString::OString<rtlunittest::OStringLiteral<8ul>{rtlunittest::OStringLiteral<8ul>::{unnamed type#1}{.more=rtlunittest::OStringLiteral<8ul>::Data{1073741824, 7, char [8]{(char)102, (char)111, (char)111, (char)0, (char)98, (char)97, (char)114}}}}>(rtlunittest::detail::OStringHolder<rtlunittest::OStringLiteral<8ul>{rtlunittest::OStringLiteral<8ul>::{unnamed type#1}{.more=rtlunittest::OStringLiteral<8ul>::Data{1073741824, 7, char [8]{(char)102, (char)111, (char)111, (char)0, (char)98, (char)97, (char)114}}}}> const&)’:
/builddir/build/BUILD/libreoffice-26.2.0.1-build/libreoffice-26.2.0.1/include/rtl/string.hxx:401:9: warning: storing the address of local variable ‘<anonymous>’ in ‘this_5(D)->pData’ [-Wdangling-pointer=]
  401 |         pData(const_cast<rtl_String *>(&holder.literal.str)) {}
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/builddir/build/BUILD/libreoffice-26.2.0.1-build/libreoffice-26.2.0.1/include/rtl/string.hxx:401:63: note: ‘<anonymous>’ declared here
  401 |         pData(const_cast<rtl_String *>(&holder.literal.str)) {}
      |                                                               ^
/builddir/build/BUILD/libreoffice-26.2.0.1-build/libreoffice-26.2.0.1/include/rtl/string.hxx:400:89: note: ‘this’ declared here
  400 |     template<OStringLiteral L> constexpr OString(detail::OStringHolder<L> const & holder):
      |                                                                                         ^


So GCC thinks there's a dangling pointer there, which would explain the garbage characters in the assertion output.
Comment 2 Jonathan Wakely 2026-01-15 08:17:14 UTC 
https://bodhi.fedoraproject.org/updates/FEDORA-2026-36a010a4b0
Comment 3 Gwyn Ciesla 2026-01-15 16:28:34 UTC 
Thank you!
Comment 4 Jonathan Wakely 2026-01-15 17:05:43 UTC 
https://bodhi.fedoraproject.org/updates/FEDORA-2026-36a010a4b0
Comment 5 Stephan Bergmann 2026-01-19 09:24:14 UTC 
(In reply to Jonathan Wakely from comment #1)
> So GCC thinks there's a dangling pointer there, which would explain the
> garbage characters in the assertion output.

(I've seen this too starting with my recent LO master builds against recent GCC trunk a while ago.  On a first look, it looks to me as if GCC started to mis-compile uses of
```
template<OStringLiteral L> struct OStringHolder {
    static constexpr auto & literal = L;
};
```
(from `include/rtl/string.hxx`), but I haven't stripped it down and analyzed it further yet.)
Comment 6 Stephan Bergmann 2026-01-21 09:52:53 UTC 
(In reply to Stephan Bergmann from comment #5)
> (I've seen this too starting with my recent LO master builds against recent
> GCC trunk a while ago.  On a first look, it looks to me as if GCC started to
> mis-compile uses of
> ```
> template<OStringLiteral L> struct OStringHolder {
>     static constexpr auto & literal = L;
> };
> ```
> (from `include/rtl/string.hxx`), but I haven't stripped it down and analyzed
> it further yet.)

(now being tracked at <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123738> "[16 Regression] "is not a constant expression" in code using a string literal operator template since r16-6431")