all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Cross-compilation from armhf to mips64el
@ 2015-10-05 19:08 Andreas Enge
  2015-10-06 19:45 ` Ludovic Courtès
  0 siblings, 1 reply; 6+ messages in thread
From: Andreas Enge @ 2015-10-05 19:08 UTC (permalink / raw)
  To: guix-devel

Hello,

currently, we get lots of failed jobs for armhf coming from cross-compilation,
such as
   http://hydra.gnu.org/job/gnu/master/mips64el-linux-gnu.grep-2.21.armhf-linux

I would think that the problem comes from build-aux/hydra/guix.scm, in this
function:
    (define (from-32-to-64? target)
      ;; Return true if SYSTEM is 32-bit and TARGET is 64-bit.  This hack
      ;; prevents known-to-fail cross-builds from i686-linux or armhf-linux to
      ;; mips64el-linux-gnuabi64.
      (and (or (string-prefix? "i686-" system)
               (string-prefix? "armhf-" system))
           (string-suffix? "64" target)))
since target seems to be mips64el-linux-gnu and not mips64el-linux-gnuabi64.
Then I would replace "string-suffix?" by "string-contains".

But I must have overlooked something, since hydra does not cross-build from
i686 to mips. If someone could have a look...

Andreas

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Cross-compilation from armhf to mips64el
  2015-10-05 19:08 Cross-compilation from armhf to mips64el Andreas Enge
@ 2015-10-06 19:45 ` Ludovic Courtès
  2015-10-08 18:48   ` Andreas Enge
  0 siblings, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2015-10-06 19:45 UTC (permalink / raw)
  To: Andreas Enge; +Cc: guix-devel

Andreas Enge <andreas@enge.fr> skribis:

> currently, we get lots of failed jobs for armhf coming from cross-compilation,
> such as
>    http://hydra.gnu.org/job/gnu/master/mips64el-linux-gnu.grep-2.21.armhf-linux

The problem in question is this:

--8<---------------cut here---------------start------------->8---
gcc   -D_RPC_THREAD_SAFE_ -D_GNU_SOURCE -DIS_IN_build -include /tmp/nix-build-glibc-cross-mips64el-linux-gnu-2.22.drv-0/build/config.h rpc_main.c \
	-o /tmp/nix-build-glibc-cross-mips64el-linux-gnu-2.22.drv-0/build/sunrpc/cross-rpc_main.o -MMD -MP -MF /tmp/nix-build-glibc-cross-mips64el-linux-gnu-2.22.drv-0/build/sunrpc/cross-rpc_main.o.dt -MT /tmp/nix-build-glibc-cross-mips64el-linux-gnu-2.22.drv-0/build/sunrpc/cross-rpc_main.o -c
In file included from /gnu/store/j3rpssxbamdarpqxsljxi9r28hl3zhzm-glibc-2.22/include/signal.h:326:0,
                 from /gnu/store/j3rpssxbamdarpqxsljxi9r28hl3zhzm-glibc-2.22/include/sys/param.h:28,
                 from rpc_main.c:45:
/gnu/store/j3rpssxbamdarpqxsljxi9r28hl3zhzm-glibc-2.22/include/sys/ucontext.h:107:16: error: field ?uc_mcontext? has incomplete type
     mcontext_t uc_mcontext;
                ^
Makefile:165: recipe for target '/tmp/nix-build-glibc-cross-mips64el-linux-gnu-2.22.drv-0/build/sunrpc/cross-rpc_main.o' failed
--8<---------------cut here---------------end--------------->8---

Before disabling cross-builds from armhf to mips64el like you suggest,
we should check whether the problem is on our side or note.

Here this is a cross-build of libc where we’re building a cross-rpcgen.
The cross-rpcgen is natively compiled, so GCC must have the native (arm)
kernel and libc headers in CPATH, not the mips headers.

I checked
/gnu/store/j3rpssxbamdarpqxsljxi9r28hl3zhzm-glibc-2.22/include/sys/ucontext.h
and I confirm that it’s an ARM header.

Long story short: everything is alright.  :-)

> I would think that the problem comes from build-aux/hydra/guix.scm, in this
> function:
>     (define (from-32-to-64? target)
>       ;; Return true if SYSTEM is 32-bit and TARGET is 64-bit.  This hack
>       ;; prevents known-to-fail cross-builds from i686-linux or armhf-linux to
>       ;; mips64el-linux-gnuabi64.
>       (and (or (string-prefix? "i686-" system)
>                (string-prefix? "armhf-" system))
>            (string-suffix? "64" target)))
> since target seems to be mips64el-linux-gnu and not mips64el-linux-gnuabi64.
> Then I would replace "string-suffix?" by "string-contains".

Or should we define a black list of pairs?

Ludo’.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Cross-compilation from armhf to mips64el
  2015-10-06 19:45 ` Ludovic Courtès
