F42 x86_64 trouble building FFmpeg from source

The Water Cooler
1

I am seeking help from both the FFmpeg community on reddit and the Fedora
community at discussion.fedoraproject.org as hopefully someone has seen this
issue before and knows what is up.

Broken FFmpeg Build

My attempt to build FFmpeg 8.1.1 on a Fedora 42 x86_64 system is failing, and I
have yet to figure out where the issue is. I also tried FFmpeg 7.1.4 and had the
same type of failure so I do not believe the issue is a bug in the current
FFmpeg code itself. I suspect it is a linker problem.

I am building it with RPM and I get the same error when attempting to build it
inside a mock build environment, eliminating the possibility that the build
error is caused by a package on my system that has had some part of it broken
after install.

The spec file and all mock build logs are at:

I will try to detail the issues here, I suspect I am not the only one who has
experienced this issue.

I am using /opt/altmedia as my install prefix. That works with many other
multimedia packages I have built.

The build error from the build.log file lines 3990–3999:

/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/15/../../../../lib64/Scrt1.o: in function `_start':
(.text+0x1b): undefined reference to `main'
collect2: error: ld returned 1 exit status
make: *** [ffbuild/library.mak:136: libavutil/libavutil.so.60] Error 1
make: *** Waiting for unfinished jobs....
STRIP	libavcodec/x86/vp9itxfm.o
error: Bad exit status from /var/tmp/rpm-tmp.GeKXYE (%build)
RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.GeKXYE (%build)
Child return code was: 1

The configure string (from line 73 of build.log, broken into multiline here):

./configure \
   --prefix=/opt/altmedia \
   --bindir=/opt/altmedia/bin \
   --datadir=/opt/altmedia/share/ffmpeg \
   --incdir=/opt/altmedia/include/ffmpeg \
   --libdir=/opt/altmedia/lib64 \
   --mandir=/opt/altmedia/share/man \
   --arch=x86_64 \
   --enable-gpl \
   --disable-static \
   --enable-shared \
   --enable-pic \
   --disable-debug \
   --enable-libaom \
   --enable-libass \
   --enable-libfreetype \
   --enable-libtwolame \
   --enable-libmp3lame \
   --enable-libopus \
   --enable-libvorbis \
   --enable-libspeex \
   --enable-libvpx \
   --enable-libdav1d \
   --enable-libsvtav1 \
   --enable-cairo \
   --enable-libpulse \
   --enable-gnutls \
   --extra-cflags=-I/opt/altmedia/include \
   --extra-ldflags=-L/opt/altmedia/lib64 \
   --shlibdir=/opt/altmedia/lib64 \
   --enable-runtime-cpudetect \
   --ignore-tests=enhanced-flv-av1,enhanced-flv-multitrack \
   --docdir=/opt/altmedia/share/doc/ffmpeg

The results of that configure script are in build.log 75–783.
Of possible interest is line 78:

ARCH                      x86 (generic)

Is that correct on x86_64 ???

The mock configuration files I am using:

Basically it only pulls in packages from Fedora, Fedora Updates, and my altmedia
repository for which all packages is /opt/altmedia as their install prefix,
the RPM spec files are in ../SPECS/.

The specific altmedia packages used as build dependencies:

  • altmedia-1.0-0.fc42.4.x86_64
  • altmedia-dav1d-devel-1.5.3-1.fc42.0.x86_64
  • altmedia-lame-devel-3.100-1.fc42.1.x86_64
  • altmedia-lame-libs-3.100-1.fc42.1.x86_64
  • altmedia-libaom-3.12.0-1.fc42.0.x86_64
  • altmedia-libaom-devel-3.12.0-1.fc42.0.x86_64
  • altmedia-libdav1d-1.5.3-1.fc42.0.x86_64
  • altmedia-libogg-1.3.6-1.fc42.0.x86_64
  • altmedia-libogg-devel-1.3.6-1.fc42.0.x86_64
  • altmedia-libsvtav1-4.1.0-1.fc42.0.x86_64
  • altmedia-libsvtav1-devel-4.1.0-1.fc42.0.x86_64
  • altmedia-libtwolame-0.4.0-1.fc42.1.x86_64
  • altmedia-libvorbis-1.3.7-1.fc42.0.x86_64
  • altmedia-libvorbis-devel-1.3.7-1.fc42.0.x86_64
  • altmedia-libvpx-1.16.0-20260523.fc42.0.x86_64
  • altmedia-libvpx-devel-1.16.0-20260523.fc42.0.x86_64
  • altmedia-mpg123-libs-1.33.5-1.fc42.1.x86_64
  • altmedia-opus-1.6.1-1.fc42.1.x86_64
  • altmedia-opus-devel-1.6.1-1.fc42.1.x86_64
  • altmedia-speex-1.2.0-1.fc42.0.x86_64
  • altmedia-speex-devel-1.2.0-1.fc42.0.x86_64
  • altmedia-twolame-devel-0.4.0-1.fc42.1.x86_64

All of those packages were built with the same mock configuration and when
installed on my system at least appear to function properly. It would not
surprise me though if maybe one of them has a pkgconfig file with an error
causing bad linker flags to be used, but not that I have found.

Spec File Notes

The spec file: ffmpeg.spec

Yes, it is incomplete and yes, there are dependencies to be added for features
that are often desired. That’s not the issue, it should be building with the
existing configure parameters.

2

Can you use already packaged ffmpeg rpms from rpmfusion or fedora?

You are on about to go end-of-life version of fedora. Consider updating to f44 or f43 if you can.

