2015-01-04 6:45 GMT+08:00 Andreas Enge :
> Hello,
>
> On Sat, Jan 03, 2015 at 08:16:02PM +0100, Ludovic Courtès wrote:
> > > * gnu/packages/qt.scm (qt): Add inputs libxcomposite, libxml2, libxslt,
> > > mtdev, pcre, eudev. Add native-inputs bison, flex, gperf, python-2,
> ruby.
>
> actually, di
I’ve finally updated Libtool (commit e13f715). The test failures turned
out to be just the same as before, plus a couple of others due to the
fact that some tests now need autoconf and automake.
However, I haven’t ported the MIPS patch.
I would like to make this version of Libtool the default in
Hello,
On Sat, Jan 03, 2015 at 08:16:02PM +0100, Ludovic Courtès wrote:
> > * gnu/packages/qt.scm (qt): Add inputs libxcomposite, libxml2, libxslt,
> > mtdev, pcre, eudev. Add native-inputs bison, flex, gperf, python-2, ruby.
actually, did you check whether each of these are actually found and
Upstream 'patchelf' doesn't work on ARM.
Here's the upstream bug report:
https://github.com/NixOS/patchelf/issues/8
I had to apply a rather large patch from a fork
of 'patchelf' to get it working:
https://github.com/sriemer/patchelf/commit/0a96239cea6b97b9a0fff80da576e58ca2dfb2a2
For now,
Mark H Weaver writes:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver skribis:
>>
>>> It turns out that on ARM systems, the result of 'config.guess' depends
>>> on the result of 'uname -m'. In other words, details of the kernel (and
>>> perhaps processor?) on the build machine will
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> It turns out that on ARM systems, the result of 'config.guess' depends
>> on the result of 'uname -m'. In other words, details of the kernel (and
>> perhaps processor?) on the build machine will determine the triplet of
>> our
Manolis Ragkousis skribis:
> When trying to build coreutils for i686-pc-gnu, building
> cross-gcc-4.8.3 with glibc-hurd fails with:
>
> In unknown file:
>?: 0 [string-append
> "/gnu/store/1hl59s1pikplwfgclw4mlk38pkx3pc72-glibc-hurd-cross-i686-pc-gnu-2.18"
> ...]
>
> ERROR: In procedure string
Mark H Weaver skribis:
> It turns out that on ARM systems, the result of 'config.guess' depends
> on the result of 'uname -m'. In other words, details of the kernel (and
> perhaps processor?) on the build machine will determine the triplet of
> our builds, which in turn may affect what set of in
It turns out that on ARM systems, the result of 'config.guess' depends
on the result of 'uname -m'. In other words, details of the kernel (and
perhaps processor?) on the build machine will determine the triplet of
our builds, which in turn may affect what set of instructions is used.
Therefore, I
宋文武 skribis:
> * gnu/packages/qt.scm (qt): Update to 5.4.0.
> [origin]: Add snippet.
[...]
> * gnu/packages/qt.scm (qt): Add inputs libxcomposite, libxml2, libxslt,
> mtdev, pcre, eudev. Add native-inputs bison, flex, gperf, python-2, ruby.
LGTM. If you’re unsure whether this breaks appl
Cyril Roelandt skribis:
> On 12/29/2014 03:23 PM, Ludovic Courtès wrote:
>> Cyril Roelandt skribis:
>>
>>> * guix/scripts/lint.scm (uri-available?): New procedure.
>>> (%checkers): Add 'home-page' checker
>>
>> Some comments in addition to what David already wrote.
>>
>>> +(define (uri-avai
Mark H Weaver skribis:
> I'm pleased to announce that the 'wip-armhf' branch is now ready for
> wider testing. So far, I've successfully used this branch to:
>
> (1) cross-compile armhf-linux bootstrap tarballs on my Libreboot X60,
>
> (2) natively compile armhf bootstrap tarballs on my Novena,
Mark H Weaver skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver skribis:
>>
>>> I don't think we need a 'system' for every combination of flags. We
>>> should just find a small number of "sweet spots" in the tradeoff between
>>> minimum requirements vs performance. IMO, for
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> I chose system name "armhf-linux", GNU triplet "arm-linux-gnueabihf",
>> and the following GCC configure flags:
>>
>>--with-arch=armv7-a
>>--with-float=hard
>>--with-mode=thumb
>>--with-fpu=vfpv3-d16
>
> Does it
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> Mark H Weaver writes:
>>
>>> Any suggestions on how best to fix this? My first crude idea is to
>>> simply remove the "-lgcc_s" from %gcc-static.
>>
>> For now, this is the approach I took, in commit 5336e4c74.
>
> Sounds good
FYI, the recent mesa and xorg-server updates have resulted in 31 new
successful builds on mips64el:
http://hydra.gnu.org/eval/102200#tabs-now-succeed
Our current xorg-server still won't work on a Loongson2F-based machines,
which require some small but horrible patches that make it work _only_
o
On Sat, Jan 03, 2015 at 03:20:45PM +0800, 宋文武 wrote:
> We have not change ld-wrapper for this right?
Not yet, but I think we should do it soon.
Andreas
17 matches
Mail list logo
