[FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

Reindl Harald h.reindl at thelounge.net
Mon Aug 14 16:51:11 EEST 2017

Am 14.08.2017 um 13:51 schrieb Carl Eugen Hoyos:
> 2017-08-14 11:04 GMT+02:00 Reindl Harald <h.reindl at thelounge.net>:
>> frankly without -ffat-lto-objects libx264 and/or the comibnation of static
>> libx264 and static ffmpeg just don't build
> The option should not be needed if your toolchain correctly supports
> lto (and it is not needed here). Is it possible that you have to add it
> because your build is not really an lto build (since something in your
> toolchain - like ar - destroys the lto information but thanks to this option,
> compilation succeeds)?
> In any case: How exactly (without a script) can I reproduce?

the mail you responded to contains the whole rpm-spec you quoted from 
and frankly i have no intention to even consider runnign any 
confgure/make call outside a buildroot

>> - it took my a lot of time to
>> figure out how to get all this crap built
>> a) static at all
> Your binaries are not static.
> (ldd would show no useful output for a static binary, see below)

what the hell - read the whole thread

they *are* static in context libx264 is static linked and there are not 
ffmpeg libraries - and that's what i explained the OP - for a *complete 
static* build you need to handle every library as i did with libx264

the whole intention of the way i build is having the latest ffmpeg with 
the latest x264 in a single binary and don't clash with distribution 
x264/ffmpeg packages - there was never and is no intention to build 
every depending library at my own from source

>> b) lto enabled
> --enable-lto
>> c) hardened
> --toolchain=hardened
fine that every second project invents his own configure flags which 
mangle around with LDFLAGS/CFLAGS, i recently had to puke about MariaDB 
in that context adding unwanted other flags like -g1 overriding a 
explicit -g0 and so on

More information about the ffmpeg-user mailing list