Installing Ffmpeg on Amazon Linux - Cpp, Gcc & Libstdc++ Dependancies

Installing ffmpeg on amazon linux - cpp, gcc & libstdc++ dependancies

Here is how to install FFMPEG on Linux using a static build.

A good FAQ is here: https://www.johnvansickle.com/ffmpeg/faq/

SSH into your instance and become root

sudo su -

Go to the the /usr/local/bin directory

cd /usr/local/bin

Inside the /usr/local/bin directory, create an "ffmpeg" directory

mkdir ffmpeg

Go into the new directory

cd ffmpeg

Now, open a browser and go to the list of FFMPEG static builds at https://johnvansickle.com/ffmpeg/ and pick the latest version.

While inside the /usr/local/bin/ffmpeg directory, type the following command to download the static build you have selected

wget https://johnvansickle.com/ffmpeg/builds/ffmpeg-git-amd64-static.tar.xz

Now, untar it...

tar -xzf ffmpeg-git-amd64-static.tar.xz

Run it and check what the latest version is

./ffmpeg -version

The output should look something like this

ffmpeg version N-60675-g8fe1076
built on Feb 16 2014 05:45:47 with gcc 4.6 (Debian 4.6.3-1)
configuration: --prefix=/root/ffmpeg-static/64bit --extra-cflags='-I/root/ffmpeg-
static/64bit/include -static' --extra-ldflags='-L/root/ffmpeg-static/64bit/lib -static' --
extra-libs='-lxml2 -lexpat -lfreetype' --enable-static --disable-shared --disable-ffserver --
disable-doc --enable-bzlib --enable-zlib --enable-postproc --enable-runtime-cpudetect --
enable-libx264 --enable-gpl --enable-libtheora --enable-libvorbis --enable-libmp3lame --
enable-gray --enable-libass --enable-libfreetype --enable-libopenjpeg --enable-libspeex --
enable-libvo-aacenc --enable-libvo-amrwbenc --enable-version3 --enable-libvpx
libavutil 52. 64.100 / 52. 64.100
libavcodec 55. 52.102 / 55. 52.102
libavformat 55. 32.101 / 55. 32.101
libavdevice 55. 9.101 / 55. 9.101
libavfilter 4. 1.102 / 4. 1.102
libswscale 2. 5.101 / 2. 5.101
libswresample 0. 17.104 / 0. 17.104
libpostproc 52. 3.100 / 52. 3.100

If you want to be able to execute FFMPEG from any directory, simply create a symlink into /usr/bin like this:

ln -s /usr/local/bin/ffmpeg/ffmpeg /usr/bin/ffmpeg

The first part (/usr/local/bin/ffmpeg/ffmpeg) is where the file is located after I untarred
the file. The second part (/usr/bin/ffmpeg) is where we want the symlink to go

Now, you should be able to run the command "ffmpeg" from anywhere

How do I get a DoubleClick event in a .NET radio button?

Based on your original suggestion I made a solution without the need to subclass the radiobuton using reflection:

MethodInfo m = typeof(RadioButton).GetMethod("SetStyle", BindingFlags.Instance | BindingFlags.NonPublic);
if (m != null)
{
    m.Invoke(radioButton1, new object[] { ControlStyles.StandardClick | ControlStyles.StandardDoubleClick, true });
}
radioButton1.MouseDoubleClick += radioButton1_MouseDoubleClick;

Now the double click event for the radiobutton is fired.
BTW: The suggestion of Nate using e.Clicks doesn't work. In my tests e.Clicks was always 1 no matter how fast or often I clicked the radiobutton.

/usr/lib/x86_64-linux-gnu/libstdc++.so.6: version CXXABI_1.3.8' not found

Add the library's path to the LD_LIBRARY_PATH environment variable

TL;DR

GCC requires you to tell it where your library is located manually when it can't find the right version, which can be done in a few ways. One is adding it to the LD_LIBRARY_PATH.

export LD_LIBRARY_PATH="/usr/local/lib64/:$LD_LIBRARY_PATH"

For some, the library path will be /usr/local/lib64/. Others have reported the library path /usr/lib/x86_64-linux-gnu/ working for them instead.

Why do we need to add the library to LD_LIBRARY_PATH?

When you compile and install GCC it puts the libraries in one of these directories, but that's all it does. According to the FAQs for libstdc++, the error that we got means that the dynamic linker found the wrong version of the libstdc++ shared library. Because the linker can't find the right version, we have to tell it where to find the libstdc++ library.

The simplest way to fix this is to use the LD_LIBRARY_PATH environment variable, which is a colon-separated list of directories in which the linker will search for shared libraries.

There are other ways as well to fix this issue. You can find this and the other solutions mentioned briefly when you install gcc if you read the make output:

Libraries have been installed in:

/usr/local/lib/../lib32

If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following:

• add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution
• add LIBDIR to the `LD_RUN_PATH' environment variable during linking
• use the `-Wl,-rpath -Wl,LIBDIR' linker flag
• have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages.

Grr, that was simple! Also, "if you ever happen to want to link against the installed libraries," seriously?

Deploying Yesod to Heroku, can't build statically

I have no idea what Yesod is, but I know exactly what each of your other errors means.

First, you should not try to link statically. The warning you get is exactly right: if you link statically, and use one of the routines for which you are getting the warning, then you must arrange to run on a system with exactly the same version of libc.so.6 as the one you used at build time.

Contrary to popular belief, static linking produces less, not more, portable executables on Linux.

Your other (static) link errors are caused by missing libopenssl.a at link time.

But let's assume that you are going to go the "sane" route, and use dynamic linking.

For dynamic linking, Linux (and most other UNIXes) support backward compatibility: an old binary continues to work on newer systems. But they don't support forward compatibility (a binary built on a newer system will generally not run on an older one).

But that's what you are trying to do: you built on a system with glibc-2.14 (or newer), and you are running on a system with glibc-2.13 (or older).

The other thing you need to know is that glibc is composed of some 200+ binaries that must all match exactly. Two key binaries are /lib/ld-linux.so and /lib/libc.so.6 (but there are many more: libpthread.so.0, libnsl.so.1, etc. etc). If some of these binaries came from different versions of glibc, you usually get a crash. And that is exactly what you got, when you tried to place your glibc-2.14 libc.so.6 on the LD_LIBRARY_PATH -- it no longer matches the system /lib/ld-linux.

So what are the solutions? There are several possibilities (in increasing difficulty):

1. You could copy ld-2.14.so (the target of /lib/ld-linux symlink) to the target system, and invoke it explicitly:

   /path/to/ld-2.14.so --library-path <whatever> /path/to/your/executable
   

   This generally works, but can confuse an application that looks at argv[0], and breaks for applications that re-exec themselves.

2. You could build on an older system.

3. You could use appgcc (this option has disappeared, see this for description of what it used to be).

4. You could set up a chroot environment matching the target system, and build inside that chroot.

5. You could build yourself a Linux-to-olderLinux crosscompiler

Error building gcc 4.8.3 from source: libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /usr/lib/x86_64-linux-gnu/libicuuc.so.55)

So, this problem occurs when a library that has been built with a newer compiler is linked with an older version of C++ library - or sometimes when a newer headerfile is used to compile something that then links to an older C++ library.

It is also possible come up with a similar problem when moving binary files from one system to another, if the shared libraries installed on the "new system" are older than the ones on which the code was built.

There are typically three plausible solutions:
1. Recompile the offending library with an older compiler.
2. Install a newever version of the C++ library.
3. Rebuild the C++ library from sources (with a new enough compiler).

---

Related Topics