Bug 2259590

Summary:	F40FailsToInstall: slic3r
Product:	[Fedora] Fedora	Reporter:	Fedora Fails To Install <fti-bugs>
Component:	slic3r	Assignee:	Miro Hrončok <mhroncok>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	jwakely, mhroncok, perl-devel
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	slic3r-1.3.0-32.fc40	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2024-01-22 13:54:06 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:	2259542
Bug Blocks:	2231790, 2258089

Description Fedora Fails To Install 2024-01-22 10:50:48 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 (slic3r) Fails To Install in Fedora 40:

can't install slic3r:
  - nothing provides libboost_filesystem.so.1.81.0()(64bit) needed by slic3r-1.3.0-31.fc39.x86_64
  - nothing provides libboost_thread.so.1.81.0()(64bit) needed by slic3r-1.3.0-31.fc39.x86_64
  - nothing provides libboost_nowide.so.1.81.0()(64bit) needed by slic3r-1.3.0-31.fc39.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-40-x86_64 --config-opts mirrored=False install slic3r


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 2024-01-22 12:24:32 UTC

This wasn't rebuilt for the new boost because the package FTBFS with gcc-14:

/usr/include/c++/14/x86_64-redhat-linux/bits/c++config.h:2509:2: warning: #warning "__STRICT_ANSI__ seems to have been undefined; this is not supported" [-Wcpp]
 2509 | #warning "__STRICT_ANSI__ seems to have been undefined; this is not supported"
      |  ^~~~~~~
In file included from /usr/include/c++/14/bits/chrono.h:39,
                 from /usr/include/c++/14/mutex:43,
                 from /usr/include/boost/system/detail/mutex.hpp:68,
                 from /usr/include/boost/system/detail/error_category_impl.hpp:101,
                 from /usr/include/boost/system/errc.hpp:17,
                 from /usr/include/boost/system/system_error.hpp:9,
                 from /usr/include/boost/thread/exceptions.hpp:22,
                 from /usr/include/boost/thread/pthread/thread_data.hpp:10,
                 from /usr/include/boost/thread/thread_only.hpp:17,
                 from /usr/include/boost/thread/thread.hpp:12,
                 from /usr/include/boost/thread.hpp:13,
                 from src/libslic3r/libslic3r.h:11:
/usr/include/c++/14/limits:2100:30: error: exponent has no digits
 2100 |         return __extension__ 0x1.0p-16382Q;
      |                              ^~~~~~


The warning says what the problem is, and indeed the build.log shows that the package uses -U__STRICT_ANSI__ '-std=c++11' 

DO. NOT. DO. THIS.

__STRICT_ANSI__ is an internal macro defined and used by the compiler, it is NOT a macro that users can define/undefined in their own code. Doing so completely breaks the C++ standard library headers.

If you want non-strict C++11 then just use -std=gnu++11 instead of -std=c++11

Asking the compiler to be strict then undefining the macro that says it's being strict is just wrong. Please get this fixed upstream.

Comment 2 Jonathan Wakely 2024-01-22 12:31:07 UTC

(In reply to Jonathan Wakely from comment #1)
> Asking the compiler to be strict then undefining the macro that says it's
> being strict is just wrong. Please get this fixed upstream.

Should have been fixed upstream 3 years ago:
https://github.com/slic3r/Slic3r/pull/4996/commits/dae33e5a9157b8f13e7f8271eae3a9d740492853

Comment 3 Miro Hrončok 2024-01-22 13:54:06 UTC

Yes it was and I backported that, see bz2259542.