The new patch method and mit-krb5

2013-10-29 Thread Mark H Weaver
Hello all,

A patch is needed to allow mit-krb5 to build on MIPS N32.  However, the
new method, where 'patches' is part of 'origin', does not work for
mit-krb5.

mit-krb5 is distributed in a strange way.  It's distributed as a tar
file that contains two files: a .tar.gz file with the actual source
code, and a signature for that .tar.gz file.  The mit-krb5 recipe copes
with this by using a custom 'unpack' phase.

My working patch is now on the 'loongson' branch:

  
http://git.savannah.gnu.org/cgit/guix.git/commit/?h=loongson&id=db956e3aff4ea5d39fb45a5a1079f8b24a592c29

Can someone help me convert this to use the new patch method?
We'll need a solution before the old patch method goes away.

 Thanks,
   Mark



Re: Guile under Guix on Arm

2013-10-29 Thread Andreas Enge
On Tue, Oct 29, 2013 at 09:51:51PM +0100, Ludovic Courtès wrote:
> Could you check in config.log why ‘GC_set_finalizer_notifier’ was
> considered unavailable?

Here is an excerpt of config.log:

configure:48599: checking for GC_set_finalizer_notifier
configure:48599: armv5-linux-gnueabi-gcc -o conftest 
-I/nix/store/8wkjgpb4b81ha352zz4fn3pvcwnj8x8c-libgc-7.2d/include   -g -O2  -ldl 
conftest.c -L/nix/store/8wkjgpb4b81ha352zz4fn3pvcwnj8x8c-libgc-7.2d/lib -lgc   
-lcrypt -lm  >&5
/nix/store/nf41xld171gr7zyzamb6lk7c2fx3cgn0-gcc-cross-armv5-linux-gnueabi-4.7.3/libexec/gcc/armv5-linux-gnueabi/ld:
 warning: libpthread.so.0, needed by 
