- there were many easy merge conflicts
- cc-wrapper needed nontrivial changes
Many other problems might've been created by interaction of the branches,
but stdenv and a few other packages build fine now.
Attrnames and package names should be as close as possible to avoid confusion.
I took care not to confuse the two mpc things during the mass-replace,
so hopefully I suceeded (tarball still builds).
For now, we don't NATIVE_SYSTEM_HEADER_DIR because it breaks the
build. However, it points to Glibc in the Nix store (not /usr/include)
so it's kind of okay.
Even if using profiledbootstrap. This was unsafe before 4.8, and
then the documentation was not fixed on time.
The documentation got fixed here:
c763997f34
But the actual code was already fixed here:
5d2fca09d5
So this is safe both for GCC 4.8 and GCC 4.9.
(Or at least restore it to the same level as brokenness as before the
staging merge. I.e. it depends on gcc-apple, which doesn't build on
standard 10.9 systems.)
Having a separate lib64 is bad because it requires special-casing in
lots of places.
Previously done in e4a11b4d92424c42f61ee55cf505ac1217944f4a, which
apparently got lost going from 4.6 to 4.8.
Recent versions of Xcode don't install headers in /usr/include but
in a directory like
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include
So use that instead, falling back to /usr/include in case of an older
version of Xcode.
Somewhere the no-sys-dirs.patch got disabled, so gcc was looking in
/usr/local/include and /usr/lib. Since I can't fix the patch easily,
I've borrowed the --sysroot trick from clang-wrapper. This causes
builtin paths to be prefixed with /var/empty
(e.g. /var/empty/usr/lib), which don't exist.
This includes a lot of fixes for cross-building to Windows and Mac OS X
and could possibly fix things even for non-cross-builds, like for
example OpenSSL on Windows.
The main reason for merging this in 14.04 already is that we already
have runInWindowsVM in master and it doesn't work until we actually
cross-build Cygwin's setup binary as the upstream version is a fast
moving target which gets _overwritten_ on every new release.
Conflicts:
pkgs/top-level/all-packages.nix
The patch doesn't apply
This reverts commit 094eea8f6a34296760afb5e11d3b6e08575cb9c0, reversing
changes made to 552d66cd9e94f7e81043aa7becaaaa4b02e7ab6b.
On MinGW, we're passing these programs to the configure script, but this
obviously won't work for non-autoconf-based projects.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Both branches have quite a lot in common, so it's time for a merge and
do the cleanups with respect to both implementations and also generalize
both implementations as much as possible.
This also closes#1876.
Conflicts:
pkgs/development/interpreters/lua-5/5.2.nix
pkgs/development/libraries/SDL/default.nix
pkgs/development/libraries/glew/default.nix
pkgs/top-level/all-packages.nix
Cross-compiling stuff against Mac OS X's CoreFoundation won't work
without ObjC support, and we don't want to compile commandline utilities
only, right?
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Let's finally hook everything into the existing cross-building
infrastructure. We're using --with-sysroot instead of --with-headers
here, because the XCode SDK contains references to /usr/lib.
I've tried to patch those references, but unfortunately (at least with
install_name_tool) it isn't possible to change those refernces in stub
dylibs.
So after bugging @tpoechtrager with annoying questions (thanks again), I
think my initial approach (patching the SDK itself and/or regenerating
the dylib stubs) was way to complicated so I ended up with this
implementation.
Also, I've added a condition to binutilsCross to use cctools if the libc
is set to libSystem. This might need some cleanups someday, mainly to
figure out how to properly bridge cctools and binutils.
So, as an example on how to cross-compile GNU Hello to Darwin, you can
use something like this:
(import <nixpkgs> {
crossSystem = {
config = "x86_64-apple-darwin13";
arch = "x86_64";
libc = "libSystem";
platform = {};
};
}).hello.crossDrv
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Mingw(32) is rather poorly maintaned and has quite a lot of bugs. And
because our Windows cross builds were also poorly maintained and most of
the cross-tests were broken as well, I'm just taking this step and try
to switch to mingw-w64 for everything "cross Windows".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Specifically, we are trying to fix the following error seen on Hydra:
../../gcc-4.7.3/gcc/gengtype-lex.c:1:21: fatal error: bconfig.h: No such file or directory
The patch is taken from gcc's SVN revision 193691.
It's to separate from other changes coming from master.
Conflicts:
pkgs/development/libraries/glibc/2.18/common.nix (taking both changes)
pkgs/development/libraries/ncurses/5_4.nix (deleted)
Sometimes the build failes with:
In file included from ../../gcc-4.4.6/gcc/ada/seh_init.c:44:
../../gcc-4.4.6/gcc/system.h:418: error: conflicting types for 'strsignal'
/nix/store/6h129q168ahnl2nzw6azr239cba884ng-glibc-2.18/include/string.h:560: note: previous declaration of 'strsignal' was here
and sometimes it doesn't. Hopefully disabling parallel builds fixes
this.
http://hydra.nixos.org/build/7179481
GCC provides a number of libraries that are used by programs built by
GCC, in particular libgcc_s.so and libstdc++.so. This caused programs
that used these libraries to have a runtime dependency on all of GCC
(~77 MiB). Now they only depend on the "lib" output of GCC (~1.6
MiB).
With this and previous multiple-output improvements, closure sizes are
reduced a lot:
hello: 41 MiB -> 22 MiB
patchelf: 118 MiB -> 23 MiB
pan: 364 MiB -> 90 MiB
Without it, gcc builds for softfloat, and the glibc doesn't have support for
softfloat (it ends up requiring some gnu-soft.h file). We'll have to test if
this fixes the build of gcc or not, though.
Conflicts:
pkgs/development/compilers/gcc/4.6/default.nix
pkgs/development/compilers/gcc/4.7/default.nix
The 4.7 had some weird parameters added in crossAttrs; I've removed
them, but I don't understand where they come from.
This is for consistency with terminology in stdenv (and the terms
"hostDrv" and "buildDrv" are not very intuitive, even if they're
consistent with GNU terminology).
The gccinstall manual says that parallel building with a profiled
bootstrap is not supported. As we don't have much means of checking
if our profiled bootstrap with parallel build was good or bad, I
propose going to safe terrain.
Removing a gcc flag, --enable-version-specific-runtime-libs, that put gcc libs
in a speparate directory instead of /lib; this broke the installation of
libgcc_s.a for the case of "--enable-shared" in mingw-w64. And we already have all gccs in directories apart.
I also add the option --enable-fully-dynamic-string, which is used in the
prebuilt mingw64 toolchain; this way nixpkgs creates ABI-compatible binaries
with mingw64 upstream. (told by jon_y on irc ##mingw)
svn path=/nixpkgs/trunk/; revision=34242
shared libraries are wrong.
It should run "-lstdc++ -lsupc++" if libstdc++-6.dll is available, and instead it runs
"-lstdc++" and therefore lack symbols.
I think simply few people use shared gcc libs on mingw.
svn path=/nixpkgs/trunk/; revision=34225
be passed to derivations that need to apply patches.
* GCC 3.4 is now the default compiler (old GCC renamed to `gcc-3.3').
* The temporary GCCs built during the stdenvLinux bootstrap are now
built without C++ support and without profiling.
* Remove fixincl in GCC 3.4 to prevent a retained dependency on the
previous GCC.
* Always set $prefix in setup.sh, even when there is no configure
script.
svn path=/nixpkgs/trunk/; revision=1444
libgcc of the gcc being built, not the gcc building it.
* Only include a directory in the rpath of an executable/library if it
is actually used. Before, the `/lib' directory of every build input
was added to the rpath, causing many unnecessary retained
dependencies. For instance, Perl has a `/lib' directory, but most
applications whose build process uses Perl don't actually link
against Perl. (Also added a test for this.)
* After building glibc, remove glibcbug, to prevent a retained
dependency on gcc.
* Add a newline after `building X' in GNU Make.
svn path=/nixpkgs/trunk/; revision=911
* Make builders unexecutable by removing the hash-bang line and
execute permission.
* Convert calls to `derivation' to `mkDerivation'.
* Remove `system' and `stdenv' attributes from calls to
`mkDerivation'. These transformations were all done automatically,
so it is quite possible I broke stuff.
* Put the `mkDerivation' function in stdenv/generic.
svn path=/nixpkgs/trunk/; revision=874
whether the system header file directory actually exists (when
calling fixinc), so passing a non-existent directory no longer
works. Instead we make a empty dummy directory.
svn path=/nixpkgs/trunk/; revision=858
builders for typical Autoconf-style to be much shorten, e.g.,
. $stdenv/setup
genericBuild
The generic builder does lots of stuff automatically:
- Unpacks source archives specified by $src or $srcs (it knows about
gzip, bzip2, tar, zip, and unpacked source trees).
- Determines the source tree.
- Applies patches specified by $patches.
- Fixes libtool not to search for libraries in /lib etc.
- Runs `configure'.
- Runs `make'.
- Runs `make install'.
- Strips debug information from static libraries.
- Writes nested log information (in the format accepted by
`log2xml').
There are also lots of hooks and variables to customise the generic
builder. See `stdenv/generic/docs.txt'.
* Adapted the base packages (i.e., the ones used by stdenv) to use the
generic builder.
* We now use `curl' instead of `wget' to download files in `fetchurl'.
* Neither `curl' nor `wget' are part of stdenv. We shouldn't
encourage people to download stuff in builders (impure!).
* Updated some packages.
* `buildinputs' is now `buildInputs' (but the old name also works).
* `findInputs' in the setup script now prevents inputs from being
processed multiple times (which could happen, e.g., if an input was
a propagated input of several other inputs; this caused the size
variables like $PATH to blow up exponentially in the worst case).
* Patched GNU Make to write nested log information in the format
accepted by `log2xml'. Also, prior to writing the build command,
Make now writes a line `building X' to indicate what is being
built. This is unfortunately often obscured by the gigantic tool
invocations in many Makefiles. The actual build commands are marked
`unimportant' so that they don't clutter pages generated by
`log2html'.
svn path=/nixpkgs/trunk/; revision=845
