Re: [PATCH] gnu: kde: Add kdelibs.

[Andreas Enge]

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

xorg-server successfully built on mips64el

[Mark H Weaver]

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_
on those machines.  (As I vaguely recall, the relevant patch hardcodes
the address of the framebuffer directly into the server.)

Anyway, if anyone still cares about those machines, it probably wouldn't
be hard to make a separate 'xorg-server-yeeloong' package that works
with them.  I vaguely remember thinking that a more proper fix would
involve changes to the kernel as well, to allow xorg-server to ask the
kernel where to find the framebuffer, as is done on other machines.

I confess that I have largely lost interest in the Lemote machines,
since Lemote's newer laptops require non-free blobs and I've lost
confidence that they will produce another machine that respects our
freedom anytime soon.  Meanwhile we have the Libreboot X60 (and soon
X200), the Novena, and other promising hardware in the pipeline.

Thoughts?
   Mark

Re: Problem with natively-built armhf bootstrap compiler

[Mark H Weaver]

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.
>
> I was tempting to do something like this:
>
> diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
> index a7156bf..dd33a26 100644
> --- a/gnu/packages/gcc.scm
> +++ b/gnu/packages/gcc.scm
> @@ -213,7 +213,7 @@ where the OS part is overloaded to denote a specific 
> ABI---into GCC
> ;; below, make sure to update the relevant code in
> ;; %gcc-static package as needed.
> (format #f "#define GNU_USER_TARGET_LIB_SPEC \
> -\"-L~a/lib %{!static:-rpath=~a/lib %{!static-libgcc:-rpath=~a/lib64 
> -rpath=~a/lib -lgcc_s}} \" ~a"
> +\"-L~a/lib %{!static:-rpath=~a/lib %{!static-libgcc:-rpath=~a/lib64 
> -rpath=~a/lib %{pthread: -lgcc_s}}} \" ~a"
> libc libc libdir libdir suffix))
>(("#define GNU_USER_TARGET_STARTFILE_SPEC.*$" line)
> (format #f "#define STANDARD_STARTFILE_PREFIX_1 \"~a/lib\"
>
> I believe this is enough to address what the comment mentions (glibc
> dlopening libgcc_s for pthread functions), but this will need testing.
>
> WDYT?

I confess I don't know enough about the relevant details to know whether
this would work reliably -- e.g. will -pthread always be passed to gcc
at link time whenever this problem would arise? -- but it certainly
looks like a cleaner solution in principle.

I'm glad to defer to your judgement on how best to fix this :)

   Thanks!
 Mark

Re: Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

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 mean that GCC generates Thumb code by default?

Yes.  I confess that I'm not sufficiently knowledgeable about ARM to
understand the tradeoffs here, and have simply followed Debian's lead.
There is some rationale here:

  https://wiki.debian.org/ArmHardFloatPort

There, it says:

  Thumb-2/ThumbEE: Thumb-2 provides code size improvements and unlike
  thumb(1) there is no interworking overhead except in a few corner
  cases. Also Thumb-2 is sufficiently complete that there is no need to
  fall back to ARM ISA for some operations (unlike thumb1). Thus
  defaulting to Thumb-2 on v7 or later makes sense.

I haven't yet verified that our GCC is generating Thumb-2 instructions
(as opposed to Thumb-1).  Debian's GCC apparently does, but they apply a
rather large patch from Linaro.  This should be checked at some point.

Anyway, here are some more links that might be worth looking at if we
run into build problems:

  https://wiki.ubuntu.com/ARM/Thumb2
  https://wiki.ubuntu.com/ARM/Thumb2PortingHowto

Regards,
  Mark

Re: Preliminary 'wip-armhf' branch pushed

[Ludovic Courtès]

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 32-bit ARM, two systems
>>> should be enough: armhf, and maybe another one (armel?) that works on
>>> lower-end processors.
>>
>> It’s not even clear that “hf” needs to be part of the system name.
>
> I think it needs to be part of the system name, because on ARM these are
> two incompatible ABIs.  Among other things, the hard-float ABI passes
> floating point arguments in registers.
>
>> In theory, the bootstrap tarballs could be soft-float, which means they
>> would run everywhere, and from there users could choose what
>> --with-float and --with-fpu flags to use.
>
> A single GCC can generate code for both ABIs, but each ABI uses its own
> dynamic linker.  If we did as you suggest, we'd need two separate
> bootstrap glibc's, and improve the dynamic-linker-name patching code in
> our gcc package to rewrite the two dynamic linker names separately, etc.

Very good points, I had overlooked this.

Thanks,
Ludo’.

Re: wip-armhf branch ready for wider testing

[Ludovic Courtès]

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, based on the
> cross-compiled bootstrap tarballs from (1), and
>
> (3) build the 'hello' package based on the natively-compiled bootstrap
> tarballs from (2).

Congrats on all the progress made!

It would be nice to have a couple of build machines for this platform.
If anyone reading this wants to help, please let us know!

Ludo’.

Re: [PATCH] lint: add 'source' checker.

[Ludovic Courtès]

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-available? uri)
>>> +  "Return #t if the given URI can be reached, otherwise throw a
>>> +'not-available exception along with an appropriate error message."
>> 
>> By convention, one would expect ‘uri-available?’ to return #t or #f, not
>> to throw.
>> 
>> How about calling it ‘validate-uri’ and directly call ‘emit-warning’
>> from there?  It would need the field name as an additional argument.
>> 
>
> This would also require passing the "package" to validate-uri.

Right, and I think it’s fine.

> How about we make uri-available? return #t/#f, and just don't really
> care about the exact reason why it failed ? Anyway a human being is
> going to manually check what happened to know whether this is a real
> issue or just a server that went down for a couple hours, or a file
> that wrongly got removed...

Possibly but still, I prefer to have detailed reports since we already
have all the details anyway.

Thanks,
Ludo’.

Re: [PATCH 1/2] gnu: qt: Update to 5.4.0.

[Ludovic Courtès]

宋文武  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 applications, we can put it
on a separate branch and have Hydra build it.  WDYT?

Thanks,
Ludo’.

Pass --build= to native builds by default?

[Mark H Weaver]

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 think that on ARM systems (and perhaps _all_ systems), we
should consider passing --build= to configure by default.

What do you think?

Mark

Re: Pass --build= to native builds by default?

[Ludovic Courtès]

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 instructions is used.

Do you know how the ‘uname -m’ output is used in config.guess?  What
does it return on ARM?

Often (always?) config.guess runs the compiler, and I think that’s the
most important source of information that it uses.

Thanks,
Ludo’.

Re: problem with building gcc-cross-4.8.3 for i686-pc-gnu

[Ludovic Courtès]

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-append:
> ERROR: In procedure string-append: Wrong type (expecting string): #f
>
> It shouldn't fail because glibc/hurd is in the path.

>From the log you sent, it’s the ‘set-cross-path’ phase (of the
cross-gcc) that’s failing.

In cross-base.scm (in master), one of them is like this:

   (setenv "CROSS_CPATH"
   (string-append libc "/include:"
  linux "/include"))

Could it be that in your case ‘linux’ above is #f, hence the error?

HTH,
Ludo’.

Re: Pass --build= to native builds by default?

[Mark H Weaver]

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 builds, which in turn may affect what set of instructions is used.
>
> Do you know how the ‘uname -m’ output is used in config.guess?  What
> does it return on ARM?

The output of 'uname -m' becomes the first (cpu) component of the GNU
triplet.  uname(1) gets its information from the kernel via the uname(2)
system call.  The field returned by 'uname -m' is described as "Hardware
identifier".  See .

Here's the relevant section of config.guess from gcc-4.8.4:

--8<---cut here---start->8---
arm*:Linux:*:*)
eval $set_cc_for_build
if echo __ARM_EABI__ | $CC_FOR_BUILD -E - 2>/dev/null \
| grep -q __ARM_EABI__
then
echo ${UNAME_MACHINE}-unknown-linux-${LIBC}
else
if echo __ARM_PCS_VFP | $CC_FOR_BUILD -E - 2>/dev/null \
| grep -q __ARM_PCS_VFP
then
echo ${UNAME_MACHINE}-unknown-linux-${LIBC}eabi
else
echo ${UNAME_MACHINE}-unknown-linux-${LIBC}eabihf
fi
fi
exit ;;
--8<---cut here---end--->8---

 Mark

