Next: , Previous: Introduction, Up: Top

2 Preparation

This chapter first describes the general build instructions that should apply to all systems. Specific instructions for known problems for particular platforms are then described in individual sections afterwards.

Compiling GNU libextractor follows the standard GNU autotools build process using configure and make. For details on the GNU autotools build process, read the INSTALL file and query ./configure --help for additional options.

GNU libextractor has various dependencies, most of which are optional. Instead of specifying the names of the software packages, we will give the list in terms of the names of the respective Debian (wheezy) packages that should be installed.

You absolutely need:

Recommended dependencies are:

For Subversion access and compilation one also needs:

Please notify us if we missed some dependencies (note that the list is supposed to only list direct dependencies, not transitive dependencies).

Once you have compiled and installed GNU libextractor, you should have a file extractor.h installed in your include/ directory. This file should be the starting point for your C and C++ development with GNU libextractor. The build process also installs the extract binary and man pages for extract and GNU libextractor. The extract man page documents the extract tool. The GNU libextractor man page gives a brief summary of the C API for GNU libextractor.

When you install GNU libextractor, various plugins will be installed in the lib/libextractor/ directory. The main library will be installed as lib/ Note that GNU libextractor will attempt to find the plugins relative to the path of the main library. Consequently, a package manager can move the library and its plugins to a different location later — as long as the relative path between the main library and the plugins is preserved. As a method of last resort, the user can specify an environment variable LIBEXTRACTOR_PREFIX. If GNU libextractor cannot locate a plugin, it will look in LIBEXTRACTOR_PREFIX/lib/libextractor/.

2.1 Installation on GNU/Linux

Should work using the standard instructions without problems.

2.2 Installation on FreeBSD

Should work using the standard instructions without problems.

2.3 Installation on OpenBSD

OpenBSD 3.8 also doesn't have CODESET in langinfo.h. CODESET is used in GNU libextractor in about three places. This causes problems during compilation.

2.4 Installation on NetBSD

No reports so far.

2.5 Installation using MinGW

Linking -lstdc++ with the provided libtool fails on Cygwin, this is a problem with libtool, there is unfortunately no flag to tell libtool how to do its job on Cygwin and it seems that it cannot be the default to set the library check to 'pass_all'. Patching libtool may help.

Note: this is a rather dated report and may no longer apply.

2.6 Installation on OS X

libextractor has two installation methods on Mac OS X: it can be installed as a Mac OS X framework or with the standard ./configure; make; make install shell commands. The framework package is self-contained, but currently omits some of the extractor plugins that can be compiled in if libextractor is installed with ./configure; make; make install (provided that the required dependencies exist.)

2.6.1 Installing and uninstalling the framework

The binary framework is distributed as a disk image (Extractor-x.x.xx.dmg). Installation is done by opening the disk image and clicking Extractor.pkg inside it. The Mac OS X installer application will then run. The framework is installed to the root volume's /Library/Frameworks folder and installing will require admin privileges.

The framework can be uninstalled by dragging
/Library/Frameworks/Extractor.framework to the Trash.

2.6.2 Using the framework

In the framework, the extract command line tool can be found at

The framework can be used in software projects as a framework or as a dynamic library.

When using the framework as a dynamic library in projects using autotools, one would most likely want to add
"-I/Library/Frameworks/Extractor.framework/Versions/Current/include" to CPPFLAGS and
"-L/Library/Frameworks/Extractor.framework/Versions/Current/lib" to LDFLAGS.

2.6.3 Example for using the framework

     // hello.c
     #include <Extractor/extractor.h>
     main (int argc, char **argv)
       struct EXTRACTOR_PluginList *el;
       el = EXTRACTOR_plugin_load_defaults (EXTRACTOR_OPTION_DEFAULT_POLICY);
       // ...
       EXTRACTOR_plugin_remove_all (el);
       return 0;

You can then compile the example using

$ gcc -o hello hello.c -framework Extractor

2.6.4 Example for using the dynamic library

     // hello.c
     #include <extractor.h>
     int main()
       struct EXTRACTOR_PluginList *el;
       el = EXTRACTOR_plugin_load_defaults (EXTRACTOR_OPTION_DEFAULT_POLICY);
       // ...
       EXTRACTOR_plugin_remove_all (el);
       return 0;

You can then compile the example using

$ gcc -I/Library/Frameworks/Extractor.framework/Versions/Current/include \
  -o hello hello.c \
  -L/Library/Frameworks/Extractor.framework/Versions/Current/lib \

Notice the difference in the #include line.

2.7 Note to package maintainers

The suggested way to package GNU libextractor is to split it into roughly the following binary packages:

This would enable minimal installations (i.e. for embedded systems) to not include any plugins, as well as moderate-size installations (that do not trigger GTK and X11) for systems that have limited resources. Right now, the MP4 plugin is experimental and does nothing and should thus never be included at all. The gstreamer plugin is experimental but largely works with the correct version of gstreamer and can thus be packaged (especially if the dependency is available on the target system) but should probably not be part of libextractor-plugins-all.