@ 2015-10-08 18:48   ` Andreas Enge
  2015-10-09  0:47     ` Mark H Weaver
  0 siblings, 1 reply; 6+ messages in thread
From: Andreas Enge @ 2015-10-08 18:48 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

Hm, I do not understand your message.

On Tue, Oct 06, 2015 at 09:45:35PM +0200, Ludovic Courtès wrote:
> The problem in question is this:
> ...
> Long story short: everything is alright.  :-)

So is there a problem or not? The function in question is supposed to
prevent cross-compilation from 32 to 64 bits; yet there is cross-compilation
from arm to mips64. I do not quite see why, and why it works to prevent
cross-compilation from i686 to mips64. So are you saying we should cross-
compile from arm to mips64? Probably not, as it seems to fail.

> Or should we define a black list of pairs?

Or a white list? What exactly should we cross-compile on hydra?

Andreas

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Cross-compilation from armhf to mips64el
  2015-10-08 18:48   ` Andreas Enge
@ 2015-10-09  0:47     ` Mark H Weaver
  2015-10-09  8:33       ` Ludovic Courtès
  2015-10-09  9:10       ` Andreas Enge
  0 siblings, 2 replies; 6+ messages in thread
From: Mark H Weaver @ 2015-10-09  0:47 UTC (permalink / raw)
  To: Andreas Enge; +Cc: guix-devel

Andreas Enge <andreas@enge.fr> writes:

> Hm, I do not understand your message.
>
> On Tue, Oct 06, 2015 at 09:45:35PM +0200, Ludovic Courtès wrote:
>> The problem in question is this:
>> ...
>> Long story short: everything is alright.  :-)
>
> So is there a problem or not? The function in question is supposed to
> prevent cross-compilation from 32 to 64 bits;

mips64el-linux-gnu uses 32-bit pointers, which is most likely the
important issue.  Note that we successfully cross-compile from i686 to
mips64el-linux-gnu, so I guess that works.

I would prefer not to disable these builds until we understand what's
going on.  Maybe it would be easy to fix.

     Mark

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Cross-compilation from armhf to mips64el
  2015-10-09  0:47     ` Mark H Weaver
@ 2015-10-09  8:33       ` Ludovic Courtès
  2015-10-09  9:10       ` Andreas Enge
  1 sibling, 0 replies; 6+ messages in thread
From: Ludovic Courtès @ 2015-10-09  8:33 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel

Mark H Weaver <mhw@netris.org> skribis:

> Andreas Enge <andreas@enge.fr> writes:
>
>> Hm, I do not understand your message.
>>
>> On Tue, Oct 06, 2015 at 09:45:35PM +0200, Ludovic Courtès wrote:
>>> The problem in question is this:
>>> ...
>>> Long story short: everything is alright.  :-)
>>
>> So is there a problem or not? The function in question is supposed to
>> prevent cross-compilation from 32 to 64 bits;
>
> mips64el-linux-gnu uses 32-bit pointers, which is most likely the
> important issue.  Note that we successfully cross-compile from i686 to
> mips64el-linux-gnu, so I guess that works.
>
> I would prefer not to disable these builds until we understand what's
> going on.  Maybe it would be easy to fix.

Could be.  I guess an issue is that nobody tries to build an
ARM → mips64el cross-toolchain.

Ludo’.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Cross-compilation from armhf to mips64el
  2015-10-09  0:47     ` Mark H Weaver
  2015-10-09  8:33       ` Ludovic Courtès
@ 2015-10-09  9:10       ` Andreas Enge
  1 sibling, 0 replies; 6+ messages in thread
From: Andreas Enge @ 2015-10-09  9:10 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel

On Thu, Oct 08, 2015 at 08:47:26PM -0400, Mark H Weaver wrote:
> Note that we successfully cross-compile from i686 to
> mips64el-linux-gnu, so I guess that works.

Oh I see, there was a misunderstanding on my part - I somehow thought that
we were successfully disabling the cross-build from i686 to mips.
So do I understand correctly now that the procedure from-32-to-64? is
currently superfluous, since we do not currently build for the target
mips64el-linux-gnuabi64?

Sorry for the noise based on my fundamental misunderstanding!

Andreas

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2015-10-09  9:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-05 19:08 Cross-compilation from armhf to mips64el Andreas Enge
2015-10-06 19:45 ` Ludovic Courtès
2015-10-08 18:48   ` Andreas Enge
2015-10-09  0:47     ` Mark H Weaver
2015-10-09  8:33       ` Ludovic Courtès
2015-10-09  9:10       ` Andreas Enge

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.