I am planning to create a new app for personal use on my Mac that uses FFMPEG library, to store a feed from a RTSP IP camera.
Following this official installation procedure from FFMPEG I have manage to successfully achieve the following 2 steps:
To get ffmpeg for OS X, you first have to install ​Homebrew. If you don't want to use Homebrew, see the section below.
ruby -e "$(curl -fsSL
https://raw.githubusercontent.com/Homebrew/install/master/install)"
Then:
- brew install automake fdk-aac git lame libass libtool libvorbis
libvpx \ opus sdl shtool texi2html theora wget x264 xvid yasm
Question:
My question here because I am confused, is how to import a library into Xcode so I can use it in the application I am about to build for my Mac. I can see plenty of GitHub projects related to FFMPEG with IOS/Android, but none for OSX.
All the FFMPEG commands under terminal are working fine, such as converting a video etc.
If you look in /usr/local/Cellar/ffmpeg you will find the actual ffmpeg package and everything in homebrew is just symbolic links to that. For example:
/usr/local/bin/ffmpeg -> ../Cellar/ffmpeg/3.0.2/bin/ffmpeg
Now, if you stay in that directory and do this, you will find all the pkgconfig configuration settings for the constituent parts of ffmpeg:
find . -name \*.pc
./lib/pkgconfig/libavcodec.pc
./lib/pkgconfig/libavdevice.pc
./lib/pkgconfig/libavfilter.pc
./lib/pkgconfig/libavformat.pc
./lib/pkgconfig/libavresample.pc
./lib/pkgconfig/libavutil.pc
./lib/pkgconfig/libpostproc.pc
./lib/pkgconfig/libswresample.pc
./lib/pkgconfig/libswscale.pc
That means you can now find the include path and library paths that you need to put in the Xcode settings. So, for example, if you want the includes for libavutil, you can do:
pkg-config --cflags libavutil
and it will tell you:
-I/usr/local/Cellar/ffmpeg/3.0.2/include
If you want the library settings for libavfilter, you can do:
pkg-config --libs libavfilter
and it will tell you
-L/usr/local/Cellar/ffmpeg/3.0.2/lib -lavfilter
So that is how you get the settings for the compiler/linker. Then you need to put them into Xcode, and I have described that here - look at the bit with the yellow, red and blue boxes.
Hope that helps. Oh, you need to do:
brew install pkg-config
first to get the pkgconfig binary.
In general, you need to configure the Xcode target build settings to add /usr/local/include to the Header Search Path.
Then your #include <ffmpeg.h> (or whatever it's called) will start to work.
Then for linking to libffmpeg.a (or whatever it's called), you can do one of two things:
Add the file to the Additional Libraries and Frameworks of the build settings (selecting it via a file open dialog).
Add /usr/local/lib to the Library Search Paths and -lffmpeg to the Other Linker Flags.
(1. is better if you ask me).
I use Macports, so for me the paths are /opt/local/{include,lib} however with Homebrew there might be an additional level of directory (like /usr/local/ffmpeg/{include,lib}, but you should be able to work that out yourself.
I won't go into details of how to actually use FFMPEG as that is way too involved (and I know nothing about it).
Although this does not answer the specific question here ("how to import such and such libraries"),
for anyone googling here, these days to use FFmpeg in OSX you just
Use the famous import script of Kewlbear
which you can easily find here
https://github.com/kewlbear/FFmpeg-iOS-build-script
and which does everything.
It is a huge amount of non-trivial work maintaining such a build script, and fortunately there's someone who does that work on an ongoing basis.
Related
A user of xnec2c was trying to build on OSX and had autoconf issues because PKG_CHECK_MODULES could not be found since MacPorts puts it in a funny spot.
The user made autoconf work like so:
ACLOCAL_PATH=/opt/local/share/aclocal ./autogen.sh
ACLOCAL_PATH=/opt/local/share/aclocal ./configure
I would like to make it build on OSX without special user path hacks for ACLOCAL_PATH. Can that be done?
I started writing a possible fix below and realized it could an xyproblem so posed the question just above. However, if this starts any gears turning, then I would be open to a bit of special-casing for OSX:
For example, would it be possible (if not advisable) to detect:
Is PKG_CHECK_MODULES missing?
If so:
is it OSX?
Is [ -d /opt/local/share/aclocal ] true?
Does the macro exist there?
While aclocal has a few ways of appending to its search path (see https://www.gnu.org/software/automake/manual/html_node/Macro-Search-Path.html), you cannot modify that macro search path using code in configure.ac:
When the shell code in configure is run, it is too late, as the available macros have already been expanded. When autoconf (is it autoconf or something else? anyway, m4 called from autoreconf) generates configure from configure.ac by having m4 expand the macros it is also too late: aclocal has already collected the m4 macros it could find.
So what you would need is a step before the autoreconf run - which is beyond what I would consider a buildsystem needs to do.
What you can do: Put static strings into the top level Makefile.am file like e.g.
ACLOCAL_AMFLAGS = -I auto-m4 -I project-m4 -I /opt/local/share/aclocal
(this example uses auto-m4/ with AC_CONFIG_MACRO_DIR([auto-m4]) for the *.m4 files automatically put there by autoreconf/autopoint/libtoolize and project-m4/ for the project specific *.m4 files).
Of course, you should already have
m4_pattern_forbid([PKG_CHECK_MODULES])dnl
before invoking PKG_CHECK_MODULES for the first time so that the problem of the missing *.m4 file will be detected at the earliest possible time, i.e. when autoconf is about to generate a configure file with PKG_CHECK_MODULES unexpanded.
You could use some m4 code to print a lengthy error message if PKG_CHECK_MODULES is not defined. Something along the lines of (untested)
m4_ifndef([PKG_CHECK_MODULES], [dnl
m4_fatal([Could not find the PKG_CHECK_MODULES macro. Check that the pkg.m4 file is available and aclocal finds it (e.g. set ACLOCAL_PATH=/opt/local/share/aclocal).
])dnl
PKG_CHECK_MODULES([FOO], [foo])
Personally, I would go with m4_pattern_forbid and make sure OSX builds with homebrew work OOTB, and then document idiosyncrasies for building on rare and buggy systems like OSX with macports or SunOS without GNU tools in the INSTALL file.
Isn't it a bug in macports/OSX that aclocal there cannot find its *.m4 files? Shouldn't there be a dirlist file pointing to /opt/local/share/aclocal? Or perhaps they macports users should have an aclocal in their PATH which actually finds the macports macro files?
In any case, I would not consider it my build systems's job to fix a buggy system. You need to draw the line somewhere.
I am trying to setup watchman for the mac. As stated on the website, I need to install glibtool.
Can anyone provide a link to where I can download glibtool?
I need to be able to download it from its source and the only solution I can find is by using brew.
I do not want to use brew.
Thank you.
glibtool is "GNU Libtool". It is typically installed as libtool on most systems, but because macOS has its own libtool that has completely different functionality, it is usually installed as glibtool on macOS.
If you can't directly use homebrew to install it, you can duplicate the steps in its recipe, which you can find here: https://github.com/Homebrew/homebrew-core/blob/master/Formula/libtool.rb
For the sake of keeping this answer "working" even if homebrew goes away, the homepage for libtool is https://www.gnu.org/software/libtool/ and you can follow the instructions there for information on how to build and install it.
I've covered similar issues to Wez's answer from a MacPorts perspective; I'll go ahead and assume you can't use that either.
The latest stable version at this time is 2.4.6. Typical best practice is to make a directory, e.g., build in the top level of the source. Add the prefix: g, with --program-prefix=g, the top level installation directory --prefix=PREFIX, or specify more fine-grained installation directories options for bin, include, lib, and share directories.
> mkdir build
> cd build
> ../configure --prefix=/my/install/path --program-prefix=g
> make; make install
You now have glibtool and glibtoolize in $PREFIX/bin.
When compiling OpenSSL you can add 2 options (from INSTALL in the OpenSSL sources):
Configuration Options
---------------------
There are several options to ./config (or ./Configure) to customize
the build:
--prefix=DIR Install in DIR/bin, DIR/lib, DIR/include/openssl.
Configuration files used by OpenSSL will be in DIR/ssl
or the directory specified by --openssldir.
--openssldir=DIR Directory for OpenSSL files. If no prefix is specified,
the library files and binaries are also installed there.
When compiling other things that rely on OpenSSL or can be added in, an option will be available e.g. for tinc the --with-openssl is available. Should this point to the OpenSSL compilation option given to prefix or openssldir?
Note: I'm not compiling tinc, it's just the first thing I found with a clear example.
You could also run this command to identify in which directory it's installed to.
openssl version -d
which is the openssldir?
By default, the OpenSSL directory is /usr/local/ssl. If you perform a config without --prefix and without --openssldir, that's what you get by default.
Headers will be located in /usr/local/ssl/include/openssl and libraries will be located in /usr/local/ssl/lib.
You should prefer --openssldir, and avoid clever tricks like --prefix=/usr to overwrite a distro's copy of OpenSSL.
If you want to provide a more up to date version of OpenSSL, then look into building a custom package (Personal Package Archive (PPA)) as described at Override Distro Package with Custom Package?.
I'm working on OS X 10.8.5 at the moment. Here's what my /usr/local/ssl looks like (I use one additional directory path on --openssldir due to multiple OpenSSL builds):
$ ls /usr/local/ssl/
android-14 darwin macosx-x64
android-18 ios macosx-x86
the --with-openssl is available. Should this point to the OpenSSL compilation option given to prefix or openssldir?
Yes (but it depends). I've worked with a lot of projects that don't append include and lib properly.
Often times those libraries with --with-openssl are broken in subtle ways. For example, suppose you do the following:
export CFLAGS="-I/usr/local/ssl/include"
export LDFLAGS="/usr/local/ssl/lib"
./config ... --with-openssl=/usr/local/ssl
make
sudo make install
In the above, you will compile and link against the gear in /usr/local/ssl. Then, when you execute your program, it will link against the shared object in /usr/lib, and not the shared object in /usr/local/ssl/lib.
If your distro provides 0.9.8 and you have 1.0.1 in /usr/local/ssl, you will get a lot of unexplained crashes that make no sense. Be vigilant for this issue on OS X because Apple provides 0.9.8.
If you and the distro are both providing something binary compatible (like 1.0.1), then you will be missing functionality without explanation. For example, your version of OpenSSL will have TLS 1.1 and 1.2 enabled, while Ubuntu's version will have TLS 1.1 and 1.2 disabled (Ubuntu priot to 14 built with -DOPENSSL_NO_TLS1_2_CLIENT). And you'll wonder why you cannot connect using TLS 1.2.
If you are compiling on OS X, then you will find OS X silently discards your request to perform static linking (i.e., -Bstatic -lcrypto -lssl). The linker will always use the shared object if available (even on iOS, where its not allowed!). And it will silently ignore your -rpath, too. And forget LD_LIBRARY_PATH because its not honored (you have to use DYLD_LIBRARY_PATH per dyld(1)).
The easiest way to cope with OS X is to:
cd <project>
grep -R "-lcrypto" *
<replace all occurences of -lcrypto with /usr/local/ssl/lib/libcrypto.a>
grep -R "-lssl" *
<replace all occurences of -lssl with /usr/local/ssl/lib/libssl.a>
Archives are just like object files (they are a collection of object files), so you don't even need the -l.
When forcing static linking as above, you don't have to worry about the linker silently discarding your requests or doing things you don't expect. The same works on Linux, too. As a matter of fact, I always use my own version of OpenSSL, and I always do what I described because I got tired of fighting with the various tools (its not only ld, its Eclipse and friends, too).
When compiling other things that rely on OpenSSL, what they usually need is, in order to compile correctly, the openssl binaries - crypto and ssl (linux) - (for linkage) and the include files.
So, your best try would be to point the --prefix you used to install the openssl
https://wiki.openssl.org/index.php/Compilation_and_Installation#PREFIX_and_OPENSSLDIR
PREFIX and OPENSSLDIR
--prefix and --openssldir control the configuration of installed components. The behavior and interactions of --prefix and --openssldir are slightly different between OpenSSL 1.0.2 and below, and OpenSSL 1.1.0 and above.
The rule of thumb to use when you want something that "just works" for all recent versions of OpenSSL, including OpenSSL 1.0.2 and 1.1.0, is:
specify both --prefix and --openssldir
set --prefix and --openssldir to the same location
One word of caution is avoid --prefix=/usr when OpenSSL versions are not binary compatible. You will replace the distro's version of OpenSSL with your version of OpenSSL. It will most likely break everything, including the package management system.
I am a pretty good programmer and I have been working with Linux for 10+ years, but sometimes when trying to build programs from source I hit a brick wall. The current problem occurs when trying to build vlc, it claims that
/usr/bin/ld: cannot find -lvorbisdec
This happens quite frequently. The first thing I do is try
sudo apt-get install vorbisdec
But that doesn't always [ever] work. Next I try googling it, but 99 times out of a hundred I get something like this
vorbisdec...did you mean vorbisenc
I had a very similar problem tyring to install libgoom2. It doesn't help that sometimes the binaries you need (ie. goom) are in a preppended and appended file name (ie. xmms-libgoom2-dev)
Could someone fill in the missing step (s) with respect to how to properly go about installing programs from source:
`sudo apt-get install
???
give up installing
Most of libraries requested by ./configure can be installed with
sudo apt-get install lib[library name]-dev
For example, vorbisdec is available in libvorbis-dev package. Sometimes you have to specify version number, like libxcb-composite0-dev, liblua5.2-dev, or if you don't know version number libxcb-composite*-dev. If apt-get still can't find requried packages, you have to compile them from source, and then run
sudo ldconfig
EDIT: You can also use Tab button to list packages starting with libvorbis:
$ sudo apt-get install libvorbis[Tab]
libvorbis libvorbisfile3 libvorbis-ocaml
libvorbis0a libvorbisfile-ruby libvorbis-ocaml-dev
libvorbis-dbg libvorbisfile-ruby1.8 libvorbisspi-java
libvorbis-dev libvorbisidec1
libvorbisenc2 libvorbisidec-dev
ANOTHER EDIT: There is more :D
$ apt-cache search vorbis
libshout3 - MP3/Ogg Vorbis broadcast streaming library
libshout3-dev - MP3/Ogg Vorbis broadcast streaming library (development)
libtag1-dev - audio meta-data library - development files
libtag1-doc - audio meta-data library - API documentation
libtag1-vanilla - audio meta-data library - vanilla flavour
libtag1c2a - audio meta-data library
libtagc0 - audio meta-data library - C bindings
[...]
You can solve with
sudo apt-get install libvorbis-dev
When using homebrew to install graphviz, the script gets to the point of "Making install in tkstubs" and then throws the following fatal error:
In file included from tkStubLib.c:15:
/usr/include/tk.h:78:11: fatal error: 'X11/Xlib.h' file not found
#include <X11/Xlib.h>
I have installed XQuartz as X11 has been dropped in Mountain Lion, but I'm unsure if it is installed correctly. The location of Xlib.h is:
/opt/X11/include/X11/Xlib.h
There are also two symlinks to /opt/X11, they are:
/usr/X11
/usr/X11R6
Does this look like the correct setup to you? I've never dealt with X11 or XQuartz until yesterday.
Cheers.
After installing XQuartz you may add a symlink to your X11 installation folder by just entering
ln -s /opt/X11/include/X11 /usr/local/include/X11
in terminal. That will fix the problem as well without changing any ruby script.
You need to tell the tkstubs build (and possibly other bits in the package as well) to look for headers in /opt/X11/include; this is not on the standard include path.
Usually this is achieved by passing -I/opt/X11/include as an additional compiler flag, the method to do so is however dependent on the build system.
For reasonably modern configure scripts, the best approach is to pass it in the environment variable CPPFLAGS; if the package uses another build system or this doesn't work for another reason, then you need to look at the Makefile in the build directory.
You can enter in your shell before the compile/link (or brew) command:
export CPPFLAGS=-I/opt/X11/include
The export line will tell the compile/linker to look in /opt/X11/include for the X11 include files
Had the same issue and running this command on terminal
xcode-select --install
worked for me. Run this command after installing xQuartz.
If you need this to work in your CMake builds:
if(APPLE)
include_directories(AFTER "/opt/X11/include")
endif()
That worked well for me.
I got it to install by copying the x11 header file directory to the /opt/local/include directory. Probably not the best way to work around it but quick and easy.
I found this thread while trying to compile ffmpeg from source on OS X. I needed --enable-x11grab and the homebrew build does not support this option.
I had XQuartz installed already but I kept getting errors from ./configure: ERROR: Xlib not found. I thought the answers here would solve my problem, but they did not!
So, if anyone is ever in the same boat, my solution was this:
I opened up the generated config.log and found lots of errors referring to various includes and header files, including X11/Xlib.h - this is misleading. At the very bottom of the logfile was the key, pkg-config was complaining about looking for xbc.pc, and requested that it be put on the path. However, the error message that is displayed on the terminal says nothing about pkg-config or xbc!
The solution is to add to your PKG_CONFIG_PATH environment variable. Mine was nonexistent, so I just did export PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig/ (the folder where I found xbc.pc).
I reran configure and everything worked like a charm!
TL;DR: check config.log - don't trust the terminal output!
Since the make file is looking for X11/xlib.h i.e., it is looking for X11 folder in the current directory, one way to solve this problem is to simply copy the /opt/X11/include/X11 directory to the directory that contains make file.