You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
562 lines
18 KiB
562 lines
18 KiB
MP4v2 2.0.0 Building the Source
|
|
*******************************
|
|
|
|
Table of Contents
|
|
*****************
|
|
|
|
1 Overview
|
|
2 Introduction
|
|
3 Quickstart
|
|
4 Build Process
|
|
4.1 Extract
|
|
4.2 Configure
|
|
4.3 Build
|
|
4.4 Install
|
|
5 Platform Notes
|
|
5.1 Mac OS X
|
|
5.1.1 Default Binaries
|
|
5.1.2 Release Binaries
|
|
5.1.3 Developer Binaries
|
|
5.1.4 Universal Binaries - all architectures
|
|
5.1.5 Universal Binaries - selected architectures
|
|
5.2 Linux
|
|
5.2.1 Default Binaries
|
|
5.2.2 Release Binaries
|
|
5.2.3 Developer Binaries
|
|
5.2.4 Bi-arch compilation
|
|
5.3 FreeBSD
|
|
5.3.1 Default Binaries
|
|
5.3.2 Release Binaries
|
|
5.3.3 Developer Binaries
|
|
5.3.4 Bi-arch compilation
|
|
5.4 Solaris
|
|
5.4.1 Default Binaries
|
|
5.4.2 Release Binaries
|
|
5.4.3 Developer Binaries
|
|
5.4.4 Bi-arch compilation
|
|
5.5 Cygwin
|
|
5.5.1 Default Binaries
|
|
5.5.2 Release Binaries
|
|
5.5.3 Developer Binaries
|
|
5.6 Windows
|
|
|
|
|
|
1 Overview
|
|
**********
|
|
|
|
The documented and supported method to build MP4v2 uses the GNU build
|
|
system (also known as the Autotools). You must first obtain the sources
|
|
by either downloading and extracting the source-distribution bundle or
|
|
working directly MP4v2's Subversion repository. We have build documents
|
|
for both methods, but unless you are a member of the MP4v2 project, you
|
|
are strongly encouraged to use the source-distribution method.
|
|
|
|
On other supported platforms which lack Autotools we provide an
|
|
alternative method for building the software. Please see the
|
|
appropriate platform section.
|
|
|
|
2 Introduction
|
|
**************
|
|
|
|
This document describes the recommended process to build MP4v2 from a
|
|
source-distribution bundle. This process is a subset of the process to
|
|
build directly from the project's repository. If you are interested in
|
|
building from the repository then this document is not for you.
|
|
|
|
3 Quickstart
|
|
************
|
|
|
|
This chapter is for the impatient or those just looking for a quick
|
|
summary of all the commands used in a typical build. You may skip this
|
|
summary and jump to *note Build Process::.
|
|
|
|
tar xf mp4v2-2.0.0.tar.bz2
|
|
cd mp4v2-2.0.0/
|
|
rm -fr build/
|
|
mkdir build/
|
|
cd build/
|
|
../configure
|
|
make
|
|
make install
|
|
make install-man
|
|
|
|
4 Build Process
|
|
***************
|
|
|
|
4.1 Extract
|
|
===========
|
|
|
|
Extract sources from a source-distribution bundle. Releases are
|
|
available from `http://code.google.com/p/mp4v2' in the downloads
|
|
(http://code.google.com/p/mp4v2/downloads/list) section.
|
|
|
|
tar xf mp4v2-2.0.0.tar.bz2
|
|
cd mp4v2-2.0.0/
|
|
|
|
Older versions of `tar' may not automatically uncompress the bundle, so
|
|
you might have to either enter additional flags manually, or first
|
|
decompress the bundle before extracting. Some possible command
|
|
variations for uncompressing a `bz2' file:
|
|
|
|
tar xjf mp4v2-2.0.0.tar.bz2
|
|
bunzip2 -c mp4v2-2.0.0.tar.bz2 | tar xf -
|
|
bzcat mp4v2-2.0.0.tar.bz2 | tar xf -
|
|
|
|
And for a `gz' file:
|
|
|
|
tar xzf mp4v2-2.0.0.tar.gz
|
|
gunzip -c mp4v2-2.0.0.tar.gz | tar xf -
|
|
gzcat mp4v2-2.0.0.tar.gz | tar xf -
|
|
|
|
4.2 Configure
|
|
=============
|
|
|
|
The following command configures the project for a build. It is highly
|
|
recommended that you invoke configure from an empty directory.
|
|
|
|
rm -fr build/
|
|
mkdir build/
|
|
cd build/
|
|
../configure
|
|
|
|
Please see `INSTALL' for details on configure usage, and standard
|
|
options. Additionally, the following custom options have been added to
|
|
`configure':
|
|
|
|
`--disable-debug'
|
|
Do not generate debug information. Do not direct compiler to
|
|
generate debugging information. By default the compiler will
|
|
generate debug information if the platform supports it.
|
|
|
|
`--disable-optimize'
|
|
Do not optimize. Do not direct compiler to optimize code. By
|
|
default compiler optimization is enabled if the platform supports
|
|
it.
|
|
|
|
`--disable-fvisibility'
|
|
Do not set default ELF symbol visibility. By default configure
|
|
attempts to detect if the compiler supports this feature. However
|
|
on some platforms detecting incompatibilty of this feature might
|
|
not be accurate in which case this option should be given.
|
|
|
|
`--disable-gch'
|
|
By default certain platforms are marked to use GCC precompiled
|
|
headers. Generally this greatly decrease build times but may
|
|
require more diligence for iterative development; that is to say
|
|
dependencies may not properly be tracked and more frequent `make
|
|
clean' may be required when headers are changed. Use this option
|
|
to disable GCC precompiled headers.
|
|
|
|
`--disable-largefile'
|
|
On some 32-bit platforms or configurations it might be desirable
|
|
to build without largefile (LFS) support. By default configure
|
|
attempts to detect formal LFS support and enables it if found.
|
|
|
|
`--disable-util'
|
|
Do not build/install utilities. This is convenience option for
|
|
users who desire to skip building the utilities (eg. command-line
|
|
executables) which are enabled by default.
|
|
|
|
`--enable-bi=ARCH'
|
|
On bi-arch capable platforms it is possible to generate 32 or 64
|
|
bit code. This is supported by adding arguments `-m32' or `-m64',
|
|
respectively, when compiling or linking. Use this option to
|
|
override the platform-specific default.
|
|
|
|
`--enable-ub[=ARCHS]'
|
|
On OSX systems it is possible to generate universal binaries. This
|
|
is supported by adding one or more argument patterns `-arch ARCH'
|
|
when compiling or linking. Use this option to either target an
|
|
architecture different from the platform default, or to produce
|
|
universal binaries.
|
|
|
|
`--enable-dependency-tracking'
|
|
Enable automatic dependency tracking for include-files. By default
|
|
this feature is disabled.
|
|
|
|
|
|
4.3 Build
|
|
=========
|
|
|
|
The following command will build MP4v2.
|
|
|
|
make
|
|
|
|
On some platforms `make' refers to a BSD-flavor of make which is not
|
|
compatible with this project. Check if `gmake' is installed, and if it
|
|
is, substitute `gmake' wherever you may see `make' in this document.
|
|
Otherwise you will need to install GNU make package version 3.81 or
|
|
higher. Lower versions might work.
|
|
|
|
4.4 Install
|
|
===========
|
|
|
|
The following command will install MP4v2.
|
|
|
|
make install
|
|
make install-man
|
|
|
|
5 Platform Notes
|
|
****************
|
|
|
|
MP4v2 builds on many unix-style platforms, also commonly referred to as
|
|
posix-style systems. Building on Mac OS X, Linux, FreeBSD, Solaris,
|
|
Cygwin, Windows are known to work.
|
|
|
|
Similar platforms should also work. Please see the following platform
|
|
specific notes for instructions on commonly used options for various
|
|
platforms.
|
|
|
|
5.1 Mac OS X
|
|
============
|
|
|
|
Building on Mac OS X is well supported as it is used by maintainers of
|
|
this project. The following are the recommended specifications for this
|
|
platform; but is not necessarily the only configuration that is
|
|
possible:
|
|
|
|
* Mac Intel hardware
|
|
|
|
* Mac OS X 10.5.7
|
|
|
|
* Xcode-3.1.2
|
|
|
|
* gcc 4.0.1 (Apple Inc. build 5493)
|
|
|
|
* gcc 4.2.1 (Apple Inc. build 5570)
|
|
|
|
Note: It is recommended to use the platform distribution's bundled
|
|
compiler for maximum C++ compatibility. If you build with a custom
|
|
compiler it will likely introduce non-standard runtime
|
|
requirements for your users. There are of course many valid
|
|
reasons to build with unbundled compilers, but be aware that is
|
|
generally unsupported and left as an exercise to the reader.
|
|
|
|
5.1.1 Default Binaries
|
|
----------------------
|
|
|
|
The preferred method to produce default binaries is to run configure
|
|
without any options which will compile with debug+optimize and produce
|
|
static+shared libraries and dynamic executables.
|
|
|
|
../configure
|
|
|
|
5.1.2 Release Binaries
|
|
----------------------
|
|
|
|
The preferred method to produce binaries suitable for releases, (ie.
|
|
which does not contain debug information) is to pass the following to
|
|
configure:
|
|
|
|
../configure --disable-debug
|
|
|
|
5.1.3 Developer Binaries
|
|
------------------------
|
|
|
|
The preferred method to produce binaries suitable for development is to
|
|
pass the following to configure. Default Binaries will work, however
|
|
for the best debugging experience we recommend no optimize and no
|
|
static libraries.
|
|
|
|
../configure --disable-optimize --disable-static
|
|
|
|
5.1.4 Universal Binaries - all architectures
|
|
--------------------------------------------
|
|
|
|
The preferred method to produce universal binaries for all supported
|
|
architectures is to pass the following option to configure. As of this
|
|
writing, architectures { i386, x86_64, ppc, ppc64 } are built.
|
|
|
|
../configure --enable-ub
|
|
|
|
5.1.5 Universal Binaries - selected architectures
|
|
-------------------------------------------------
|
|
|
|
The preferred method to produce universal binaries for selected
|
|
architectures is to specify a comma-delimited list specifying the
|
|
desired architecture identifiers. Passing the following option will
|
|
produce universal binaries for architectures { i386, x86_64 }.
|
|
|
|
../configure --enable-ub=i386,x86_64
|
|
|
|
5.2 Linux
|
|
=========
|
|
|
|
Building on Linux is well supported as it is used by maintainers of
|
|
this project. The following are the recommended specifications for this
|
|
platform; but is not necessarily the only configuration that is
|
|
possible:
|
|
|
|
* Intel 32-bit or 64-bit hardware
|
|
|
|
* Fedora 10, gcc 4.3.2
|
|
|
|
* gcc 3.4.0 or higher is reported to work
|
|
|
|
Note: It is recommended to use the platform distribution's bundled
|
|
compiler for maximum C++ compatibility. If you build with a custom
|
|
compiler it will likely introduce non-standard runtime
|
|
requirements for your users. There are of course many valid
|
|
reasons to build with unbundled compilers, but be aware that is
|
|
generally unsupported and left as an exercise to the reader.
|
|
|
|
5.2.1 Default Binaries
|
|
----------------------
|
|
|
|
The preferred method to produce default binaries is to run configure
|
|
without any options which will compile with debug+optimize and produce
|
|
static+shared libraries and dynamic executables.
|
|
|
|
../configure
|
|
|
|
5.2.2 Release Binaries
|
|
----------------------
|
|
|
|
The preferred method to produce binaries suitable for releases, (ie.
|
|
which does not contain debug information) is to pass the following to
|
|
configure:
|
|
|
|
../configure --disable-debug
|
|
|
|
5.2.3 Developer Binaries
|
|
------------------------
|
|
|
|
The preferred method to produce binaries suitable for development is to
|
|
pass the following to configure. Default Binaries will work, however
|
|
for the best debugging experience we recommend no optimize and no
|
|
static libraries.
|
|
|
|
../configure --disable-optimize --disable-static
|
|
|
|
5.2.4 Bi-arch compilation
|
|
-------------------------
|
|
|
|
The preferred method to produce a bi-arch binary is to specify the
|
|
target (eg. 32-bit) with the following option to configure. This
|
|
example will produce a 32-bit binary if compiling on a platform which
|
|
defaults to producing 64-bit binaries. The inverse is also possible.
|
|
|
|
../configure --enable-bi=32
|
|
|
|
Warning: Currently bi-arch cross-compilation is not supported due
|
|
to a bug with libtool which fails miserably during linking.
|
|
|
|
5.3 FreeBSD
|
|
===========
|
|
|
|
Building on FreeBSD is supported. The following are the recommended
|
|
specifications for this platform; but is not necessarily the only
|
|
configuration that is possible:
|
|
|
|
* Intel 32-bit or 64-bit hardware
|
|
|
|
* FreeBSD 7.0 Release, gcc 4.2.1
|
|
|
|
* gcc 3.4.0 or higher is reported to work
|
|
|
|
Note: It is recommended to use the platform distribution's bundled
|
|
compiler for maximum C++ compatibility. If you build with a custom
|
|
compiler it will likely introduce non-standard runtime
|
|
requirements for your users. There are of course many valid
|
|
reasons to build with unbundled compilers, but be aware that is
|
|
generally unsupported and left as an exercise to the reader.
|
|
|
|
5.3.1 Default Binaries
|
|
----------------------
|
|
|
|
The preferred method to produce default binaries is to run configure
|
|
without any options which will compile with debug+optimize and produce
|
|
static+shared libraries and dynamic executables.
|
|
|
|
../configure
|
|
|
|
5.3.2 Release Binaries
|
|
----------------------
|
|
|
|
The preferred method to produce binaries suitable for releases, (ie.
|
|
which does not contain debug information) is to pass the following to
|
|
configure:
|
|
|
|
../configure --disable-debug
|
|
|
|
5.3.3 Developer Binaries
|
|
------------------------
|
|
|
|
The preferred method to produce binaries suitable for development is to
|
|
pass the following to configure. Default Binaries will work, however
|
|
for the best debugging experience we recommend no optimize and no
|
|
static libraries.
|
|
|
|
../configure --disable-optimize --disable-static
|
|
|
|
5.3.4 Bi-arch compilation
|
|
-------------------------
|
|
|
|
The preferred method to produce a bi-arch binary is to specify the
|
|
target (eg. 32-bit) with the following option to configure. This
|
|
example will produce a 32-bit binary if compiling on a platform which
|
|
defaults to producing 64-bit binaries. The inverse is also possible.
|
|
|
|
../configure --enable-bi=32
|
|
|
|
Warning: Currently bi-arch cross-compilation is not supported due
|
|
to a bug with libtool which fails miserably during linking.
|
|
|
|
5.4 Solaris
|
|
===========
|
|
|
|
Building on Solaris is supported. The following are the recommended
|
|
specifications for this platform; but is not necessarily the only
|
|
configuration that is possible:
|
|
|
|
* Intel 32-bit or 64-bit hardware
|
|
|
|
* Solaris 10u6, gcc 3.4.3
|
|
|
|
* gcc 3.4.0 or higher is reported to work
|
|
|
|
Note: It is recommended to use the platform distribution's bundled
|
|
compiler for maximum C++ compatibility. If you build with a custom
|
|
compiler it will likely introduce non-standard runtime
|
|
requirements for your users. There are of course many valid
|
|
reasons to build with unbundled compilers, but be aware that is
|
|
generally unsupported and left as an exercise to the reader.
|
|
|
|
Note: Solaris does not (yet) really bundle a compiler. The
|
|
recommendation is to use the companion-disk compiler for maximum
|
|
C++ runtime compatibility. It is usually found in `/usr/sfw/bin'.
|
|
|
|
5.4.1 Default Binaries
|
|
----------------------
|
|
|
|
The preferred method to produce default binaries is to run configure
|
|
without any options which will compile with debug+optimize and produce
|
|
static+shared libraries and dynamic executables.
|
|
|
|
../configure
|
|
|
|
5.4.2 Release Binaries
|
|
----------------------
|
|
|
|
The preferred method to produce binaries suitable for releases, (ie.
|
|
which does not contain debug information) is to pass the following to
|
|
configure:
|
|
|
|
../configure --disable-debug
|
|
|
|
5.4.3 Developer Binaries
|
|
------------------------
|
|
|
|
The preferred method to produce binaries suitable for development is to
|
|
pass the following to configure. Default Binaries will work, however
|
|
for the best debugging experience we recommend no optimize and no
|
|
static libraries.
|
|
|
|
../configure --disable-optimize --disable-static
|
|
|
|
5.4.4 Bi-arch compilation
|
|
-------------------------
|
|
|
|
The preferred method to produce a bi-arch binary is to specify the
|
|
target (eg. 32-bit) with the following option to configure. This
|
|
example will produce a 32-bit binary if compiling on a platform which
|
|
defaults to producing 64-bit binaries. The inverse is also possible.
|
|
|
|
../configure --enable-bi=32
|
|
|
|
Warning: Currently bi-arch cross-compilation is not supported due
|
|
to a bug with libtool which fails miserably during linking.
|
|
|
|
5.5 Cygwin
|
|
==========
|
|
|
|
Building on Cygwin is supported. The following are the recommended
|
|
specifications for this platform; but is not necessarily the only
|
|
configuration that is possible:
|
|
|
|
* Intel 32-bit or 64-bit hardware
|
|
|
|
* Cygwin, gcc 4.3.2
|
|
|
|
* gcc 3.4.0 or higher is reported to work
|
|
|
|
Note: As of this writing, Cygwin has available to it several
|
|
versions of gcc; only one of which may be found and used in the
|
|
path as `gcc' and `g++'. Configure will thus find what is probably
|
|
the older more stable version of gcc in a typical Cygwin
|
|
environment. If you desire to build with the newer gcc, it is
|
|
found in the path as `gcc-4' and `g++-4' respectively and you must
|
|
indicate to configure the desired versions. Defining the following
|
|
variables beforing running configure should do the trick:
|
|
|
|
setenv CC gcc-4
|
|
setenv CXX gcc-4
|
|
../configure
|
|
|
|
5.5.1 Default Binaries
|
|
----------------------
|
|
|
|
The preferred method to produce default binaries is to run configure
|
|
without any options which will compile with debug+optimize and produce
|
|
static+shared libraries and dynamic executables.
|
|
|
|
../configure
|
|
|
|
5.5.2 Release Binaries
|
|
----------------------
|
|
|
|
The preferred method to produce binaries suitable for releases, (ie.
|
|
which does not contain debug information) is to pass the following to
|
|
configure:
|
|
|
|
../configure --disable-debug
|
|
|
|
5.5.3 Developer Binaries
|
|
------------------------
|
|
|
|
The preferred method to produce binaries suitable for development is to
|
|
pass the following to configure. Default Binaries will work, however
|
|
for the best debugging experience we recommend no optimize and no
|
|
static libraries.
|
|
|
|
../configure --disable-optimize --disable-static
|
|
|
|
5.6 Windows
|
|
===========
|
|
|
|
Native builds on Windows is supported via Microsoft's Visual Studio
|
|
package. Both the commercial version and free version (express) are
|
|
known to work. The following are the recommended specifications for
|
|
this platform; but is not necessarily the only configuration that is
|
|
possible:
|
|
|
|
* Intel 32-bit or 64-bit hardware
|
|
|
|
* Windows 2000 or higher, Visual Studio 9.0 (aka. Visual Studio 2008)
|
|
|
|
* Visual Studio 9.0 Express is reported to work
|
|
|
|
Only 32-bit binaries are targeted, and win32-API is set to Windows 2000
|
|
or higher. Older versions of Windows, or win32-API are not supported.
|
|
|
|
MP4v2 has directory `vstudio9.0/' which contains the necessary
|
|
solution+project files to produce a basic build of libmp4v2's DLL and
|
|
several command-line executables. Enabling things such as debugging,
|
|
optimization, etc, are all left as an exercise to the user.
|
|
|
|
Warning: Project meta-data is stored in header `project.h'. A
|
|
proper source distribution is built using autotools and generates
|
|
`TOP/include/mp4v2/project.h' correctly, which is then bundled
|
|
with our source distribution. This is adequate for building on the
|
|
Windows platform.
|
|
|
|
However, if you are building from the repository, be warned that
|
|
there is no method to automatically generate `project.h' on
|
|
Windows. Instead, we periodically checkin a copy of this file
|
|
(generated using autotools) as
|
|
`vstudio9.0/include/mp4v2/project.h' which may from time to time
|
|
get out of date. If it is significantly out of date, you should
|
|
find the latest source distribution and copy the `project.h' from
|
|
there.
|
|
|