/nix/store/8wkjgpb4b81ha352zz4fn3pvcwnj8x8c-libgc-7.2d/lib/libgc.so, not found 
(try using -rpath or -rpath-link)
/nix/store/8wkjgpb4b81ha352zz4fn3pvcwnj8x8c-libgc-7.2d/lib/libgc.so: undefined 
reference to `pthread_detach@GLIBC_2.4'
/nix/store/8wkjgpb4b81ha352zz4fn3pvcwnj8x8c-libgc-7.2d/lib/libgc.so: undefined 
reference to `pthread_attr_getstack@GLIBC_2.4'
/nix/store/8wkjgpb4b81ha352zz4fn3pvcwnj8x8c-libgc-7.2d/lib/libgc.so: undefined 
reference to `pthread_create@GLIBC_2.4'
/nix/store/8wkjgpb4b81ha352zz4fn3pvcwnj8x8c-libgc-7.2d/lib/libgc.so: undefined 
reference to `sem_getvalue@GLIBC_2.4'
/nix/store/8wkjgpb4b81ha352zz4fn3pvcwnj8x8c-libgc-7.2d/lib/libgc.so: undefined 
reference to `pthread_cancel@GLIBC_2.4'
... (lots of further warnings concerning threads).
collect2: error: ld returned 1 exit status
configure:48599: $? = 1

Andreas




Re: Guile under Guix on Arm

2013-10-29 Thread Ludovic Courtès
Andreas Enge  skribis:

>./pre-inst-env guix build guile-static-stripped-tarball 
> --target=armv5-linux-gnueabi
> (after enabling armv5 as explained under porting in the guix manual)
> results in the following error:
>
>   CC   libguile_2.0_la-fluids.lo
> finalizers.c:166:1: error: static declaration of 'GC_set_finalizer_notifier' 
> follows non-static declaration
> In file included from ../libguile/bdw-gc.h:47:0,
>  from finalizers.c:26:
> /nix/store/8wkjgpb4b81ha352zz4fn3pvcwnj8x8c-libgc-7.2d/include/gc/gc.h:177:21:
>  note: previous declaration of 'GC_set_finalizer_notifier' was here

[...]

> And config.h contains
> /* #undef HAVE_GC_SET_FINALIZER_NOTIFIER */

Could you check in config.log why ‘GC_set_finalizer_notifier’ was
considered unavailable?

That could be worked around by adding
‘ac_cv func_GC_set_finalizer_notifier=yes’ to #:configure-flags, but I
suspect there’s another issue hiding here.

Thanks,
Ludo’.



Guile under Guix on Arm

2013-10-29 Thread Andreas Enge
Hello,

   ./pre-inst-env guix build guile-static-stripped-tarball 
--target=armv5-linux-gnueabi
(after enabling armv5 as explained under porting in the guix manual)
results in the following error:

  CC   libguile_2.0_la-fluids.lo
finalizers.c:166:1: error: static declaration of 'GC_set_finalizer_notifier' 
follows non-static declaration
In file included from ../libguile/bdw-gc.h:47:0,
 from finalizers.c:26:
/nix/store/8wkjgpb4b81ha352zz4fn3pvcwnj8x8c-libgc-7.2d/include/gc/gc.h:177:21: 
note: previous declaration of 'GC_set_finalizer_notifier' was here
make[3]: *** [libguile_2.0_la-finalizers.lo] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory 
`/tmp/nix-build-guile-static-2.0.9.drv-0/guile-2.0.9/libguile'
make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/tmp/nix-build-guile-static-2.0.9.drv-0/guile-2.0.9/libguile'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/nix-build-guile-static-2.0.9.drv-0/guile-2.0.9'
make: *** [all] Error 2
phase `build' failed after 54 seconds

Indeed, line 177 of gc.h is:
GC_API void GC_CALL GC_set_finalizer_notifier(GC_finalizer_notifier_proc);

And line 47 of bdw-gc.h is:
#include 

The static redefinition is in lines 164 ff. of finalizers.c:
#ifndef HAVE_GC_SET_FINALIZER_NOTIFIER
static void
GC_set_finalizer_notifier (void (*notifier) (void))
{
  GC_finalizer_notifier = notifier;
}
#endif

And config.h contains
/* #undef HAVE_GC_SET_FINALIZER_NOTIFIER */

"By hand", I did compile guile-2.0.9 without problem.

A problem in guile, or with the guile package in guix with respect to cross
compiling?

Andreas




Re: [PATCH] gnu: cmake: Bump to 2.8.12

2013-10-29 Thread Ludovic Courtès
Andreas Enge  skribis:

> On Tue, Oct 29, 2013 at 12:14:21AM +0100, Ludovic Courtès wrote:
>> Qt doesn’t depend on CMake AFAICS.  Am I missing something?
>
> No, but kde does, which is the main "consumer" of qt. Probably I was
> confusing things.

Ah, OK.

>> So it had two test failures (‘volume-test’ and ‘thread-test’) on
>> hydra.gnu.org (which runs 2.6.32-xen), and none on my laptop (which runs
>> 3.0.43).
>> I restarted the build a couple of times on hydra and it eventually
>> succeeded...
>> Not satisfying, but to me that suggests a timing issue.
>
> If it happens again, maybe we should disable parallel tests?

AFAICS the PulseAudio 4.0 tarball was generated with Automake 1.11,
where the ‘parallel-tests’ driver was disabled by default.  So tests are
run sequentially already.

We’d need to report it upstream, but I don’t really have enough info.
So it’d be great if someone could reproduce it and try to gather more
details.

Thanks,
Ludo’.



Re: GCC front-ends

2013-10-29 Thread Ludovic Courtès
Andreas Enge  skribis:

> On Mon, Oct 28, 2013 at 02:07:45PM +0100, Ludovic Courtès wrote:
>> I wonder if this would also be an opportunity to do that fixed-point
>> thing while we’re at rebuilding everything.  Or is it too ambitious?
>
> Only you can tell, as you have been doing a lot of work on it! Why not
> give it a try?

Right, let’s try, and consider it an optional goal for 0.5.

Ludo’.



Re: GCC front-ends

2013-10-29 Thread Andreas Enge
On Mon, Oct 28, 2013 at 02:07:45PM +0100, Ludovic Courtès wrote:
> I wonder if this would also be an opportunity to do that fixed-point
> thing while we’re at rebuilding everything.  Or is it too ambitious?

Only you can tell, as you have been doing a lot of work on it! Why not
give it a try?

Andreas




Re: [PATCH] gnu: cmake: Bump to 2.8.12

2013-10-29 Thread Andreas Enge
On Tue, Oct 29, 2013 at 12:14:21AM +0100, Ludovic Courtès wrote:
> Qt doesn’t depend on CMake AFAICS.  Am I missing something?

No, but kde does, which is the main "consumer" of qt. Probably I was
confusing things.

> So it had two test failures (‘volume-test’ and ‘thread-test’) on
> hydra.gnu.org (which runs 2.6.32-xen), and none on my laptop (which runs
> 3.0.43).
> I restarted the build a couple of times on hydra and it eventually
> succeeded...
> Not satisfying, but to me that suggests a timing issue.

If it happens again, maybe we should disable parallel tests?

Andreas