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/libextractor.so. 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/.
Should work using the standard instructions without problems.
Should work using the standard instructions without problems.
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.
No reports so far.
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.
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.)
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.
In the framework, the extract command line tool can be found at
/Library/Frameworks/Extractor.framework/Versions/Current/bin/extract
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.
// hello.c
#include <Extractor/extractor.h>
int
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
// 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 \ -lextractor
Notice the difference in the #include line.
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.