Re: Pass --build= to native builds by default?

[Mark H Weaver]

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 determine the triplet of
>>> our builds, which in turn may affect what set of instructions is used.
>>
>> Do you know how the ‘uname -m’ output is used in config.guess?  What
>> does it return on ARM?
>
> The output of 'uname -m' becomes the first (cpu) component of the GNU
> triplet.  uname(1) gets its information from the kernel via the uname(2)
> system call.  The field returned by 'uname -m' is described as "Hardware
> identifier".  See .
>
> Here's the relevant section of config.guess from gcc-4.8.4:
>
> arm*:Linux:*:*)
>   eval $set_cc_for_build
>   if echo __ARM_EABI__ | $CC_FOR_BUILD -E - 2>/dev/null \
>   | grep -q __ARM_EABI__
>   then
>   echo ${UNAME_MACHINE}-unknown-linux-${LIBC}
>   else
>   if echo __ARM_PCS_VFP | $CC_FOR_BUILD -E - 2>/dev/null \
>   | grep -q __ARM_PCS_VFP
>   then
>   echo ${UNAME_MACHINE}-unknown-linux-${LIBC}eabi
>   else
>   echo ${UNAME_MACHINE}-unknown-linux-${LIBC}eabihf
>   fi
>   fi
>   exit ;;

I forgot to answer your second question.  On my Novena, 'uname -m'
returns "armv7l".  The problem is this: I suspect that if the build
machine has an armv8 processor, it will return something different like
"armv8l".

  Mark

patchelf apparently needs extensive changes to work on ARM

[Mark H Weaver]

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, I've applied this patch on the 'wip-armhf' branch in commit
8de9362f3.  If anyone has a better suggestion, I'm all ears.

 Mark

Re: [PATCH 1/2] gnu: qt: Update to 5.4.0.

[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, did you check whether each of these are actually found and used
during the build of qt? I seem to recall that I tried one or two of them
and they were not found.

Andreas

Re: Libtool

[Ludovic Courtès]

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
core-updates, but that needs to work on MIPS before we can do that.
Mark?

Thanks,
Ludo’.

Re: [PATCH 1/2] gnu: qt: Update to 5.4.0.

[宋文武]

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, did you check whether each of these are actually found and used
> during the build of qt? I seem to recall that I tried one or two of them
> and they were not found.
>
Actually, it failed at qtwebengine, and pcre not used..
I'll check more.

>
> Andreas
>
>