GNU bug report logs - #13848
Statically linking guile-2.0.

Previous Next

Full log

Message #47 received at 13848 <at> debbugs.gnu.org (full text, mbox):

From: shookie <at> email.de
To: Andy Wingo <wingo <at> pobox.com>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 13848 <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Sun, 10 Mar 2013 05:09:00 +0100

Ok, tried the windows builds again.

The struct timespec is still an issue in a mingw build on windows, but I know how to handle it.


On 10.03.2013, at 00:06, Andy Wingo <wingo <at> pobox.com> wrote:

> On Sat 09 Mar 2013 14:44, Jan Schukat <shookie <at> email.de> writes:
> 
>> Just tried it again on windows/mingw with the newer tarball:
>> 
>> http://hydra.nixos.org/build/4290536/download/3/guile-2.0.7.157-929d1.tar.gz
> 
> FWIW it seems hydra is totally down right now; of course that would
> happen as soon as ludo goes on holiday ;)
> 
> Here is a tarball I just generated from make dist:
> 
>  http://wingolog.org/priv/guile-2.0.7.179-94c5.tar.gz
> 
>> checking for gcc... gcc
>> checking whether the C compiler works... no
>> configure: error: in `/c/Users/shookie/guiletest/lib/guile-2.0':
>> configure: error: C compiler cannot create executables
> 
> No idea what is happening here, this looks like a problem on your side.

Ok, contrary to what I thought earlier, that was actually on my side: I set -rdynamic in the CFLAGS environment variable, because that is needed for the deadline module to work on linux. I guess I need to treat that differently too on each platform.

> 
> I fixed a bunch of things today.  BTW are you using the old mingw or are
> you using mingw32 or mingw64?  It seems that the mingw64 project (which
> provides both 32- and 64-bit builds) is the current thing, but I don't
> really know.
> 

The paths don't seem to be a problem anymore. Great.

> Anyway, please give the new tarball a roll and see how it works for you.
> Be sure to have a relatively new mingw.  I built everything myself, with
> all default options (except --enable-threads=pthreads in bdw-gc, and
> enabling dynamic builds in gmp), and it builds with only some warnings
> about iconv (filed with gnulib).  I can't get it to run under wine
> however, and that must mean something is pretty wrong...
> 
> Happy hacking,
> 
> Andy
> -- 
> http://wingolog.org/


As I said, I build everything on windows.

I have to build bdw-gc with --enable-threads=posix. If I don't, I get errors along this line:

./.libs/libguile-2.0.a(libguile_2.0_la-threads.o):threads.c:(.text+0xfb8): undefined reference to `GC_pthread_detach'
./.libs/libguile-2.0.a(libguile_2.0_la-threads.o):threads.c:(.text+0x10de): undefined reference to `GC_pthread_create'
./.libs/libguile-2.0.a(libguile_2.0_la-threads.o):threads.c:(.text+0x1221): undefined reference to `GC_pthread_detach'
./.libs/libguile-2.0.a(libguile_2.0_la-threads.o):threads.c:(.text+0x12d1): undefined reference to `GC_pthread_create'

The problem is, when I do build bdw-gc with posix threads, the guile module compiling is all broken, it periodically drops messages like this:

  GUILEC ice-9/eval.go
Backtrace:
In unknown file:
   ?: 3 [apply-smob/1 #<boot-closure 192c100 (_ _ _)> #t ...]
   ?: 2 [apply-smob/1 #<catch-closure 1ccee70>]
   ?: 1 [primitive-eval ((@ # %) (begin # # #))]
   ?: 0 [chmod #<closed: file 0> 438]

and it takes ages an ages. Builds on windows are not very fast in the first place, but I stopped the build after it go stuck at building vlist for half an hour. I'm gonna start another build like that and see what it looks like when I wake up.

BTW, have you tried to execute any of the guile cross-comiles you made on a windows machine?

Regards

Jan Schukat

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.