|
BuildSource
OverviewThe 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. IntroductionThis 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. QuickstartThis 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 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 Build ProcessExtractExtract sources from a source-distribution bundle. Releases are available from http://code.google.com/p/mp4v2 in the downloads 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 - ConfigureThe 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:
BuildThe 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. InstallThe following command will install MP4v2. make install make install-man Platform NotesMP4v2 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. Mac OS XBuilding 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:
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. Default BinariesThe 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 Release BinariesThe 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 Developer BinariesThe 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 Universal Binaries - all architecturesThe 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 Universal Binaries - selected architecturesThe 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 LinuxBuilding 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:
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. Default BinariesThe 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 Release BinariesThe 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 Developer BinariesThe 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 Bi-arch compilationThe 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. FreeBSDBuilding on FreeBSD is supported. The following are the recommended specifications for this platform; but is not necessarily the only configuration that is possible:
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. Default BinariesThe 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 Release BinariesThe 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 Developer BinariesThe 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 Bi-arch compilationThe 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. SolarisBuilding on Solaris is supported. The following are the recommended specifications for this platform; but is not necessarily the only configuration that is possible:
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. Default BinariesThe 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 Release BinariesThe 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 Developer BinariesThe 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 Bi-arch compilationThe 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. CygwinBuilding on Cygwin is supported. The following are the recommended specifications for this platform; but is not necessarily the only configuration that is possible:
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 Default BinariesThe 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 Release BinariesThe 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 Developer BinariesThe 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 WindowsNative 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:
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. | ||||||||||||||||||
► Sign in to add a comment