Bug 857201 – media-video/pipewire-0.3.54-r1: fails to build with -Ofast (fcntl2.h:41:1: error: inlining failed in call to ‘always_inline’ ‘open.localalias’: function not inlinable)

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Karl Ernst Brunk 2022-07-09 20:58:56 UTC]

Should be added to Bug 839906 gcc-12 tracker.
All compilitions i tried with different USE-Flags of pipewire and gcc failing with "function not inliable".
There is no problem doing it with gcc-11.3.0 .

Reproducible: Always

Steps to Reproduce:
1.Emerge pipewire
2.
3.
Actual Results:  
failed compilition. See build.log made with MAKEOPTS=-j1"

Expected Results:  
Compiles fine and merges build

I found some hints on internet that it might depend on c++ code.
So even f it is something completely different i compiled gcc with objc++. Did not change anything.

[Comment 1 Karl Ernst Brunk 2022-07-09 21:01:51 UTC]

Created attachment 790802 [details]
Build.log

[Comment 2 Karl Ernst Brunk 2022-07-09 21:02:25 UTC]

Created attachment 790805 [details]
Environment

[Comment 3 Karl Ernst Brunk 2022-07-09 21:03:18 UTC]

Created attachment 790808 [details]
meson.ini

[Comment 4 Sam James 2022-07-10 06:32:41 UTC]

(FWIW, PW is written in C, not C++, and objc++ is something very different.)

[Comment 5 Sam James 2022-07-10 06:33:05 UTC]

Please also include emerge --info. I'm not convinced this is GCC 12 specific but I'll add the blocker.

[Comment 6 Karl Ernst Brunk 2022-07-10 10:06:15 UTC]

Created attachment 790823 [details]
emerge-info

[Comment 7 Karl Ernst Brunk 2022-07-10 10:12:03 UTC]

Hi Sam,
as i did mention, i myself did doubt about objc++, BUT sometimes there are strange things happening;))
I added USE-Flags for gcc as well because the are the same for 11.3 and as also mentioned 11.3 does the Job.
cheers
Karl

[Comment 8 Karl Ernst Brunk 2022-07-10 10:12:24 UTC]

Created attachment 790826 [details]
gcc use flags

[Comment 9 Sam James 2022-07-10 10:50:15 UTC]

(In reply to Karl Ernst Brunk from comment #7)
> Hi Sam,
> as i did mention, i myself did doubt about objc++, BUT sometimes there are
> strange things happening;))
> I added USE-Flags for gcc as well because the are the same for 11.3 and as
> also mentioned 11.3 does the Job.
> cheers
> Karl

Aye, no worries, I think a bit of speculation/musing like that is helpful, as it gives ideas if we're stuck!

Anyway, this is exposed by -Ofast. the always_inline is bogus.

[Comment 10 Karl Ernst Brunk 2022-07-10 11:47:44 UTC]

I am so sorry. My 930+x packages using gcc run smoothly with -Ofast
- despite of polkit and python
Both i have covered by package.env with O2-flag.
And because - till now with pipewire - there are no complains, i forgot completely that setting.
I should maybe change it back because i can't see any difference in speed or faster starting in normal use.
The general warning about using "strange" settings is quit right.
So compiling pipewire with -O2 with 12.1 is indeed working.
thanks for having patience
Karl

[Comment 11 Sam James 2022-07-10 11:55:36 UTC]

No problem at all. This is definitely a real bug upstream (I've reported it to them), but you can work around it by using -O2 or even -O3 it seems for this package. So I am glad you reported it :)

You can use https://wiki.gentoo.org/wiki//etc/portage/package.env / https://wiki.gentoo.org/wiki/Knowledge_Base:Overriding_environment_variables_per_package to set more safe CFLAGS for fragile packages if you want.

I'm going to work around it by adding -U_FORTIFY_SOURCE within the ebuild (do not do that yourself) for now as the existing logic seems brittle.

[Comment 12 Karl Ernst Brunk 2022-07-10 12:21:43 UTC]

I can commit that adding -U_FORTIFY_SOURCE=1 to CFLAGS is doing it with Ofast.
All hints i could find that direction just show -D_FORTIFY_SOURCE=1/2 - and thats not working.
So your advice not to set it myself is welcome. It is just nice to now that this is a possibility in advance when something like that arrives again before
reporting it.
nice last houres of a weekend
Karl

[Comment 13 Sam James 2022-07-10 13:43:28 UTC]

(In reply to Karl Ernst Brunk from comment #12)
> I can commit that adding -U_FORTIFY_SOURCE=1 to CFLAGS is doing it with
> Ofast.
> All hints i could find that direction just show -D_FORTIFY_SOURCE=1/2 - and
> thats not working.
> So your advice not to set it myself is welcome. It is just nice to now that
> this is a possibility in advance when something like that arrives again
> before
> reporting it.
> nice last houres of a weekend
> Karl

You too! Just to be clear: please don't disable FORTIFY_SOURCE at all with -U or anything. It's better to set -O3 for now or -O2 using package.env.

[Comment 14 Larry the Git Cow 2022-07-10 20:23:52 UTC]

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0de895e872b03a682e49c886807e247e1658f62f

commit 0de895e872b03a682e49c886807e247e1658f62f
Author:     Sam James <[e-mail]>
AuthorDate: 2022-07-10 20:22:49 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2022-07-10 20:23:45 +0000

    media-video/pipewire: fix build w/ -Ofast & FORTIFY_SOURCE
    
    Not strictly limited to -Ofast paired w/ >= FORTIFY_SOURCE=2, can
    happen with other optimisation levels, just that -Ofast encourages
    it to do the inlining which then blows up.
    
    Revbump b/c of the obvious possible runtime nature of the bug
    (given the patch may change behaviour).
    
    Closes: https://bugs.gentoo.org/857201
    Signed-off-by: Sam James <[e-mail]>

 .../files/pipewire-0.3.54-fortify-source.patch     |  33 ++
 media-video/pipewire/pipewire-0.3.54-r2.ebuild     | 422 +++++++++++++++++++++
 2 files changed, 455 insertions(+)

[Comment 15 Sam James 2022-07-10 20:25:01 UTC]

Thanks for reporting! For what it's worth, I seem to get a consistent test failure on test-spa when using -Ofast, so I would recommend avoiding it.

-O3, while still somewhat out there, should be less risky.