the target libraries, as 4.3.4
I trigger the breaking build using uclibc, instead of glibc, and then the
mixture of CPP getting the build glibc headers, and CC getting the uclibc
headers, makes the problem evident.
In 4.3.4 it only affected libmudflap. In 4.4.2, it affects libmudflap and
libstdc++.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18850
through libtool.
I found a make variable holding flags that will not be trimmed by libtool:
FLAGS_FOR_TARGET.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18846
* xfsprogs: don't use shared libraries because libxfs.so isn't
installed for some reason, so mkfs.xfs doesn't work.
svn path=/nixpkgs/trunk/; revision=18842
coreutils 7.6, which did not build well. The newer coreutils 8.1 work perfectly,
and we don't need to rely in older versions.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18836
we can't build easily with them gcc-4.4 natively, because of a bug in the ld of the
previous bootstrap-tools.
I updated the unpack script to include the new gcc-4.4 libraries *ppl*.so in patchelfing.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18835
Dealt with the gcc 4.4 expression for it to work well for a native and a cross
compiler, adding a pair of patches to get the job done without much side
effects. One (libtool problems on -B) comes from the gcc 4.3 expression, while
the other fixes a bug already fixed in gcc 4.4.3.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18833
between uclibc/glibc still.
I started the renaming from glibc to libc regarding the cross-toolchain, but I
still have to finish.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18801
- Upgraded KDE to 4.3.4
- Upgraded KOffice to 2.1.0
- Upgraded Konversation to 1.2.1
- Upgraded kdesvn to 1.4.1
- Upgraded ktorrent to 3.3.1
svn path=/nixpkgs/trunk/; revision=18751
(dynamic libraries of ppl and cloogppl) into the package.
We need newer binutils in the bootstrap-tools for the armv5tel in order to
be able to build gcc 4.4 from them.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18747
I also set the 'glibcLocales' top-level attribute point to 2.11 instead of
2.10, to match that of the 'glibc' top-level attribute.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18746
used to cross-compile, because of some bug in 4.4.2 I think. This bug does not
allow building a cross-compiler without libc:
http://archives.free.net.ph/message/20091119.140407.040d3c5b.en.html
Maybe we should wait for 4.4.3 or stay with 4.4.1 cross compiling. By now I
will keep 4.3.4 on cross compilation.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18730
Fixing the glibc-2.10 expression on cross-builds (which should be ported to
the glibc-2.11 expression once we get "ports" there)
Making kde3 and cyrus-sasl use gcc-4.3, because the strictness in gcc-4.4 does
not allow them build.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18706
when I commited it, so it has been a expression that only worked for me, I think,
because I had done the proper fetchcvs previously.
svn path=/nixpkgs/trunk/; revision=18699
- I still have not understood why it worked without this fix before, and I think
this has been triggered by the gcc-4.4, but I have not investigated this much. I
went with the trivial fix.
Adding a glibc-2.10.1 expression, because the glibc-2.11 still does not have
a ports release, so it cannot be used in arm. I'm using it only in native
compilation by now.
Making the default glibc to be 2.10 instead of 2.11 in armv5tel-linux.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18688
renaming.
I think directory renaming breaks the usual merges... because it leaves the
'to be removed' directory in the working directory still. A manual 'rm' of the
'to be removed' directory fixed the commit.
svn merge ^/nixpkgs/trunk
svn path=/nixpkgs/branches/stdenv-updates/; revision=18661
this because 'ld' wants to know the path of every library involved in a dynamic
linking. I imagine that ld does not need that in native builds because it can
call the loader for it to resolve the library rpaths, but this is not the case
for cross-building.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18577
inputs did not get in)
Updating the xorg builder script to support cross building (in fact, support
for propagating the required build inputs).
svn path=/nixpkgs/branches/stdenv-updates/; revision=18569
native strip. So we now distinguish dontStrip and dontCrossStrip. I updated
the expressions for glibc-2.9 and glibc-2.11 accordingly.
I could get rid of the cross-glibc depending on the cross-gcc-stage-static.
Enabling nls in the final cross-gcc.
I still have problems on wint_t/wchar_t not working on cross build. Gettext
does not build.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18562
- Disabling guile test, because one fails. I commented on that in the source.
On cross builds:
- Adding stripping
- Updating the glibc-2.11 expression to match the parameters of glibc-2.9,
which I was updating more.
- Renaming from selfNativeBuildInput to selfBuildNativeInput, so this matches
better the pattern buildNativeInputs.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18550
eqStrict now to return false when a b have different types. Passing
string and {} to eqStrict caused coercion failures when running tests
previously
svn path=/nixpkgs/trunk/; revision=18539
- Before this changes, cflags and ldflags for the native and the cross compiler
got mixed. Not all the gcc-wrapper/gcc-cross-wrapper variables are
independant now, but enough, I think.
- Fixed the generic stdenv expression, which did a big mess on buildInputs and
buildNativeInputs. Now it distinguishes when there is a stdenvCross or not.
Maybe we should have a single stdenv and forget about the stdenvCross
adapter - this could end in a stdenv a bit complex, but simpler than the
generic stdenv + adapter.
- Added basic support in pkgconfig for cross-builds: a single PKG_CONFIG_PATH
now works for both the cross and the native compilers, but I think this
should work well for most cases I can think of.
- I tried to fix the guile expression to cross-biuld; guile is built, but not
its manual, so the derivation still fails. Guile requires patching to
cross-build, as far as I understnad.
- Made the glibcCross build to be done through the usage of a
gcc-cross-wrapper over the gcc-cross-stage-static, instead of using it
directly.
- Trying to make physfs (a neverball dependency) cross build.
- Updated the gcc expression to support building a cross compiler without getting
derivation variables mixed with those of the stdenvCross.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18534
on a derivation with a meta.license attribute which does not satisfy the
license predicate.
With this adapter you can abort any install which depends on software
which are not free by default. You can try it with MPlayer, because
MPlayer depends of win32codecs flagged as "unfree".
svn path=/nixpkgs/trunk/; revision=18530
its dependencies. To make it works, you need to change the default
stdenv as documented in the error message.
./maintainers/scripts/dep-licenses.sh <attribute name>
svn path=/nixpkgs/trunk/; revision=18508
buildInputs and buildNativeInputs, on pkgconfig, which now works always
as buildDrv even asking for its hostDrv.
Key string: cross_renaming
svn path=/nixpkgs/branches/stdenv-updates/; revision=18506
I was trying to cross compile SDL. Many dependencies work, but I ended seeing
libX11 not ready for cross compilation. Other xorg libraries cross-compile
well. libX11 may need a small patch. The problem is the usual "configure test
cannot be run in cross compilation", so the configure script halts.
I made the pkgconfig expression always return buildDrv, as I think it rarely
will be needed as buildInput. So to avoid rewriting all its mentions to use
it as buildNativeInput, I prefered this small change.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18500
