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

[Carl Eugen Hoyos]

2017-08-14 16:49 GMT+02:00 Reindl Harald <h.reindl at thelounge.net>:
>
>
> Am 14.08.2017 um 16:41 schrieb Carl Eugen Hoyos:
>>
>> 2017-08-14 13:51 GMT+02:00 Carl Eugen Hoyos <ceffmpeg at gmail.com>:
>>>
>>> 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)?
>>
>> I can confirm that the reason you "need" -ffat-lto-objects is that you
>> are not actually building with lto.
>>
>> The sad thing is that the optimized h264 cabac reader cannot be
>> compiled with (static) lto. I don't remember the details atm but I
>> suspect you have to disable this optimization in the source code to
>> use lto, it may be better performance-wise to not use lto at all
>> (depending on your exact needs).
>>
>> This bug cannot be worked around with -ffat-lto-objects (you would
>> see the same issue I do if you would actually compile with lto)
>
> well, then i still guess other parts off mpeg can be still lto-optimized
> and only x264 isn't

Nothing above was related to x264 but to the hevc and the h264 decoder.

The work-around for the cabac issue is using --enable-pic, I am not
sure if this has negative effects (speed-wise), a performance test
would be necessary.

In any case, -ffat-lto-objects is never necessary, it only hides the
fact that you are not using lto although using -flto (and friends)
while you would get a compilation error otherwise.

Carl Eugen