Redland's use of the pre-processor symbol SQLITE_API collides with a
symbol of the same name in sqlite 3.6.19. Patching the source code to
use REDLAND_SQLITE_API instead works around the problem.
svn path=/nixpkgs/trunk/; revision=18100
Sqlite has a build mode called "amalgamation" that gathers all 90+ source code
files into a single sqlite3.c file before compiling the library. Building
sqlite this way reportedly gives a 5-10% performance gain because the compiler
can perform more sophisticated optimizations.
svn path=/nixpkgs/trunk/; revision=18092
The new version requires Tcl at build time in order to construct sqlite3.h,
even when the --without-tcl option is passed to configure. That feels odd
because the sqlite web site does advertise "no dependencies", but then it's
probably not a big deal either. The build of the Tcl plugin for sqlite is still
disabled, so there is no run-time dependency.
svn path=/nixpkgs/trunk/; revision=18091
propagatedBuildInputs, because those inputs are required by the *.pc
or *.la files of the package:
- If a *.pc file references a non-propagated input, then Gnome
packages have the bad tendency to silently ignore this problem in
configure scripts - the failure of a command like `pkg-config
--cflags foo' will be ignored if a dependency of foo.pc is
missing, so no flags will be added, and the build will fail later
on a missing header or library.
- If a *.la file references a non-propagated input, the build will
also fail, because Libtool will add library dependencies that it
cannot find. (Arguably *.la files should never reference packages
that aren't in the corresponding *.pc file, but they do it
anyway).
By setting the propagatedBuildInputs properly, it should be possible
to get rid of all the NIX_CFLAGS_COMPILE / NIX_LDFLAGS hacks in the
Gnome expressions.
svn path=/nixpkgs/branches/xorg-7.5/; revision=18084
configuration directory so that users on other distributions don't
need to set $FONTCONFIG_FILE (NIXPKGS-29). Also use
/var/cache/fontconfig for the cache to prevent programs run by root
from writing into the Nix store.
svn path=/nixpkgs/branches/xorg-7.5/; revision=18021
patent-encumbered hinting and sub-pixel rendering. It's disabled by
default. (Or should it be enabled by default?)
svn path=/nixpkgs/branches/xorg-7.5/; revision=18019
development/libraries/{glib,gtk+,pango,atk,...}. Done for glib/gtk+
1.2. Also deleted some obsolete, unused versions (gtkLibs 2.10,
2.12, and 2.14).
svn path=/nixpkgs/trunk/; revision=17992
* Dropped "nolongdouble.patch". The patch no longer applies to Python 2.6, and
apparently isn't required anymore either.
* Added access to native Darwin arch utility. Python tries to run 'arch' in
the configure stage, but that binary reside in /usr/bin. To make it
available to the expression, the small wrapper darwinArchUtility is added as
a buildInput if appropriate.
* Don't pass --enable-shared. The build fails if we try to enable building of
shared libraries, apparently because some required libraries aren't linked,
i.e. the linker call isn't right.
TODO:
* Figure out how to enable shared linking.
* The resulting binary on Darwin seem to lack the binascii module.
svn path=/nixpkgs/trunk/; revision=17894
The build succeeds on i686-linux. Other platforms look good, too,
because there were hardly any changes necessary to update the expression
from 2.5.
svn path=/nixpkgs/trunk/; revision=17889
Updating libgpod
Making gtkpod accept 'ogg' files, and made it convert them well to mp3, if 'lame'
and oggdec is in path. It should better reference lame and libvorbis store path
files.
svn path=/nixpkgs/trunk/; revision=17888
The initial MacOS X binaries have been linked to libgmp.dylib using some
mad path in /opt that's now hard-coded into the program. Consequently,
$DYLD_LIBRARY_PATH must contain the place where libgmp really is for
those binaries to run correctly. Tested on i386-apple-darwin9.7.0.
svn path=/nixpkgs/trunk/; revision=17873
On MacOS X, we used to use the native perl interpreter from /usr/bin.
Unfortunately, that interpreter fails to build a number of packages
(Subversion, Git, etc. ...), because it assumes knowledge about the
underlying C compiler that is not valid for the compiler used by Nix.
For example, /usr/bin/perl assumes that the compiler can build binaries
for both the ppc and the x86 architecture. /usr/bin/gcc can do that, but
the gcc from Nix can't.
The solution is to compile Perl 5.10 in Nix so that the ./configure
phase can properly detect the system's capabilities. However, note that
the resulting binary is impure: it will find headers in /usr/include and
libraries in /usr/lib. In this respect, the Nix-compiled perl binary is
no different than the native one in /usr/bin -- it's just configured
more accurately.
svn path=/nixpkgs/trunk/; revision=17870