When faced with problems building software that is packaged in fedora or rpmfusion I look at the source rpms to get clues on how they built it.

3

I updated to Fedora 44 last night and rebuilt all the dependencies, the issue still exists.

Yes I can use a prebuilt ffmpeg BUT THE WHOLE BLEEPING POINT OF OPEN SOURCE SOFTWARE IS THE RIGHT TO REBUILD IT and with packages like FFmpeg that can be important because you want the right to choose what features it has and what versions of libraries it links against. Historically, the devs of FFmpeg only intended it to be distributed as source.

All the other media related packages I’m rebuilding in /opt/altmedia (chosen that location to avoid file conflicts with vendor packages) is working.

At this point, I’ve stripped FFmpeg configure down to the bare minimum and am still getting this same problem at the same place. I tried redefining the optflags macro to something very simple:

%global optflags -O2 -m64 -march=x86-64

Still, same issue, same place.

I’ll find out what is causing it eventually, I suspect it’s one of the many decisions Fedora decides to make for us in their spaghetti nest of macro definitions that average people like me just don’t know enough about that spaghetti nest to figure out what it is that works 99% of the time but causes corner-case headaches that are difficult to otherwise diagnose.

BTW, it seems the update to Fedora 44 has broken some mock logs. I used to get a nice log called installed_pkgs.log but now it’s full of

error: incorrect format: unknown tag: "pkgid"

So something in my mock configuration that was legal in Fedora 42 no longer is in Fedora 44—although building packages itself seems to still work just fine.

One other thing I tried, sometimes redefining %{_prefix} breaks things because other macros that SHOULD be defined full path (like Fortran include flags) are not defined full path in Fedora’s macro spaghetti nest, so I tried leaving %{_prefix} alone and just setting the prefix flags to FFmpeg to my destination full path, but that didn’t fix the issue either.

It’s probably something simple, I’ll eventually figure it out.

4

WooHoo! I got a successful minimal build

Well…

Processing files: altmedia-ffmpeg-debugsource-8.1.1-0.fc44.0.x86_64
error: Empty %files file /home/mpeters/rpmbuild/BUILD/altmedia-ffmpeg-8.1.1-build/ffmpeg-8.1.1/debugsourcefiles.list

RPM build errors:
    Empty %files file /home/mpeters/rpmbuild/BUILD/altmedia-ffmpeg-8.1.1-build/ffmpeg-8.1.1/debugsourcefiles.list

But that means %build and %install completed, it’s probably the

  --disable-debug      \
  --disable-stripping  \

that is causing that, I can turn off debug package if I need to, but now that I have it building I can undo changes one at a time (e.g. I’d rather use Fedora’s optflag if it actually works) and then re-enable features again.

The culprit I think may have been

export LDFLAGS+=" -no-pie"

I put that in to deal with a different issue which it did deal with, but it looks like that other issue doesn’t exist with minimum options, so there’s likely an option I had selected that isn’t working correctly. I should have a working fairly functional build by Monday.

5

Okay it’s the Fedora %{optflags} that caused the problem fixed by that export. So now it’s a matter of filtering out which of the Fedora %{optflags} caused the first issue.

6

%global _lto_cflags %{nil}

That fixes the %{optflags} definition for building FFmpeg, at least in Fedora and probably most RPM based distros.

7

LOL, I love watching amateurs and the false assumptions they make.

FTR you only need to disable lto for i686 or aarch64 builds

1 Like
8

you are expected to have the appropriate skills to build the software.

9

That kind of arrogant gatekeeping is not and never has been a component of the free software world. We help each other other out when we get stuck and it has always been that way.

10

Sorry you think I am gatekeeping, but the fact is building non trivial software is difficult.
Sure if we have the time we can mentor you in the skills.

11

Feel free to call me amateur. The FFmpeg build consistently fails on x86_64 unless that macro is unset.

12

Notice in this case I found the solution without any of your help.

A reddit user pointed me in the right direction, point out the lto in the CFLAGS could be the problem, and from there I found the macro that defined it.

13

I actually find this whole thread is pointless. Updating ffmpeg to the latest release offers very little change to 7.1.4 (7.1.4 is the latest security /bug release).

Are you going to do the same with kernels and all other security flaws.

14

I understand you find it pointless. That is irrelevant. I was having an issue building something so I sought help. Where’s the fucking crime in that?

15

So you did not look at the scripts used by rpmfusion to build ffmpeg for clues as I suggested?
That is how I learnt to build all sorts of complex software, see how others did it.

16

No, I didn’t look at the rpmfusion script. I usually look at BLFS for build instruction when I get stuck.

17

Works fine here for the rpmfusion packaging

18

I’m happy for them. Truly ecstatic. My mock configuration likely differs from theirs, the way dependencies I am using are built likely differs from theirs. They used the same solution on two hardware platforms, just not x86_64. More power to them.

19

Try reading the spec instead of acting like a fucking jerk!

20

I apologize for coming off as a jerk.

I have reasons for wanting to build it myself. I don’t use rpmfusion because in the past, packages from rpmfusion have caused me problems.

Generally I’m happy just running vanilla Fedora and what vanilla Fedora doesn’t offer that I need, I build it myself, typically in mock.

I’m sorry that’s not how a lot of people do things but it works for me.

Telling me that I shouldn’t be building open software myself when the user having the fundamental right to build it themself is a core concept of the free software movement, from my perspective, that felt like you guys were being a jerk to me. Especially with remarks about being amused watching “amateurs” do things.