ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

tlum
I'm having trouble adding OpenJPEG to my ffmpeg build. I'm doing a static build, still I'm getting:

ffmpeg: error while loading shared libraries: libopenjp2.so.7: cannot open shared object file: No such file or directory

This is on my build machine which has built a working ffmpeg a few times in the past. I'm a CentOS shop and try to make it a point not to build/install shared libraries that are not is the distro's repository, so, I'm always doing a static build of ffmpeg and the dependencies I'm enabling.

The snapshot I'm using is: N-86964-gf357104
OpenJPEG is: 2.2.0

OpenJPEG is built with:

cmake .. -DCMAKE_INSTALL_PREFIX="$HOME/ffmpeg_build" -DBUILD_SHARED_LIBS:bool=off -DBUILD_CODEC:bool=off -DCMAKE_BUILD_TYPE=Release

It seems to build both lib types:

[root@san1srvp01 build]# make
Scanning dependencies of target openjp2
[  2%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/thread.c.o
[  5%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/bio.c.o
[  7%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/cio.c.o
[ 10%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/dwt.c.o
[ 12%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/event.c.o
[ 15%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/image.c.o
[ 17%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/invert.c.o
[ 20%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/j2k.c.o
[ 22%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/jp2.c.o
[ 25%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/mct.c.o
[ 27%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/mqc.c.o
[ 30%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/openjpeg.c.o
[ 32%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/opj_clock.c.o
[ 35%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/pi.c.o
[ 37%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/t1.c.o
[ 40%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/t2.c.o
[ 42%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/tcd.c.o
[ 45%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/tgt.c.o
[ 47%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/function_list.c.o
[ 50%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/opj_malloc.c.o
Linking C shared library ../../../bin/libopenjp2.so
[ 50%] Built target openjp2
Scanning dependencies of target openjp2_static
[ 52%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/thread.c.o
[ 55%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/bio.c.o
[ 57%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/cio.c.o
[ 60%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/dwt.c.o
[ 62%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/event.c.o
[ 65%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/image.c.o
[ 67%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/invert.c.o
[ 70%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/j2k.c.o
[ 72%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/jp2.c.o
[ 75%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/mct.c.o
[ 77%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/mqc.c.o
[ 80%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/openjpeg.c.o
[ 82%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/opj_clock.c.o
[ 85%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/pi.c.o
[ 87%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/t1.c.o
[ 90%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/t2.c.o
[ 92%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/tcd.c.o
[ 95%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/tgt.c.o
[ 97%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/function_list.c.o
[100%] Building C object src/lib/openjp2/CMakeFiles/openjp2_static.dir/opj_malloc.c.o
Linking C static library ../../../bin/libopenjp2.a
[100%] Built target openjp2_static

It also appears to install both targets:

[root@san1srvp01 build]# make install
[ 50%] Built target openjp2
[100%] Built target openjp2_static
Install the project...
-- Install configuration: "Release"
-- Installing: /root/ffmpeg_build/lib/openjpeg-2.2/OpenJPEGTargets.cmake
-- Installing: /root/ffmpeg_build/lib/openjpeg-2.2/OpenJPEGTargets-release.cmake
-- Installing: /root/ffmpeg_build/lib/openjpeg-2.2/OpenJPEGConfig.cmake
-- Installing: /root/ffmpeg_build/lib/pkgconfig/libopenjp2.pc
-- Installing: /root/ffmpeg_build/include/openjpeg-2.2/opj_config.h
-- Installing: /root/ffmpeg_build/lib/libopenjp2.so.2.2.0
-- Installing: /root/ffmpeg_build/lib/libopenjp2.so.7
-- Installing: /root/ffmpeg_build/lib/libopenjp2.so
-- Installing: /root/ffmpeg_build/lib/libopenjp2.a
-- Installing: /root/ffmpeg_build/include/openjpeg-2.2/openjpeg.h
-- Installing: /root/ffmpeg_build/include/openjpeg-2.2/opj_stdint.h


...and it has in fact installed both libraries:

[root@san1srvp01 lib]# ls -al libopen*
-rw-r--r--. 1 root root 452858 Aug 11 16:57 libopenjp2.a
lrwxrwxrwx. 1 root root     15 Aug 11 17:00 libopenjp2.so -> libopenjp2.so.7
-rwxr-xr-x. 1 root root 364464 Aug 11 16:57 libopenjp2.so.2.2.0
lrwxrwxrwx. 1 root root     19 Aug 11 17:00 libopenjp2.so.7 -> libopenjp2.so.2.2.0


ffmpeg is being configured like so:

PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure --prefix="$HOME/ffmpeg_build" \
  --extra-cflags="-I$HOME/ffmpeg_build/include" --extra-ldflags="-L$HOME/ffmpeg_build/lib -ldl" \
  --bindir="$HOME/bin" --pkg-config-flags="--static" \
  --enable-gpl \
  --enable-libfdk_aac \
  --enable-libfreetype \
  --enable-libmp3lame \
  --enable-libopus \
  --enable-libvorbis \
  --enable-libvpx \
  --enable-libx264 \
  --enable-libx265 \
  --enable-nonfree \
  --enable-libvidstab \
  --enable-libfontconfig \
  --enable-libfribidi \
  --enable-libass \
  --enable-libopenjpeg

configure confirms:

static                    yes
shared                    no


But the resulting binaries throw the shared library error. Without --enable-libopenjpeg it works fine... aside from the fact that #6375 broke it with just about every file I have.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

Moritz Barsnick
On Fri, Aug 11, 2017 at 16:27:16 -0700, tlum wrote:

Wow, how did you manage to compose this email? See here, this is what
the users get:
http://ffmpeg.org/pipermail/ffmpeg-user/2017-August/036951.html

I can see it here though:
http://www.ffmpeg-archive.org/ffmpeg-built-static-yet-quot-libopenjp2-so-7-cannot-open-shared-object-file-quot-td4680895.html

> I'm having trouble adding OpenJPEG to my ffmpeg build. I'm doing a static
> build, still I'm getting:
>
> ffmpeg: error while loading shared libraries: libopenjp2.so.7: cannot open shared object file: No such file or directory

So apparently, ffmpeg isn't static after all.

> ffmpeg is being configured like so:
>
> PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure --prefix="$HOME/ffmpeg_build" \
>   --extra-cflags="-I$HOME/ffmpeg_build/include" --extra-ldflags="-L$HOME/ffmpeg_build/lib -ldl" \
>   --bindir="$HOME/bin" --pkg-config-flags="--static" \
>   --enable-gpl \
>   --enable-libfdk_aac \
>   --enable-libfreetype \
>   --enable-libmp3lame \
>   --enable-libopus \
>   --enable-libvorbis \
>   --enable-libvpx \
>   --enable-libx264 \
>   --enable-libx265 \
>   --enable-nonfree \
>   --enable-libvidstab \
>   --enable-libfontconfig \
>   --enable-libfribidi \
>   --enable-libass \
>   --enable-libopenjpeg
[...]
> configure confirms:
>
> configure confirms:
>
> static                    yes
> shared                    no

Well, either something is going wrong during the configure or linking
process, or you are not using that ffmpeg binary.

What does
$ which ffmpeg
$ file ffmpeg
$ ldd ffmpeg
and finally
$ ffmpeg
say?

Moritz
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

Reindl Harald


Am 12.08.2017 um 22:27 schrieb Moritz Barsnick:
> On Fri, Aug 11, 2017 at 16:27:16 -0700, tlum wrote:
>> I'm having trouble adding OpenJPEG to my ffmpeg build. I'm doing a static
>> build, still I'm getting:
>>
>> ffmpeg: error while loading shared libraries: libopenjp2.so.7: cannot open shared object file: No such file or directory
>
> So apparently, ffmpeg isn't static after all

it's nearly impossible to get it completly static, most distributions
just don't ship the needed static bits of libraries

that below is a "static" ffmpeg while x264 is in fact static linked
because built so at my own but doing that for the rest is more or less
impossible or not worth the work

people really should stick at distribution packages or when build at
their own get some basics right

[harry@srv-rhsoft:~]$ ldd /usr/local/bin/ffmpeg
         linux-vdso.so.1 (0x00007ffc4f3c9000)
         libdl.so.2 => /lib64/libdl.so.2 (0x00007f599217c000)
         libvdpau.so.1 => /lib64/libvdpau.so.1 (0x00007f5991f78000)
         libva.so.1 => /lib64/libva.so.1 (0x00007f5991d58000)
         libva-x11.so.1 => /lib64/libva-x11.so.1 (0x00007f5991b52000)
         libX11.so.6 => /lib64/libX11.so.6 (0x00007f5991813000)
         libva-drm.so.1 => /lib64/libva-drm.so.1 (0x00007f5991610000)
         libssl.so.10 => /lib64/libssl.so.10 (0x00007f599139e000)
         libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f5990f3d000)
         libx265.so.79 => /lib64/libx265.so.79 (0x00007f59909ea000)
         libvpx.so.4 => /lib64/libvpx.so.4 (0x00007f59905e1000)
         libm.so.6 => /lib64/libm.so.6 (0x00007f59902d8000)
         libtheoraenc.so.1 => /lib64/libtheoraenc.so.1 (0x00007f5990097000)
         libtheoradec.so.1 => /lib64/libtheoradec.so.1 (0x00007f598fe7c000)
         libmp3lame.so.0 => /lib64/libmp3lame.so.0 (0x00007f5994132000)
         liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f598fc56000)
         libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f598fa46000)
         libz.so.1 => /lib64/libz.so.1 (0x00007f598f830000)
         libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f598f619000)
         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f598f3fb000)
         libc.so.6 => /lib64/libc.so.6 (0x00007f598f035000)
         /lib64/ld-linux-x86-64.so.2 (0x00007f5993fde000)
         libXext.so.6 => /lib64/libXext.so.6 (0x00007f598ee23000)
         libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f598ec1d000)
         libdrm.so.2 => /lib64/libdrm.so.2 (0x00007f598ea0c000)
         libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f598e7e4000)
         libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2
(0x00007f598e597000)
         libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f598e2b1000)
         libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f598e0ad000)
         libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f598de7c000)
         librt.so.1 => /lib64/librt.so.1 (0x00007f598dc74000)
         libnuma.so.1 => /lib64/libnuma.so.1 (0x00007f598da69000)
         libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f598d6e1000)
         libogg.so.0 => /lib64/libogg.so.0 (0x00007f598d4da000)
         libmvec.so.1 => /lib64/libmvec.so.1 (0x00007f598d2b0000)
         libgomp.so.1 => /lib64/libgomp.so.1 (0x00007f598d082000)
         libXau.so.6 => /lib64/libXau.so.6 (0x00007f598ce7e000)
         libkrb5support.so.0 => /lib64/libkrb5support.so.0
(0x00007f598cc6f000)
         libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f598ca6b000)
         libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f598c850000)
         libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f598c629000)
         libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f598c3b7000)
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

tlum
In reply to this post by Moritz Barsnick
On 8/12/2017 4:27 PM, Moritz Barsnick wrote:
> On Fri, Aug 11, 2017 at 16:27:16 -0700, tlum wrote:
>
> Wow, how did you manage to compose this email? See here, this is what
> the users get:
> http://ffmpeg.org/pipermail/ffmpeg-user/2017-August/036951.html
>
> I can see it here though:
> http://www.ffmpeg-archive.org/ffmpeg-built-static-yet-quot-libopenjp2-so-7-cannot-open-shared-object-file-quot-td4680895.html
Yea... terribly sorry about that. First time using that gateway... I had
no I idea it was going to munge it like that. Promise I won't do that again.

>> I'm having trouble adding OpenJPEG to my ffmpeg build. I'm doing a static
>> build, still I'm getting:
>>
>> ffmpeg: error while loading shared libraries: libopenjp2.so.7: cannot open shared object file: No such file or directory
> So apparently, ffmpeg isn't static after all.
Well, in one sense it is, because most of the other libraries don't even
build shared versions, so I know it does link and work with the static
libraries. In another sense it's not, because C and C++ programs with
dependencies on glibc aren't really static. My limited understanding is
that it's kind of a hybrid.

>
>> ffmpeg is being configured like so:
>>
>> PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure --prefix="$HOME/ffmpeg_build" \
>>    --extra-cflags="-I$HOME/ffmpeg_build/include" --extra-ldflags="-L$HOME/ffmpeg_build/lib -ldl" \
>>    --bindir="$HOME/bin" --pkg-config-flags="--static" \
>>    --enable-gpl \
>>    --enable-libfdk_aac \
>>    --enable-libfreetype \
>>    --enable-libmp3lame \
>>    --enable-libopus \
>>    --enable-libvorbis \
>>    --enable-libvpx \
>>    --enable-libx264 \
>>    --enable-libx265 \
>>    --enable-nonfree \
>>    --enable-libvidstab \
>>    --enable-libfontconfig \
>>    --enable-libfribidi \
>>    --enable-libass \
>>    --enable-libopenjpeg
> [...]
>> configure confirms:
>>
>> configure confirms:
>>
>> static                    yes
>> shared                    no
> Well, either something is going wrong during the configure or linking
> process, or you are not using that ffmpeg binary.
>
> What does
> $ which ffmpeg
> $ file ffmpeg
> $ ldd ffmpeg
> and finally
> $ ffmpeg
> say?
I'm sure there is only one copy of all the executables. They are
actually deployed to /root/bin so they're kept highly isolated from the
rest of the system. Since I've had so many problems with duplicate
dependencies, combing the system for them is one of the first
troubleshooting steps. I'm not opposed to shared libraries, what I'm
opposed to is installing a shared library that didn't come from a
repository in an rpm using yum. Otherwise, I find you tend to end up
with a lot of stray, unmanaged, dependencies causing conflicts, and it
makes it difficult to deploy applications when dependencies aren't
readily available. When I'm forced to, I'll do an rpmbuild and drop them
on the local repository so they're at least managed, deconflicted, and
easy to deploy, but I'd rather manage one build than one build + a bunch
of single use dependent libraries... economies of scale come from
actually sharing shared objects.

So, we have:

[root@san1srvp01 ~]# which ffmpeg
/root/bin/ffmpeg

[root@san1srvp01 ~]# file /root/bin/ffmpeg
/root/bin/ffmpeg: ELF 64-bit LSB executable, x86-64, version 1
(GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux
2.6.32, BuildID[sha1]=293e48bcdcde80eed190f5514bde9862cc3a6195, stripped

[root@san1srvp01 ~]# ldd /root/bin/ffmpeg
         linux-vdso.so.1 =>  (0x00007ffe29370000)
         libdl.so.2 => /lib64/libdl.so.2 (0x00007ff19d75e000)
         libass.so.5 => /lib64/libass.so.5 (0x00007ff19d534000)
         libm.so.6 => /lib64/libm.so.6 (0x00007ff19d231000)
         libfontconfig.so.1 => /lib64/libfontconfig.so.1
(0x00007ff19cff4000)
         libfribidi.so.0 => /lib64/libfribidi.so.0 (0x00007ff19cddb000)
         libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007ff19cb34000)
         libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007ff19c82b000)
         librt.so.1 => /lib64/librt.so.1 (0x00007ff19c623000)
         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff19c406000)
         libgomp.so.1 => /lib64/libgomp.so.1 (0x00007ff19c1e0000)
         liblzma.so.5 => /lib64/liblzma.so.5 (0x00007ff19bfba000)
         libz.so.1 => /lib64/libz.so.1 (0x00007ff19bda3000)
         libc.so.6 => /lib64/libc.so.6 (0x00007ff19b9e2000)
         /lib64/ld-linux-x86-64.so.2 (0x00007ff19d96d000)
         libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x00007ff19b789000)
         libexpat.so.1 => /lib64/libexpat.so.1 (0x00007ff19b55e000)
         libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff19b348000)
         libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007ff19b010000)
         libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x00007ff19ade3000)

I am using some shared libraries:

fribidi-0.19.4-6.el7.x86_64 : Library implementing the Unicode
Bidirectional Algorithm
Repo        : @base
Matched from:
Filename    : /usr/lib64/libfribidi.so.0
Filename    : /usr/lib64/libfribidi.so.0.3.3

fribidi-devel-0.19.4-6.el7.x86_64 : Libraries and include files for FriBidi
Repo        : @base
Matched from:
Filename    : /usr/lib64/libfribidi.so

fontconfig-2.10.95-10.el7.x86_64 : Font configuration and customization
library
Repo        : @base
Matched from:
Filename    : /usr/lib64/libfontconfig.so.1.7.0
Filename    : /usr/lib64/libfontconfig.so.1

fontconfig-devel-2.10.95-10.el7.x86_64 : Font configuration and
customization library
Repo        : @base
Matched from:
Filename    : /usr/lib64/libfontconfig.so

freetype-2.4.11-12.el7.x86_64 : A free and portable font rendering engine
Repo        : @base
Matched from:
Filename    : /usr/lib64/libfreetype.so.6.10.0
Filename    : /usr/lib64/libfreetype.so.6

freetype-devel-2.4.11-12.el7.x86_64 : FreeType development libraries and
header files
Repo        : @base
Matched from:
Filename    : /usr/lib64/libfreetype.so

libass-0.13.4-1.el7.x86_64 : Portable library for SSA/ASS subtitles
rendering
Repo        : @epel
Matched from:
Filename    : /usr/lib64/libass.so.5.3.2
Filename    : /usr/lib64/libass.so.5

libass-devel-0.13.4-1.el7.x86_64 : Development files for libass
Repo        : @epel
Matched from:
Filename    : /usr/lib64/libass.so
Filename    : /usr/lib64/pkgconfig/libass.pc

Right now, it's compiled without --enable-libopenjpeg because I needed
to get some work done. Otherwise you wouldn't even get the header (see
below), you'd just get the missing library error.

[root@san1srvp01 ~]# ffmpeg
ffmpeg version N-86964-gf357104 Copyright (c) 2000-2017 the FFmpeg
developers
   built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-11)
   configuration: --prefix=/root/ffmpeg_build
--extra-cflags=-I/root/ffmpeg_build/include
--extra-ldflags='-L/root/ffmpeg_build/lib -ldl' --bindir=/root/bin
--pkg-config-flags=--static --enable-gpl --enable-libfdk_aac
--enable-libfreetype --enable-libmp3lame --enable-libopus
--enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265
--enable-nonfree --enable-libvidstab --enable-libfontconfig
--enable-libfribidi --enable-libass
   libavutil      55. 73.100 / 55. 73.100
   libavcodec     57.102.100 / 57.102.100
   libavformat    57. 76.100 / 57. 76.100
   libavdevice    57.  7.100 / 57.  7.100
   libavfilter     6. 98.100 /  6. 98.100
   libswscale      4.  7.102 /  4.  7.102
   libswresample   2.  8.100 /  2.  8.100
   libpostproc    54.  6.100 / 54.  6.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile
options] outfile}...

>
> Moritz
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

Reindl Harald

Am 13.08.2017 um 02:23 schrieb Ted Lum:
> I'm sure there is only one copy of all the executables. They are
> actually deployed to /root/bin so they're kept highly isolated from the
> rest of the system.
>
> So, we have:
>
> [root@san1srvp01 ~]# which ffmpeg
> /root/bin/ffmpeg

jesus christ don't run *especially* codec software as root - that's what
/usr/local is for - let me guess - you fire also "make" as root?

and since making /root readable for others is also a terrible idea
there's no business for /root/bin at all
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

tlum
On 8/12/2017 8:28 PM, Reindl Harald [via FFmpeg-users] wrote:

Am 13.08.2017 um 02:23 schrieb Ted Lum:
> I'm sure there is only one copy of all the executables. They are
> actually deployed to /root/bin so they're kept highly isolated from the
> rest of the system.
>
> So, we have:
>
> [root@san1srvp01 ~]# which ffmpeg
> /root/bin/ffmpeg

jesus christ don't run *especially* codec software as root - that's what
/usr/local is for - let me guess - you fire also "make" as root?

and since making /root readable for others is also a terrible idea
there's no business for /root/bin at all

It's a build VM. I spin them up from and image, do what I've got to do, and then generally destroy them. It's also generally a terrible idea to install compilers and development libraries on production systems, hence the build environment.

Production deployment is a lot more controlled and standardized as you might expect.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".


If you reply to this email, your message will be added to the discussion below:
http://www.ffmpeg-archive.org/ffmpeg-built-static-yet-libopenjp2-so-7-cannot-open-shared-object-file-tp4680895p4680907.html
To unsubscribe from ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file", click here.
NAML


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

Reindl Harald


Am 13.08.2017 um 02:59 schrieb tlum:

> On 8/12/2017 8:28 PM, Reindl Harald [via FFmpeg-users] wrote:
>>
>> Am 13.08.2017 um 02:23 schrieb Ted Lum:
>>> I'm sure there is only one copy of all the executables. They are
>>> actually deployed to /root/bin so they're kept highly isolated from the
>>> rest of the system.
>>>
>>> So, we have:
>>>
>>> [root@san1srvp01 ~]# which ffmpeg
>>> /root/bin/ffmpeg
>>
>> jesus christ don't run *especially* codec software as root - that's what
>> /usr/local is for - let me guess - you fire also "make" as root?
>>
>> and since making /root readable for others is also a terrible idea
>> there's no business for /root/bin at all
>
> It's a build VM. I spin them up from and image, do what I've got to do,
> and then generally destroy them

that don't justify root as nothing justify root for non administrative
commands, frankly some software out there even refuses ./configure as
root for that reason

> It's also generally a terrible idea to
> install compilers and development libraries on production systems, hence
> the build environment.

yes, hence a proper build system is using something like "rpmbuild"
which always starts in a clean buildroot adn even don't need root
permission for "make install"

> Production deployment is a lot more controlled and standardized as you
> might expect
i strongly doubt that starting with that the environments are completly
different and the lack of a proper buildsystem is the root cause of the
thread topic "libopenjp2.so.7: cannot open shared object file"

rpmbuild would have generated proper dependencies to begin with

[harry@srv-rhsoft:~]$ rpm -q ffmpeg-latest
ffmpeg-latest-3.3.3-1.fc25.20170730.rh.x86_64
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

tlum
On 8/13/2017 6:58 AM, Reindl Harald [via FFmpeg-users] wrote:


Am 13.08.2017 um 02:59 schrieb tlum:

> On 8/12/2017 8:28 PM, Reindl Harald [via FFmpeg-users] wrote:
>>
>> Am 13.08.2017 um 02:23 schrieb Ted Lum:
>>> I'm sure there is only one copy of all the executables. They are
>>> actually deployed to /root/bin so they're kept highly isolated from the
>>> rest of the system.
>>>
>>> So, we have:
>>>
>>> [root@san1srvp01 ~]# which ffmpeg
>>> /root/bin/ffmpeg
>>
>> jesus christ don't run *especially* codec software as root - that's what
>> /usr/local is for - let me guess - you fire also "make" as root?
>>
>> and since making /root readable for others is also a terrible idea
>> there's no business for /root/bin at all
>
> It's a build VM. I spin them up from and image, do what I've got to do,
> and then generally destroy them

that don't justify root as nothing justify root for non administrative
commands, frankly some software out there even refuses ./configure as
root for that reason

> It's also generally a terrible idea to
> install compilers and development libraries on production systems, hence
> the build environment.

yes, hence a proper build system is using something like "rpmbuild"
which always starts in a clean buildroot adn even don't need root
permission for "make install"

> Production deployment is a lot more controlled and standardized as you
> might expect
i strongly doubt that starting with that the environments are completly
different and the lack of a proper buildsystem is the root cause of the
thread topic "libopenjp2.so.7: cannot open shared object file"

rpmbuild would have generated proper dependencies to begin with

Lets try and keep this topic on the topic of linking the static libopenjp2.a and away from religious dogma please.

Correct me if I'm mistaken, but AFAIK, ffmpeg does not maintain an srpm?. In any event, that would be tricky to do for static builds, given the licensing. So that leaves us with guides like this one https://trac.ffmpeg.org/wiki/CompilationGuide/Centos .

Your constructive feedback is appreciated.

[harry@srv-rhsoft:~]$ rpm -q ffmpeg-latest
ffmpeg-latest-3.3.3-1.fc25.20170730.rh.x86_64
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".


If you reply to this email, your message will be added to the discussion below:
http://www.ffmpeg-archive.org/ffmpeg-built-static-yet-libopenjp2-so-7-cannot-open-shared-object-file-tp4680895p4680909.html
To unsubscribe from ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file", click here.
NAML

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

Reindl Harald


Am 13.08.2017 um 15:19 schrieb tlum:
> On 8/13/2017 6:58 AM, Reindl Harald [via FFmpeg-users] wrote:
> Lets try and keep this topic on the topic of linking the static
> libopenjp2.a and away from religious dogma please.

you did not provide any useful informations how you built excatly

> Correct me if I'm mistaken, but AFAIK, ffmpeg does not maintain an
> srpm?. In any event, that would be tricky to do for static builds, given
> the licensing

what the hell has licensing with rpmbuild to do?

don't be silly - there is no legal differnce between let spit "make
install" directly into the system or in the buildroot - licensing is all
about distribution and what let you imagine that that case affects
distribute your own self built package to your own servers - it's all
about "can i distribute that package for other people"

> So that leaves us with guides like this one
> https://trac.ffmpeg.org/wiki/CompilationGuide/Centos .

no, that leaves you with "write a spec is not rocket science"

> Your constructive feedback is appreciated

just build and link the library proper, see example for x264 and that
way i can install ffmpeg-libs from fedora-repos for software linked
agianst it and my /usr/bin/ffmpeg is finally always the latest version
for CLI
________________________________________

[builduser@testserver:/rpmbuild/SPECS]$ cat x264-latest.spec
%global            snapshot 20170629

Summary:           H264/AVC video encoder (static build)
Name:              x264-latest
Version:           0.152.2851
Release:           1%{?dist}
License:           GPLv2+
Group:             System Environment/Libraries
URL:               https://www.videolan.org/developers/x264.html
Source0:           x264-%{snapshot}.tar.xz
Source1:           x264-snapshot-latest.sh
BuildRequires:     yasm

%description
x264 is a free library for encoding H264/AVC video streams, written from
scratch

%prep
%setup -q -n x264-%{snapshot}

%build
./configure \
  --prefix=%{_prefix}/local \
  --exec-prefix=%{_prefix}/local \
  --bindir=%{_prefix}/local/bin \
  --libdir=%{_prefix}/local/lib64 \
  --includedir=%{_prefix}/local/include \
  --extra-cflags="%{optflags} -Ofast -ffast-math
-funsafe-math-optimizations -Wno-pointer-sign -minline-all-stringops
-fno-strict-aliasing -flto -ffat-lto-objects -fuse-ld=gold
-fuse-linker-plugin" \
  --extra-ldflags="-Wl,--as-needed -Wl,-z,now -Wl,-z,relro
-Wl,-z,noexecstack %{optflags} -Ofast -ffast-math
-funsafe-math-optimizations -Wno-pointer-sign -minline-all-stringops
-fno-strict-aliasing -flto -ffat-lto-objects -fuse-ld=gold
-fuse-linker-plugin" \
  --enable-lto \
  --enable-static \
  --enable-pic \
  --enable-strip \
  --disable-avs \
  --disable-cli \
  --disable-ffms \
 

  --disable-gpac \
 

  --disable-lavf \
 

  --disable-opencl \
 

  --disable-swscale
 

%{__make} %{?_smp_mflags}
 

 
 

%install
 

make install DESTDIR=%{buildroot}
 

rm -rf %{buildroot}%{_prefix}/local/bin/
 

rm -rf %{buildroot}%{_prefix}/local/lib64/pkgconfig/x264.pc
 

mkdir %{buildroot}%{_prefix}/local/x264/
 

mv %{buildroot}%{_prefix}/local/lib64/libx264.a
%{buildroot}%{_prefix}/local/x264/
mv %{buildroot}%{_prefix}/local/include/x264.h
%{buildroot}%{_prefix}/local/x264/
mv %{buildroot}%{_prefix}/local/include/x264_config.h
%{buildroot}%{_prefix}/local/x264/
strip --strip-unneeded --strip-debug
%{buildroot}%{_prefix}/local/x264/libx264.a

%files
%{_prefix}/local/x264/libx264.a
%{_prefix}/local/x264/x264.h
%{_prefix}/local/x264/x264_config.h

%changelog
* Thu Jun 29 2017 Reindl Harald <[hidden email]>
- update to upstream snapshot 0.152.2851
________________________________________

[builduser@testserver:/rpmbuild/SPECS]$ cat ffmpeg-latest.spec
%global            snapshot 20170607

Summary:           Audio/Video-Encoder (static build)
Name:              ffmpeg-latest
Version:           3.3.2
Release:           1%{?dist}
License:           GPLv3+
Group:             Applications/Multimedia
URL:               http://ffmpeg.org/
Source0:           ffmpeg-%{snapshot}.tar.xz
Source1:           ffmpeg-snapshot-latest.sh
BuildRequires:     bzip2-devel
BuildRequires:     imlib2-devel
BuildRequires:     lame-devel
BuildRequires:     libtheora-devel
BuildRequires:     x264-latest
BuildRequires:     x265-devel
BuildRequires:     zlib-devel
BuildRequires:     libvpx-devel
BuildRequires:     openssl-devel
BuildRequires:     yasm
Provides:          ffmpeg
Obsoletes:         ffmpeg

%description
FFMpeg is a complete and free Internet live audio and video broadcasting
solution for Linux

%package           manpages
Group:             Manpages
Summary:           Manpages for ffmpeg-latest
BuildArch:         noarch
%description       manpages

%prep
%setup -q -n ffmpeg-%{snapshot}

%build
mkdir generic
pushd generic
../configure \
  --prefix=%{_prefix}/local \
  --bindir=%{_prefix}/local/bin \
  --mandir=%{_prefix}/local/man \
  --extra-cflags="-I%{_prefix}/local/x264 %{optflags} -Ofast -ffast-math
-funsafe-math-optimizations -Wno-pointer-sign -minline-all-stringops
-fno-strict-aliasing -flto -fno-fat-lto-objects -fuse-ld=gold
-fuse-linker-plugin -Wa,--noexecstack" \
  --extra-ldflags="-I%{_prefix}/local/x264 -L%{_prefix}/local/x264 -ldl
-Wl,--as-needed -Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack %{optflags}
-Ofast -ffast-math -funsafe-math-optimizations -Wno-pointer-sign
-minline-all-stringops -fno-strict-aliasing -flto -fno-fat-lto-objects
-pie -fPIE -fuse-ld=gold -fuse-linker-plugin -Wa,--noexecstack" \
  --enable-lto \
  --ar=gcc-ar \
  --ranlib=true \
  --enable-nonfree \
  --enable-gpl \
  --enable-pic \
  --enable-version3 \
  --enable-libmp3lame \
  --enable-libtheora \
  --enable-libx264 \
  --enable-libx265 \
  --enable-libvpx \
  --enable-openssl \
  --enable-static \
  --enable-runtime-cpudetect \
  --disable-amd3dnow \
  --disable-amd3dnowext \
  --disable-avdevice \
  --disable-debug \
  --disable-devices \
  --disable-ffplay \
  --disable-ffprobe \
  --disable-ffserver \
  --disable-htmlpages \
  --disable-hwaccels \
  --disable-iconv \
  --disable-libdc1394 \
  --disable-libfreetype \
  --disable-libgsm \
  --disable-libopencore-amrnb \
  --disable-libopencore-amrwb \
  --disable-libopencv \
  --disable-libopenjpeg \
  --disable-libopus \
  --disable-librtmp \
  --disable-libschroedinger \
  --disable-libspeex \
  --disable-libvorbis \
  --disable-libxvid \
  --disable-podpages \
  --disable-postproc \
  --disable-protocol=gopher \
  --disable-shared \
  --disable-txtpages
%{__make} %{?_smp_mflags}
make documentation
popd
CURRENT_DIR=`pwd`
mkdir -p %{buildroot}%{_prefix}/local/bin/
gcc -fPIC -fPIE -pie -Wl,-z,now -Wl,-z,relro,-z,noexecstack
$CURRENT_DIR/tools/qt-faststart.c -o qt-faststart

%install
pushd generic
make install DESTDIR=%{buildroot}
popd
install -D -m0755 qt-faststart
"%{buildroot}%{_prefix}/local/bin/qt-faststart"
mkdir %{buildroot}%{_bindir}
ln -s %{_prefix}/local/bin/ffmpeg %{buildroot}%{_bindir}/ffmpeg
rm -rf %{buildroot}%{_prefix}/local/include
%{buildroot}%{_prefix}/local/lib %{buildroot}%{_prefix}/local/lib64
%{buildroot}%{_prefix}/local/share
strip -s %{buildroot}%{_prefix}/local/bin/qt-faststart
%{buildroot}%{_prefix}/local/bin/ffmpeg

%files
%{_prefix}/local/bin/ffmpeg
%{_prefix}/local/bin/qt-faststart
%{_bindir}/ffmpeg

%files manpages
%{_prefix}/local/man/man1/*
%{_prefix}/local/man/man3/*

%changelog
* Thu Jun 29 2017 Reindl Harald <[hidden email]>
- rebuild against x264 0.152.2851
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

Carl Eugen Hoyos-2
In reply to this post by Moritz Barsnick
2017-08-12 22:27 GMT+02:00 Moritz Barsnick <[hidden email]>:
> On Fri, Aug 11, 2017 at 16:27:16 -0700, tlum wrote:

>> static                    yes
>> shared                    no
>
> Well, either something is going wrong during the configure or linking
> process, or you are not using that ffmpeg binary.

(Nothing is "wrong" with the linking process: All linkers I know of
prefer dynamic libraries they find over static libraries in the same
directory - which makes sense.)

FFmpeg - as probably any other open source project - can be built
as a completely static binary but this is not related to above output
of configure nor to any configure option, it is a function of your
toolchain (and/or the toolchain-specific options that you pass to
configure).

The options --enable-shared and --disable-static (--disable-shared
and --enable-static being the default as can be seen above) only
control how the libav libraries that are shipped with FFmpeg are
built: Either only as static libraries (this is the default and it makes
testing easier because you can run the resulting ffmpeg binary
from the built directory without installing it as I alwas do) or only
as shared library or both.

If you want any of the external dependencies of FFmpeg (like
x264 or in your case libopenjpeg) linked statically, remove the
.so symlink from the x264/libopenjpeg or the /usr/local/lib*
directory.

If you want a truly static ffmpeg binary, consider using musl,
note that 32bit musl is NOT supported by FFmpeg and this is
not documented (FFmpeg developers are against documenting
this), and you may not immediately notice, the build process
works fine.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

Carl Eugen Hoyos-2
In reply to this post by Reindl Harald
2017-08-13 15:29 GMT+02:00 Reindl Harald <[hidden email]>:

>  --extra-cflags="%{optflags} -Ofast -ffast-math -funsafe-math-optimizations
> -Wno-pointer-sign -minline-all-stringops -fno-strict-aliasing -flto
> -ffat-lto-objects -fuse-ld=gold -fuse-linker-plugin" \
>  --extra-ldflags="-Wl,--as-needed -Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack
> %{optflags} -Ofast -ffast-math -funsafe-math-optimizations -Wno-pointer-sign
> -minline-all-stringops -fno-strict-aliasing -flto -ffat-lto-objects
> -fuse-ld=gold -fuse-linker-plugin" \

Just to make sure: Binaries with such excessive extra-flags
cannot be used for bug reports, a default build will be requested.

(configure options both for lto builds and more "secure" binaries
exist, if -Ofast has any testable advantage with FFmpeg, *please*
report this, same for fat-lto.)

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

Reindl Harald


Am 14.08.2017 um 10:53 schrieb Carl Eugen Hoyos:

> 2017-08-13 15:29 GMT+02:00 Reindl Harald <[hidden email]>:
>
>>   --extra-cflags="%{optflags} -Ofast -ffast-math -funsafe-math-optimizations
>> -Wno-pointer-sign -minline-all-stringops -fno-strict-aliasing -flto
>> -ffat-lto-objects -fuse-ld=gold -fuse-linker-plugin" \
>>   --extra-ldflags="-Wl,--as-needed -Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack
>> %{optflags} -Ofast -ffast-math -funsafe-math-optimizations -Wno-pointer-sign
>> -minline-all-stringops -fno-strict-aliasing -flto -ffat-lto-objects
>> -fuse-ld=gold -fuse-linker-plugin" \
>
> Just to make sure: Binaries with such excessive extra-flags
> cannot be used for bug reports, a default build will be requested.
>
> (configure options both for lto builds and more "secure" binaries
> exist, if -Ofast has any testable advantage with FFmpeg, *please*
> report this, same for fat-lto.)

frankly without -ffat-lto-objects libx264 and/or the comibnation of
static libx264 and static ffmpeg just don't build - it took my a lot of
time to figure out how to get all this crap built

a) static at all
b) lto enabled
c) hardened

[root@rh:~]$ /usr/bin/hardening-check /usr/local/bin/ffmpeg
/usr/local/bin/ffmpeg:
  Position Independent Executable: yes
  Stack protected: yes
  Fortify Source functions: yes (some protected functions found)
  Read-only relocations: yes
  Immediate binding: yes

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

Carl Eugen Hoyos-2
2017-08-14 11:04 GMT+02:00 Reindl Harald <[hidden email]>:
> 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?

> - 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)

> b) lto enabled

--enable-lto

> c) hardened

--toolchain=hardened

Carl Eugen

$ file ffmpeg
ffmpeg: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
statically linked, stripped
$ ldd ffmpeg
        not a dynamic executable
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

Reindl Harald


Am 14.08.2017 um 13:51 schrieb Carl Eugen Hoyos:

> 2017-08-14 11:04 GMT+02:00 Reindl Harald <[hidden email]>:
>> 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
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

Carl Eugen Hoyos-2
In reply to this post by Carl Eugen Hoyos-2
2017-08-14 13:51 GMT+02:00 Carl Eugen Hoyos <[hidden email]>:
> 2017-08-14 11:04 GMT+02:00 Reindl Harald <[hidden email]>:
>> 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).

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

Reindl Harald


Am 14.08.2017 um 16:41 schrieb Carl Eugen Hoyos:

> 2017-08-14 13:51 GMT+02:00 Carl Eugen Hoyos <[hidden email]>:
>> 2017-08-14 11:04 GMT+02:00 Reindl Harald <[hidden email]>:
>>> 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
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

Carl Eugen Hoyos-2
2017-08-14 16:49 GMT+02:00 Reindl Harald <[hidden email]>:

>
>
> Am 14.08.2017 um 16:41 schrieb Carl Eugen Hoyos:
>>
>> 2017-08-14 13:51 GMT+02:00 Carl Eugen Hoyos <[hidden email]>:
>>>
>>> 2017-08-14 11:04 GMT+02:00 Reindl Harald <[hidden email]>:
>>>>
>>>> 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
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

Reindl Harald


Am 14.08.2017 um 16:56 schrieb Carl Eugen Hoyos:

> 2017-08-14 16:49 GMT+02:00 Reindl Harald <[hidden email]>:
>>
>>
>> Am 14.08.2017 um 16:41 schrieb Carl Eugen Hoyos:
>>>
>>> 2017-08-14 13:51 GMT+02:00 Carl Eugen Hoyos <[hidden email]>:
>>>>
>>>> 2017-08-14 11:04 GMT+02:00 Reindl Harald <[hidden email]>:
>>>>>
>>>>> 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

as you can see in the rpm spec (relevant part quoted again below) this
is alreayd enabled and that's in fact part of the hardening stuff

%build
 

mkdir generic
 

pushd generic
 

../configure \
 

  --prefix=%{_prefix}/local \
 

  --bindir=%{_prefix}/local/bin \
 

  --mandir=%{_prefix}/local/man \
 

  --extra-cflags="-I%{_prefix}/local/x264 %{optflags} -Ofast -ffast-math
-funsafe-math-optimizations -Wno-pointer-sign -minline-all-stringops
-fno-strict-aliasing -flto -fno-fat-lto-objects -fuse-ld=gold
-fuse-linker-plugin -Wa,--noexecstack" \
 

  --extra-ldflags="-I%{_prefix}/local/x264 -L%{_prefix}/local/x264 -ldl
-Wl,--as-needed -Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack %{optflags}
-Ofast -ffast-math -funsafe-math-optimizations -Wno-pointer-sign
-minline-all-stringops -fno-strict-aliasing -flto -fno-fat-lto-objects
-pie -fPIE -fuse-ld=gold -fuse-linker-plugin -Wa,--noexecstack" \
  --enable-lto \
  --ar=gcc-ar \
  --ranlib=true \
  --enable-nonfree \
  --enable-gpl \
  --enable-pic \
  --enable-version3 \
  --enable-libmp3lame \
  --enable-libtheora \
  --enable-libx264 \
  --enable-libx265 \
  --enable-libvpx \
  --enable-openssl \
  --enable-static \
  --enable-runtime-cpudetect \
  --disable-amd3dnow \
  --disable-amd3dnowext \
  --disable-avdevice \
  --disable-debug \
  --disable-devices \
  --disable-ffplay \
  --disable-ffprobe \
  --disable-ffserver \
  --disable-htmlpages \
  --disable-hwaccels \
  --disable-iconv \
  --disable-libdc1394 \
  --disable-libfreetype \
  --disable-libgsm \
  --disable-libopencore-amrnb \
  --disable-libopencore-amrwb \
  --disable-libopencv \
  --disable-libopenjpeg \
  --disable-libopus \
  --disable-librtmp \
  --disable-libschroedinger \
  --disable-libspeex \
  --disable-libvorbis \
  --disable-libxvid \
  --disable-podpages \
  --disable-postproc \
  --disable-protocol=gopher \
  --disable-shared \
  --disable-txtpages

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

tlum
In reply to this post by Carl Eugen Hoyos-2
On 8/14/2017 4:49 AM, Carl Eugen Hoyos wrote:
>
> If you want any of the external dependencies of FFmpeg (like
> x264 or in your case libopenjpeg) linked statically, remove the
> .so symlink from the x264/libopenjpeg or the /usr/local/lib*
> directory.
>
>
> Carl Eugen

Thanks. The problem really is more with OpenJPEG. They were messing with
the build flags in response to a users "enhancement request". It seems
like you can't really disable building and installing the shared
libraries. So, if you want a static link you just have to delete them.
Everything is working as expected now.
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

Reindl Harald


Am 15.08.2017 um 04:00 schrieb Ted Lum:

> On 8/14/2017 4:49 AM, Carl Eugen Hoyos wrote:
>>
>> If you want any of the external dependencies of FFmpeg (like
>> x264 or in your case libopenjpeg) linked statically, remove the
>> .so symlink from the x264/libopenjpeg or the /usr/local/lib*
>> directory.
>>
>>
>> Carl Eugen
>
> Thanks. The problem really is more with OpenJPEG. They were messing with
> the build flags in response to a users "enhancement request". It seems
> like you can't really disable building and installing the shared
> libraries. So, if you want a static link you just have to delete them.
> Everything is working as expected now.

well, and that's why building packages
go back in the thread where i showed you how to get x264 static linked

the way it's built it never collides with the system packages and the
way it's linked in the ffmpeg build it's using the correct library

after that setup works you just replace the tarball and change versions
in the spec files and build the stuff just in the right order,
reproduceable forever

[root@buildserver:~]$ rpm -q --filesbypkg
x264-latest-0.152.2851-1.fc25.20170703.rh.x86_64
x264-latest               /usr/local/x264/libx264.a
x264-latest               /usr/local/x264/x264.h
x264-latest               /usr/local/x264/x264_config.h
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
12
Loading...