Allow inclusion in static builds

[cromefire]

I'm trying to build a static version ffmpeg including rav1e, but it seems like one can't compile a static library that includes lgcc_s, because there's only a shard version of it.

gcc-10 -L<prefix>/lib -I<prefix>/lib -L/usr/lib/gcc/x86_64-linux-gnu/10 -static -Wl,--as-needed -Wl,-z,noexecstack -I<prefix>/include/rav1e -L<prefix>/lib -o /tmp/ffconf.EpJq5glV/test /tmp/ffconf.EpJq5glV/test.o -lrav1e -lgcc_s -lutil -lrt -lpthread -lm -ldl -lc -lgcc_s -lutil -lrt -lpthread -lm -ldl -lc -lm -lpthread
/usr/bin/ld: cannot find -lgcc_s
collect2: error: ld returned 1 exit status
ERROR: rav1e >= 0.1.0 not found using pkg-config

I'm not a lot into C so I'm not sure if that is something that even can be changed at all or if there's something I couldn't find that's allows this (although I searched quite thorough and all of the "solutions" simply didn't work or aren't applicable).

[lu-zero]

It seems a local problem. You seem to be missing a base library.

[cromefire]

Yeah I do have libgcc_s.so, but that's not going to work for a static (libgcc_s.a) build and that's doesn't seem to be available as static library (for technical reasons I guess)

[cromefire]

Ref: https://packages.ubuntu.com/search?searchon=contents&keywords=libgcc_s.a&mode=filename&suite=focal&arch=amd64 (the few results are only mingw, which probably isn't really helpful in this instance)

[cromefire]

If you look it up, you see a lot of people suggesting liking it dynamically, which isn't quite possible here, because it's defined via pkgconfig: https://stackoverflow.com/a/18803598/8220327

[cromefire]

For reference the generated .pc file looks like this:

prefix=/path/to/the/prefix
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: rav1e
Description: The fastest and safest AV1 encoder
Version: 0.4.0
Libs: -L${libdir} -lrav1e  -lgcc_s -lutil -lrt -lpthread -lm -ldl -lc
Cflags: -I${includedir}/rav1e
Libs.private:  -lgcc_s -lutil -lrt -lpthread -lm -ldl -lc

[barrbrain]

I see in https://askubuntu.com/a/1190778 that someone recommends removing the rav1e shared library to build ffmpeg. We should look into why this workaround is necessary for some configurations.

[cromefire]

I'm actually building without shared libraries:

RUSTFLAGS="-C target-cpu=native" cargo cinstall --release --locked --prefix "${prefix}" --library-type staticlib

I did not see any difference vs not doing that though

[cromefire]

To be clear: If I'm not linking it statically it's working just fine, it's only having problems while linking statically

[tdaede]

FWIW I double checked and on Fedora Linux and my .pc also has -lgcc_s.

I did notice there is a -static-libgcc option to gcc, however I've not tested it. (I'm also not sure why rav1e depends on libgcc_s...)

prefix=/usr/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: rav1e
Description: The fastest and safest AV1 encoder
Version: 0.5.0-alpha
Libs: -L${libdir} -lrav1e
Cflags: -I${includedir}/rav1e
Libs.private:  -lutil -ldl -lutil -lgcc_s -lutil -lrt -lpthread -lm -ldl -lc

[cromefire]

I tested -static-libgcc and it didn't work, I tried to remove the -lgcc_s and it did actually compile (it requires manually modifying the .pc file though), I'll check later if that still works during runtime

[barrbrain]

I note that media-autobuild_suite is also using this workaround for static builds:
https://github.com/m-ab-s/media-autobuild_suite/blob/962658b9/build/media-suite_compile.sh#L1077-L1088

[cromefire]

It seems to be target at Windows though so there might be a difference there (likely using mingw, which seems to bring a static version of libgcc_s)

[tdaede]

Apparently Rust's own unwinder normally depends on libgcc_s. I'm not sure if we can disable the unwinder (or would even want to - it probably requires abort on panic), though I did find this option for using libunwind instead, which might be easier to statically link. Maybe we should do this by default. rust-lang/rust#59089

[cromefire]

Even if not by default (one probably should benchmark it and look at the consequences for compilation and usage), it might make sense to add it as an option if that's possible

[lu-zero]

You should open the issue on the rust side, we receive the link line directly from the compiler.