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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13848 in the body.
You can then email your comments to 13848 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Jan Schukat <shookie <at> email.de>
To: bug-guile <at> gnu.org
Subject: Statically linking guile-2.0.
Date: Fri, 01 Mar 2013 17:19:59 +0100

I'm trying to build a program that uses guile 2.0 on linux, windows and 
osx and finds the same environment, more or less, on all 3 platforms. 
That means mainly for windows reasons, I have to statically link it.

So, first step is a little test system to compile it everywhere.

But compiling guile-2.0 on MinGW is a very hairy undertaking. I'm not 
sure how often it is tested by the developers.

First of all, You have to define a whole lot of environment variables. 
For one, there is no pkg-config on windows, but ./configure --help tells 
you what to do, so that's ok.

Also, when you link statically and the symbol resolving works 
differently, you have to go through some hoops to resolve boehm-gc 
symbols, despite the preprocessor guards: That concerns 
HAVE_GC_SET_FINALIZER_NOTIFIER, HAVE_GC_GET_HEAP_USAGE_SAFE, 
HAVE_GC_GET_FREE_SPACE_DIVISOR, HAVE_GC_SET_FINALIZE_ON_DEMAND. In guile 
there are statically defined fallbacks for the respective functions, 
that cause linker conflicts when statically linked. Those functions 
probably should be renamed completely to prevent this kind of problem.

Then there is also the old problem of the conflicting definitions of 
struct timespec on MinGW in time.h and pthreads.h. I still have to 
conditionally define it in stat-time.h and in thread.c - and I can't use 
HAVE_STRUCT_TIMESPEC as a preprocessor check, it has to be 
__TIMESPEC_DEFINED. Anything else leads to ugly conflicts, either 
already at compile time or at link time. Most likely also related to 
statically linking.

The bug #13768 about scm_getpid being used in "--without-posix" builds I 
have sent already.

Also, on mingw the guile-tools/guild copy script can't deal with the 
.exe ending. I have to configure and make once with 
--program-suffix=.exe to create the proper script names and files, and 
then again without, so they can be copied. (or find and copy them by 
hand between builds)

But then on install (processing .texi files) guile.exe fails with this 
message:

"Throw without catch before boot:
Throw to key system-error with args ("canonicalize-path" "~A" ("No such 
file or directory") (2))Aborting.

This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information."

Calling guile.exe directly gives this message:

"Throw without catch before boot:
Throw to key misc-error with args ("primitive-load-path" "Unable to find 
file ~S in load path" ("ice-9/boot-9") #f)Aborting.

This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information."


When I copy the libguile and the header by hand and then I can build the 
a program, which does nothing more but calling scm_with_guile and 
scm_shell, get a popup window with the message:

"This application has requested the Runtime to terminate it in an 
unusual way.
Please contact the application's support team for more information."


So my guess is, that due to some weird path construction in automake (of 
which the .exe copying trouble is just another symptom), the scheme 
modules can't be found and built, and thus everything crashes at startup.

But trying to figure out what's going on and wrong in an automake build 
is a major project of its own. Any hints by the experts?

Regards

Jan Schukat

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Jan Schukat <shookie <at> email.de>
Cc: 13848 <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Sat, 02 Mar 2013 16:28:48 +0100

Hello,

Thanks for the report.

Jan Schukat <shookie <at> email.de> skribis:

> But then on install (processing .texi files) guile.exe fails with this
> message:
>
> "Throw without catch before boot:
> Throw to key system-error with args ("canonicalize-path" "~A" ("No
> such file or directory") (2))Aborting.

[...]

> Calling guile.exe directly gives this message:
>
> "Throw without catch before boot:
> Throw to key misc-error with args ("primitive-load-path" "Unable to
> find file ~S in load path" ("ice-9/boot-9") #f)Aborting.

Does it happen when running the installed Guile?  That is, you
successfully run ‘make’ and ‘make install’ (and ideally ‘make check’),
and it’s the installed ‘guile’ binary that produces this message?

As most Unix and GNU packages, Guile expects to be installed in the
place specified by --prefix.  If you install it elsewhere, it will fail
to find its companion files, such as ice-9/boot-9.scm.  So you really
must install it in --prefix, and leave it there.  Is it what you did?

(Note that this restriction can be worked around by techniques such as
found in
<http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/guile-relocatable.patch>.)

Thanks,
Ludo’.

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

From: Jan Schukat <shookie <at> email.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 13848 <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Mon, 04 Mar 2013 00:20:10 +0100

[Message part 1 (text/plain, inline)]

Thank you for the reply!

I guess it's best I send you my little test project, which is just a 
makefile and a different main .cc file for each platform. Although it's 
work in progress, it makes what I'm doing reproducible and explains it.

On 03/02/2013 04:28 PM, Ludovic Courtès wrote:
> Hello,
>
> Thanks for the report.
>
> Jan Schukat <shookie <at> email.de> skribis:
>
>> But then on install (processing .texi files) guile.exe fails with this
>> message:
>>
>> "Throw without catch before boot:
>> Throw to key system-error with args ("canonicalize-path" "~A" ("No
>> such file or directory") (2))Aborting.
> [...]
>
>> Calling guile.exe directly gives this message:
>>
>> "Throw without catch before boot:
>> Throw to key misc-error with args ("primitive-load-path" "Unable to
>> find file ~S in load path" ("ice-9/boot-9") #f)Aborting.
> Does it happen when running the installed Guile?  That is, you
> successfully run ‘make’ and ‘make install’ (and ideally ‘make check’),

It's the guile.exe, guild.exe, guile-config.exe and guile-tools.exe in 
guile-2.0/meta.

And when I trick automake into installing (by running it twice, first 
with --program-suffix=.exe, then without, then the installed files fail, 
although they are not binaries, but hashbang scripts.
Same happens of course when I install the by hand into prefix/bin.

I haven't gotten to compile on Linux yet in my build setup since I tried 
it on windows, because of the linking conflicts with the boehm-GC 
callbacks. That's what I'm gonna continue with now.


> and it’s the installed ‘guile’ binary that produces this message?
>
> As most Unix and GNU packages, Guile expects to be installed in the
> place specified by --prefix.  If you install it elsewhere, it will fail
> to find its companion files, such as ice-9/boot-9.scm.  So you really
> must install it in --prefix, and leave it there.  Is it what you did?
>
> (Note that this restriction can be worked around by techniques such as
> found in
> <http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/guile-relocatable.patch>.)
>
> Thanks,
> Ludo’.

Thank you for the hint. Eventually the binary should look for the scheme 
libraries relative to the binary position, at least on OSX where they 
will be placed in the .app directory and Windows.

Regards

Jan Schukat

[guiletest.tgz (application/x-compressed-tar, attachment)]

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

From: Jan Schukat <shookie <at> email.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 13848 <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Tue, 05 Mar 2013 01:54:12 +0100

[Message part 1 (text/plain, inline)]

Ok, I did some more work on the linux and mingw side. My little test 
project now compiles and works under linux, provided in gc.c I remove 
the static qualifiers from GC_set_finalize_on_demand, 
GC_get_heap_usage_safe, GC_get_free_space_divisor and 
GC_set_finalizer_notifier. That still gave a warning at linking time, 
but any combination of preprocessor guards caused either compile errors 
or link errors.

Also, when building guile-2.9 with --disable-posix, there comes a 
lisp-compile error when the standard modules are made:

  GUILEC ice-9/popen.go
Backtrace:
In ice-9/eval.scm:
 376: 19 [eval # #]
In srfi/srfi-1.scm:
 619: 18 [for-each #<procedure a389618 at ice-9/eval.scm:405:20 (a)> #]
In ice-9/eval.scm:
 376: 17 [eval # #]
 470: 16 [lp (#<fluid 23>) ("")]
In system/base/target.scm:
  59: 15 [with-target "i686-pc-linux-gnu" ...]
In system/base/compile.scm:
 147: 14 [compile-file "ice-9/popen.scm" #:output-file ...]
  43: 13 [call-once #<procedure a434b40 at system/base/compile.scm:56:5 
()>]
In ice-9/boot-9.scm:
 171: 12 [with-throw-handler #t ...]
In system/base/compile.scm:
  59: 11 [#<procedure a434b20 at system/base/compile.scm:58:9 ()>]
 150: 10 [#<procedure a434b60 at system/base/compile.scm:148:8 (port)> 
#<input-output: ice-9/popen.go.HBtyxJ 6>]
 199: 9 [read-and-compile #<input: ice-9/popen.scm 5> #:from ...]
 211: 8 [lp (#<tree-il (let # # ...)>) #<directory (ice-9 popen) 
a4f2a68> ...]
 177: 7 [lp (#<procedure compile-tree-il (x e opts)>) (eval-when # #) ...]
In ice-9/boot-9.scm:
2131: 6 [save-module-excursion #<procedure a50b9f0 at 
language/scheme/compile-tree-il.scm:29:3 ()>]
In language/scheme/compile-tree-il.scm:
  31: 5 [#<procedure a50b9f0 at 
language/scheme/compile-tree-il.scm:29:3 ()>]
In ice-9/psyntax.scm:
1091: 4 [expand-top-sequence ((eval-when # #)) () ((top)) ...]
 976: 3 [scan ((eval-when # #)) () ((top)) ...]
 270: 2 [scan ((load-extension # "scm_init_popen")) () ((top)) ...]
In unknown file:
   ?: 1 [load-extension "libguile-2.0" "scm_init_popen"]
In ice-9/boot-9.scm:
 106: 0 [#<procedure a434b00 at ice-9/boot-9.scm:97:6 (thrown-k . 
args)> misc-error ...]

ice-9/boot-9.scm:106:20: In procedure #<procedure a434b00 at 
ice-9/boot-9.scm:97:6 (thrown-k . args)>:
ice-9/boot-9.scm:106:20: In procedure dynamic-pointer: Symbol not found: 
scm_init_popen
make[3]: *** [ice-9/popen.go] Error 1
make[3]: Leaving directory `/home/shookie/guiletest/lib/guile-2.0/module'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/home/shookie/guiletest/lib/guile-2.0'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/home/shookie/guiletest/lib/guile-2.0'
make: *** [lib/lib/libguile-2.0.a] Error 2


When I leave out that option it (the test project) builds and runs fine 
on linux now though.

On mingw, I still have to define the struct timespec:

diff --recursive guile-2.0/lib/stat-time.h guile-2.0.7/lib/stat-time.h
26,32d25
< #ifndef _TIMESPEC_DEFINED
< struct timespec {
<         time_t tv_sec;
<         long tv_nsec;
< };
< #endif
<
diff --recursive guile-2.0/libguile/random.c guile-2.0.7/libguile/random.c
668c668
<      scm_from_ulong(getpid()),         /* process ID */
---
>      scm_getpid (),         /* process ID */
diff --recursive guile-2.0/libguile/threads.c guile-2.0.7/libguile/threads.c
70,75d69
< #ifndef _TIMESPEC_DEFINED
< struct timespec {
<         time_t tv_sec;
<         long tv_nsec;
< };
< #endif

With that it builds.

When I run it with --program-suffix=.exe it also copies guild.exe 
(without it fails while trying), but then fails when it tries to run it 
without the suffix.

So I run it again without the --program-suffix, and since the files are 
copied in the previous build it starts them, but then they fail like this:


 but then fails installing the lisp modules:

  GEN      guile-procedures.texi
Throw without catch before boot:
Throw to key system-error with args ("canonicalize-path" "~A" ("No such 
file or directory") (2))Aborting.

This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.
make[4]: *** [guile-procedures.texi] Error 1
make[4]: Leaving directory 
`/c/Users/shookie/guiletest/lib/guile-2.0/libguile'
make[3]: *** [install] Error 2
make[3]: Leaving directory 
`/c/Users/shookie/guiletest/lib/guile-2.0/libguile'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0'
make: *** [lib/lib/libguile-2.0.a] Error 2

I attached the new updated test-project tgz.

In summary, I still think on mingw the configure script gets very 
confused about paths and file names.

Regards

Jan Schukat


On 03/02/2013 04:28 PM, Ludovic Courtès wrote:
> Hello,
>
> Thanks for the report.
>
> Jan Schukat<shookie <at> email.de>  skribis:
>
>> But then on install (processing .texi files) guile.exe fails with this
>> message:
>>
>> "Throw without catch before boot:
>> Throw to key system-error with args ("canonicalize-path" "~A" ("No
>> such file or directory") (2))Aborting.
> [...]
>
>> Calling guile.exe directly gives this message:
>>
>> "Throw without catch before boot:
>> Throw to key misc-error with args ("primitive-load-path" "Unable to
>> find file ~S in load path" ("ice-9/boot-9") #f)Aborting.
> Does it happen when running the installed Guile?  That is, you
> successfully run ‘make’ and ‘make install’ (and ideally ‘make check’),
> and it’s the installed ‘guile’ binary that produces this message?
>
> As most Unix and GNU packages, Guile expects to be installed in the
> place specified by --prefix.  If you install it elsewhere, it will fail
> to find its companion files, such as ice-9/boot-9.scm.  So you really
> must install it in --prefix, and leave it there.  Is it what you did?
>
> (Note that this restriction can be worked around by techniques such as
> found in
> <http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/guile-relocatable.patch>.)
>
> Thanks,
> Ludo’.

[guiletest.tgz (application/x-compressed-tar, attachment)]

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Jan Schukat <shookie <at> email.de>
Cc: 13848 <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Tue, 05 Mar 2013 11:22:26 +0100

Hi,

Sorry for the delay.

Jan Schukat <shookie <at> email.de> skribis:

> ice-9/boot-9.scm:106:20: In procedure #<procedure a434b00 at
> ice-9/boot-9.scm:97:6 (thrown-k . args)>:
> ice-9/boot-9.scm:106:20: In procedure dynamic-pointer: Symbol not
> found: scm_init_popen
> make[3]: *** [ice-9/popen.go] Error 1

I see: the (ice-9 popen) module depends on functionality that is missing
when building with --disable-posix, so it cannot be built.  This is a
bug: Guile shouldn’t try to build ice-9/popen.scm when --disable-posix
is used.

Regarding file names on MinGW, Andy Wingo did a lot of work recently to
integrate them correctly.  This will be in Guile 2.0.8, but in the
meantime could you try building Guile’s ‘stable-2.0’ branch from Git?

  git clone git://git.sv.gnu.org/guile.git
  git checkout stable-2.0
  autoreconf -vfi
  ./configure
  make && make check

Thanks in advance,
Ludo’.

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

From: Jan Schukat <shookie <at> email.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 13848 <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Tue, 05 Mar 2013 16:44:55 +0100

Ok, tried that on linux.

autoreconf demanded automake 1.12, which isn't available via .debs on 
ubuntu yet, so I installed that from the sources.

after that I get this error message:

configure.ac:873: warning: macro 'AM_GNU_GETTEXT' not found in library
autoreconf: running: /usr/bin/autoconf --force
configure.ac:900: error: possibly undefined macro: AM_GNU_GETTEXT
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1

I simply don't know enough about automake internals to even know where 
to begin to go about such errors. What library would such macros be 
defined in? And if I knew that, would I even want to do any changes 
there? Or is that generated from one of the dozens of scripts in the 
auto toolchain? I wouldn't even know where one might apply that 
m4_pattern_allow. What I can gather it could also just be a sign of a 
syntax error in the configure.ac.

Regards

Jan Schukat

On 03/05/2013 11:22 AM, Ludovic Courtès wrote:
> Hi,
>
> Sorry for the delay.
>
> Jan Schukat <shookie <at> email.de> skribis:
>
>> ice-9/boot-9.scm:106:20: In procedure #<procedure a434b00 at
>> ice-9/boot-9.scm:97:6 (thrown-k . args)>:
>> ice-9/boot-9.scm:106:20: In procedure dynamic-pointer: Symbol not
>> found: scm_init_popen
>> make[3]: *** [ice-9/popen.go] Error 1
> I see: the (ice-9 popen) module depends on functionality that is missing
> when building with --disable-posix, so it cannot be built.  This is a
> bug: Guile shouldn’t try to build ice-9/popen.scm when --disable-posix
> is used.
>
> Regarding file names on MinGW, Andy Wingo did a lot of work recently to
> integrate them correctly.  This will be in Guile 2.0.8, but in the
> meantime could you try building Guile’s ‘stable-2.0’ branch from Git?
>
>    git clone git://git.sv.gnu.org/guile.git
>    git checkout stable-2.0
>    autoreconf -vfi
>    ./configure
>    make && make check
>
> Thanks in advance,
> Ludo’.

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Jan Schukat <shookie <at> email.de>
Cc: 13848 <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Tue, 05 Mar 2013 18:25:10 +0100

Jan Schukat <shookie <at> email.de> skribis:

> autoreconf demanded automake 1.12, which isn't available via .debs on
> ubuntu yet, so I installed that from the sources.
>
> after that I get this error message:
>
> configure.ac:873: warning: macro 'AM_GNU_GETTEXT' not found in library
> autoreconf: running: /usr/bin/autoconf --force
> configure.ac:900: error: possibly undefined macro: AM_GNU_GETTEXT
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.
> autoreconf: /usr/bin/autoconf failed with exit status: 1

You need to install the ‘gettext’ package and re-run autoreconf.

Even easier: grab a tarball from
<http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest>.

Note that the reason I’m suggesting using the latest 2.0 is to fix file
name problems on MinGW.  So you can take the tarball from the above URL,
and build from there on MinGW.

Ludo’.

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

From: Jan Schukat <shookie <at> email.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 13848 <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Tue, 05 Mar 2013 23:25:12 +0100

Gettext was installed. Actually I don't know any linux distributions 
where it isn't installed by default.

On mingw the latest source snapshot tarball (after taking care of the 
struct timespec trouble) ends in a compilation error on I can't really 
make any sense off:

  SNARF  numbers.x
numbers.c:7643:5: error: missing binary operator before token "("

Seems to be another I'll handled pre-processor guard.

So for now I just get some of my actual work done under linux with the 
normal 2.0.7 tarball and my mentioned changes and wait for 2.0.8. Then 
I'll try again and will find some new and some of the same old problems 
again and go from there and probably write again. And then I'm probably 
gonna wait for the 2.0.9 tarball with some new and some old problems, 
and write again.

Regards

Jan Schukat

On 03/05/2013 06:25 PM, Ludovic Courtès wrote:
> Jan Schukat<shookie <at> email.de>  skribis:
>
>> autoreconf demanded automake 1.12, which isn't available via .debs on
>> ubuntu yet, so I installed that from the sources.
>>
>> after that I get this error message:
>>
>> configure.ac:873: warning: macro 'AM_GNU_GETTEXT' not found in library
>> autoreconf: running: /usr/bin/autoconf --force
>> configure.ac:900: error: possibly undefined macro: AM_GNU_GETTEXT
>>        If this token and others are legitimate, please use m4_pattern_allow.
>>        See the Autoconf documentation.
>> autoreconf: /usr/bin/autoconf failed with exit status: 1
> You need to install the ‘gettext’ package and re-run autoreconf.
>
> Even easier: grab a tarball from
> <http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest>.
>
> Note that the reason I’m suggesting using the latest 2.0 is to fix file
> name problems on MinGW.  So you can take the tarball from the above URL,
> and build from there on MinGW.
>
> Ludo’.

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Jan Schukat <shookie <at> email.de>
Cc: 13848 <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Thu, 07 Mar 2013 00:12:38 +0100

Jan Schukat <shookie <at> email.de> skribis:

> On mingw the latest source snapshot tarball (after taking care of the
> struct timespec trouble) ends in a compilation error on I can't really
> make any sense off:
>
>   SNARF  numbers.x
> numbers.c:7643:5: error: missing binary operator before token "("

This is fixed by commit 6db7ee7 of the ‘stable-2.0’ branch (it will be
in 2.0.8).  Can you try from a tarball at
<http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest/download>?
(Wait for an hour so that the build farm has time to catch up.)

Thanks,
Ludo’.

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

From: Andy Wingo <wingo <at> pobox.com>
To: Jan Schukat <shookie <at> email.de>
Cc: 13848 <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Sat, 09 Mar 2013 10:32:32 +0100

Hi,

On Fri 01 Mar 2013 17:19, Jan Schukat <shookie <at> email.de> writes:

> But compiling guile-2.0 on MinGW is a very hairy undertaking. I'm not
> sure how often it is tested by the developers.

Approximately never, unfortunately.  However we have been improving it
recently, and cross-compiling from GNU systems to MinGW is done
occasionally.

I will mostly address concerns about cross-compiling.  Note that you
should really be using Guile from stable-2.0 git and the latest MinGW.

The easiest way to do that is to install a Fedora 18 VM, because they
package mingw very well and are closest to upstream.  I'm a Debian user
and that's what I did, FWIW.  I haven't yet tried with Debian itself.

Also I would mention that dynamic linking should work on Windows, if all
your DLLs are in the same folder.  But I am ignorant and maybe that
doesn't work.

> Also, when you link statically and the symbol resolving works
> differently, you have to go through some hoops to resolve boehm-gc
> symbols, despite the preprocessor guards: That concerns
> HAVE_GC_SET_FINALIZER_NOTIFIER, HAVE_GC_GET_HEAP_USAGE_SAFE,
> HAVE_GC_GET_FREE_SPACE_DIVISOR, HAVE_GC_SET_FINALIZE_ON_DEMAND. In guile
> there are statically defined fallbacks for the respective functions,
> that cause linker conflicts when statically linked. Those functions
> probably should be renamed completely to prevent this kind of problem.

Are you saying that symbols with internal, static linkage inside bdw-gc
conflict with static symbols inside Guile?  This sounds like a
misconfiguration issue.

> Then there is also the old problem of the conflicting definitions of
> struct timespec on MinGW in time.h and pthreads.h.

FWIW I did not experience this in my cross-compile.

> The bug #13768 about scm_getpid being used in "--without-posix" builds I
> have sent already.

Fixed upstream; thanks.

> Also, on mingw the guile-tools/guild copy script can't deal with the
> .exe ending. I have to configure and make once with
> --program-suffix=.exe to create the proper script names and files, and
> then again without, so they can be copied. (or find and copy them by
> hand between builds)

Are you certain that the meta/guile and meta/guild scripts need the .exe
extension?  They are not EXE files.  MinGW should add on .exe to
programs like libguile/guile (NB: not meta/guile) as needed.

Also note that I just fixed a bug in meta/guile in which it was
referencing libguile/guile without the @EXEEXT@.

Basically I think --program-suffix is not what you want.

> But then on install (processing .texi files) guile.exe fails with this
> message:
>
> "Throw without catch before boot:
> Throw to key system-error with args ("canonicalize-path" "~A" ("No such
> file or directory") (2))Aborting.

This is fixed in git, I believe.

I think we're close.  Can you give it another try?  If needed I can
handle the autogen side of things and give you a freshly prepared
tarball.

Andy
-- 
http://wingolog.org/

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

From: Jan Schukat <shookie <at> email.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 13848 <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Sat, 09 Mar 2013 14:44:58 +0100

Sorry for the long time waiting. As I said, I had to get some real work 
done.

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

This one to be exact. On windows7 with mingw this is the result:


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
See `config.log' for more details
make: *** [lib/lib/libguile-2.0.a] Error 77


and config.log says:

configure:5226: $? = 0
configure:5215: gcc -v >&5
Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.7.2/configure 
--enable-languages=c,c++,ada,fortran,objc,obj-c++ 
--disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp 
--disable-win32-registry --enable-libstdcxx-debug 
--disable-build-poststage1-with-cxx 
--enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.7.2 (GCC)
configure:5226: $? = 0
configure:5215: gcc -V >&5
gcc.exe: error: unrecognized command line option '-V'
gcc.exe: fatal error: no input files
compilation terminated.


Regards

Jan Schukat

On 03/07/2013 12:12 AM, Ludovic Courtès wrote:
> Jan Schukat <shookie <at> email.de> skribis:
>
>> On mingw the latest source snapshot tarball (after taking care of the
>> struct timespec trouble) ends in a compilation error on I can't really
>> make any sense off:
>>
>>    SNARF  numbers.x
>> numbers.c:7643:5: error: missing binary operator before token "("
> This is fixed by commit 6db7ee7 of the ‘stable-2.0’ branch (it will be
> in 2.0.8).  Can you try from a tarball at
> <http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest/download>?
> (Wait for an hour so that the build farm has time to catch up.)
>
> Thanks,
> Ludo’.

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

From: Jan Schukat <shookie <at> email.de>
To: Andy Wingo <wingo <at> pobox.com>
Cc: 13848 <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Sat, 09 Mar 2013 16:42:22 +0100

[Message part 1 (text/plain, inline)]

On 03/09/2013 10:32 AM, Andy Wingo wrote:
> Hi,
>
> On Fri 01 Mar 2013 17:19, Jan Schukat<shookie <at> email.de>  writes:
>
>> But compiling guile-2.0 on MinGW is a very hairy undertaking. I'm not
>> sure how often it is tested by the developers.
> Approximately never, unfortunately.  However we have been improving it
> recently, and cross-compiling from GNU systems to MinGW is done
> occasionally.
>
> I will mostly address concerns about cross-compiling.  Note that you
> should really be using Guile from stable-2.0 git and the latest MinGW.
>
> The easiest way to do that is to install a Fedora 18 VM, because they
> package mingw very well and are closest to upstream.  I'm a Debian user
> and that's what I did, FWIW.  I haven't yet tried with Debian itself.
>
> Also I would mention that dynamic linking should work on Windows, if all
> your DLLs are in the same folder.  But I am ignorant and maybe that
> doesn't work.

Well, I really do my linux builds and most development on linux: that's 
the uname -a:

Linux solon 3.5.0-26-generic #40-Ubuntu SMP Tue Feb 26 19:59:36 UTC 2013 
i686 athlon i686 GNU/Linux

My windows builds I really do on windows7/mingw, the uname -a there:

MINGW32_NT-6.1 BIAS 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys

I haven't even tried to do any of that guile building on OSX, and as I 
understand cross-compiling from Linux to OSX is more or less 
impossible/a nightmare (the VLC guys do it though I think), so I will do 
it on my old iMac too.

I really would like to do all 3 targets via cross compiles some day 
(especially since compilation on linux is the fastest by far), but for 
now I just want to get it to work and have something to build on.


>> Also, when you link statically and the symbol resolving works
>> differently, you have to go through some hoops to resolve boehm-gc
>> symbols, despite the preprocessor guards: That concerns
>> HAVE_GC_SET_FINALIZER_NOTIFIER, HAVE_GC_GET_HEAP_USAGE_SAFE,
>> HAVE_GC_GET_FREE_SPACE_DIVISOR, HAVE_GC_SET_FINALIZE_ON_DEMAND. In guile
>> there are statically defined fallbacks for the respective functions,
>> that cause linker conflicts when statically linked. Those functions
>> probably should be renamed completely to prevent this kind of problem.
> Are you saying that symbols with internal, static linkage inside bdw-gc
> conflict with static symbols inside Guile?  This sounds like a
> misconfiguration issue.
That problem I really have on Linux too. I build my own gc for static 
linking, and I pass the relevant environment variables to configure (I 
don't rely in pkg-config, because it is not easily available on windows) 
.You should be able to reproduce it, with my little test project. But 
when I don't pass those CPP guards to configure, I get compile errors.

>> Then there is also the old problem of the conflicting definitions of
>> struct timespec on MinGW in time.h and pthreads.h.
> FWIW I did not experience this in my cross-compile.
That's a very old and nasty problem with the pthread headers on windows. 
When I was searching I found people having problems with that for years 
and years.

>
>> The bug #13768 about scm_getpid being used in "--without-posix" builds I
>> have sent already.
> Fixed upstream; thanks.
>
>> Also, on mingw the guile-tools/guild copy script can't deal with the
>> .exe ending. I have to configure and make once with
>> --program-suffix=.exe to create the proper script names and files, and
>> then again without, so they can be copied. (or find and copy them by
>> hand between builds)
> Are you certain that the meta/guile and meta/guild scripts need the .exe
> extension?  They are not EXE files.  MinGW should add on .exe to
> programs like libguile/guile (NB: not meta/guile) as needed.
>
> Also note that I just fixed a bug in meta/guile in which it was
> referencing libguile/guile without the @EXEEXT@.
>
> Basically I think --program-suffix is not what you want.

I guess You can really only reproduce that on windows, since that really 
has to do with how windows treats paths and executable file names.
>> But then on install (processing .texi files) guile.exe fails with this
>> message:
>>
>> "Throw without catch before boot:
>> Throw to key system-error with args ("canonicalize-path" "~A" ("No such
>> file or directory") (2))Aborting.
> This is fixed in git, I believe.
>
> I think we're close.  Can you give it another try?  If needed I can
> handle the autogen side of things and give you a freshly prepared
> tarball.
I tried today with this tarball: 
http://hydra.nixos.org/build/4290536/download/3/guile-2.0.7.157-929d1.tar.gz
Seems to have a gcc check error where a capital -V option is passed and 
it fails. Summary in previous email to this bug thread.

> Andy

I will keep trying of course. I can foresee a lot of problems with 
libreadline and similar loadable modules that use external dynamic 
libraries that don't come in a standard windows install on windows too. 
But I plan to make some changes/patches to the load paths anyway, so 
they work the same everywhere for my program, so I can address that there.

But until then I first need to get something that properly builds 
everywhere reliably.


Regards

Jan Schukat

[guiletest.tgz (application/x-compressed-tar, attachment)]

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

From: Andy Wingo <wingo <at> pobox.com>
To: Jan Schukat <shookie <at> email.de>
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 00:06:24 +0100

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.

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.

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/

Message #44 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 00:57:31 +0100

Oh, a present :)

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

Will do that at some point tonight.

> 
>> 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.

Don't really see how, considering the old tar balls didn't have that problem and that the log file definitely says that gcc gets called with a command line option (-V) that would be illegal on any 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.
> 

I'm using standard mingw/msys for this, those have gcc 4.7 already.  All the compilers in cygwin (mingw or not) are still stuck at 4.5. And I assume all other packages lack similarly behind.

> 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/

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

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

From: Andy Wingo <wingo <at> pobox.com>
To: shookie <at> email.de
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 18:32:14 +0100

Hi :)

On Sun 10 Mar 2013 05:09, shookie <at> email.de writes:

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

How do you handle it, for the record?

I assume you are using pthreads-w32?

> 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'

You can build bdw-gc without threads, and then build Guile without
threads.  In my builds I was doing --enable-threads=posix.

> 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]

You passed the `GEN guile-procedures.texi' phase?  If so, things are
already going well.  That's the first time the newly built Guile is
used, and if it went through it means at least you have a functional
Guile.

This problem sounds similar to something Eli Zaretskii reported:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10474#14:

   The next problem is here:

          GUILEC ice-9/eval.go
        Backtrace:
        In unknown file:
   	?: 5 [boot-closure #t #<catch-closure 231fd40> ...]
   	?: 4 [catch-closure]
   	?: 3 [primitive-eval ((@ # %) (begin # # #))]
   	?: 2 [chmod #<input-output: ice-9/eval.go.9IiPxC 6> 438]
   	?: 1 [boot-closure system-error "chmod" ...]
   	?: 0 [delete-file "ice-9/eval.go.9IiPxC"]

        ERROR: In procedure delete-file:
        ERROR: In procedure delete-file: Permission denied

   This happens because Guile calls fchmod, which is #define'd to -1 on
   MinGW.

However the code is different now, than it was when Eli made his report;
now if you don't have fchmod (as mingw does not), chmod only accepts
strings -- and here it seems that we are trying to chmod a port.  I will
see what I can do here.

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

No I have not.  I would like to do so, but am not really equipped for it
at the moment.  Your feedback here is really appreciated, thanks :)

Andy
-- 
http://wingolog.org/

Message #53 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 18:38:08 +0100

Ok, the guile compilation, apart from being exceptionally slow and spouting the mentioned backtraces, is also an infinite loop in the build process on my windows/mingw.

I guess I adapt my Makefile to fully support cross compilation and make patches to guile load path initialization so that it becomes relative to the executable on windows (and osx too), since you can't rely on absolute paths there and on guile even being available. Will probably take a long while, since I got other stuff to do next week too.

When I got results with that, I'm gonna write again probably due to new problems.

Regards

Jan Schukat


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.
> 
> 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.
> 
> 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/

Message #56 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 18:38:08 +0100

Ok, the guile compilation, apart from being exceptionally slow and spouting the mentioned backtraces, is also an infinite loop in the build process on my windows/mingw.

I guess I adapt my Makefile to fully support cross compilation and make patches to guile load path initialization so that it becomes relative to the executable on windows (and osx too), since you can't rely on absolute paths there and on guile even being available. Will probably take a long while, since I got other stuff to do next week too.

When I got results with that, I'm gonna write again probably due to new problems.

Regards

Jan Schukat


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.
> 
> 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.
> 
> 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/

Message #59 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 19:54:22 +0100

On 10.03.2013, at 18:32, Andy Wingo <wingo <at> pobox.com> wrote:

> Hi :)
> 
> On Sun 10 Mar 2013 05:09, shookie <at> email.de writes:
> 
>> The struct timespec is still an issue in a mingw build on windows, but
>> I know how to handle it.
> 
> How do you handle it, for the record?


by adding 

#ifndef _TIMESPEC_DEFINED
struct timespec {
        time_t tv_sec;
        long tv_nsec;
};
#endif

to lib/stat-time.h and libguile/threads.c.  Don't particularly like it, but that's what works. If you don't wanna make that part of the main source tree, I got no problem making a patch part of my build process. I gotta do some patching anyway to be able to have relative/runtime initialized load paths on windows.

> 
> I assume you are using pthreads-w32?

/* This is an implementation of the threads API of POSIX 1003.1-2001.
 *
 * --------------------------------------------------------------------------
 *
 *      Pthreads-win32 - POSIX Threads Library for Win32
 *      Copyright(C) 1998 John E. Bossom
 *      Copyright(C) 1999,2005 Pthreads-win32 contributors
 *
 *      Contact Email: rpj <at> callisto.canberra.edu.au


That's what the pthread.h says.

> 
>> 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'
> 
> You can build bdw-gc without threads, and then build Guile without
> threads.  In my builds I was doing --enable-threads=posix.
> 
>> 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]
> 
> You passed the `GEN guile-procedures.texi' phase?  If so, things are
> already going well.  That's the first time the newly built Guile is
> used, and if it went through it means at least you have a functional
> Guile.
> 
> This problem sounds similar to something Eli Zaretskii reported:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10474#14:
> 
>   The next problem is here:
> 
>          GUILEC ice-9/eval.go
>        Backtrace:
>        In unknown file:
>   	?: 5 [boot-closure #t #<catch-closure 231fd40> ...]
>   	?: 4 [catch-closure]
>   	?: 3 [primitive-eval ((@ # %) (begin # # #))]
>   	?: 2 [chmod #<input-output: ice-9/eval.go.9IiPxC 6> 438]
>   	?: 1 [boot-closure system-error "chmod" ...]
>   	?: 0 [delete-file "ice-9/eval.go.9IiPxC"]
> 
>        ERROR: In procedure delete-file:
>        ERROR: In procedure delete-file: Permission denied
> 
>   This happens because Guile calls fchmod, which is #define'd to -1 on
>   MinGW.
> 
> However the code is different now, than it was when Eli made his report;
> now if you don't have fchmod (as mingw does not), chmod only accepts
> strings -- and here it seems that we are trying to chmod a port.  I will
> see what I can do here.

Sounds promising!

Regards

Jan Schukat


P.S. I guess I append some more info, namely my configure command line, and the most interesting build output section (after that its mostly backtraces from guile compiling):

./configure --prefix=/c/Users/shookie/guiletest/lib --disable-shared --disable-fast-install --with-gnu-ld  --disable-deprecated --enable-nls --with-libgmp-prefix=/c/Users/shookie/guiletest/lib  LIBFFI_CFLAGS='-I/c/Use
rs/shookie/guiletest/lib/lib/libffi-3.0.12/include' LIBFFI_LIBS='-lffi' BDW_GC_LIBS='-lgc' BDW_GC_CFLAGS='-I/c/Users/shookie/guiletest/lib' CPPFLAGS='-D HAVE_GC_SET_FINALIZER_NOTIFIER -D HAVE_GC_GET_FREE_SPACE_DIVISOR -D HAVE_GC_GET_HEAP
_USAGE_SAFE -D HAVE_GC_SET_FINALIZE_ON_DEMAND' CFLAGS='-s' && make install

….


  CC       libguile_2.0_la-threads.lo
threads.c: In function 'scm_pthread_cond_timedwait':
threads.c:2006:3: warning: passing argument 3 of 'pthread_cond_timedwait' from incompatible pointer type [enabled by default]
In file included from ../lib/time.h:369:0,
                 from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/sys/time.h:3,
                 from ../lib/sys/time.h:30,
                 from ../libguile/scmconfig.h:26,
                 from ../libguile/bdw-gc.h:24,
                 from threads.c:27:
c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/pthread.h:1097:31: note: expected 'const struct timespec *' but argument is of type 'const struct scm_t_timespec *'
  CC       libguile_2.0_la-throw.lo
  CC       libguile_2.0_la-trees.lo
  CC       libguile_2.0_la-uniform.lo
  CC       libguile_2.0_la-values.lo
  CC       libguile_2.0_la-variable.lo
  CC       libguile_2.0_la-vectors.lo
  CC       libguile_2.0_la-version.lo
  CC       libguile_2.0_la-vm.lo
  CC       libguile_2.0_la-vports.lo
  CC       libguile_2.0_la-weaks.lo
  CCLD     libguile-2.0.la
libtool: link: warning: library `c:/mingw/lib/libunistring.la' was moved.
copying selected object files to avoid basename conflicts...
  CC       guile-guile.o
  CCLD     guile.exe
libtool: link: warning: library `c:/mingw/lib/libunistring.la' was moved.
  GEN      guile-procedures.texi
rm -f guile-procedures.txt
makeinfo --force -o guile-procedures.txt guile-procedures.texi || test -f guile-procedures.txt
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:10246: Cross reference to nonexistent node `Backslash Escapes' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:9941: Cross reference to nonexistent node `Network Address Conversion' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:9880: Cross reference to nonexistent node `Network Databases' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:9830: Cross reference to nonexistent node `Network Databases' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:9304: Cross reference to nonexistent node `Hash Tables' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:9297: Cross reference to nonexistent node `Hash Tables' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:9290: Cross reference to nonexistent node `Hash Tables' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:9204: Cross reference to nonexistent node `File Ports' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:8569: Cross reference to nonexistent node `Vtables' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:8187: Cross reference to nonexistent node `Locales' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:8006: Cross reference to nonexistent node `Bitwise Operations' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:6697: Cross reference to nonexistent node `Character Sets' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:6675: Cross reference to nonexistent node `Character Sets' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:6619: Cross reference to nonexistent node `Multiple Values' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:5563: Cross reference to nonexistent node `File Ports' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:5272: Cross reference to nonexistent node `Ports and File Descriptors' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:5261: Cross reference to nonexistent node `Ports and File Descriptors' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:5250: Cross reference to nonexistent node `Ports and File Descriptors' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:3319: Cross reference to nonexistent node `File Ports' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:3126: Cross reference to nonexistent node `Locales' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:2797: Cross reference to nonexistent node `Hash Tables' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:2790: Cross reference to nonexistent node `Hash Tables' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:2783: Cross reference to nonexistent node `Hash Tables' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:2213: Cross reference to nonexistent node `Character Encoding of Source Files' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:2207: Cross reference to nonexistent node `Ports and File Descriptors' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:2189: Cross reference to nonexistent node `Ports and File Descriptors' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:1575: Cross reference to nonexistent node `Ports and File Descriptors' (perhaps incorrect sectioning?).
/c/Users/shookie/guiletest/lib/guile-2.0/libguile//guile-procedures.texi:1563: Cross reference to nonexistent node `Closing' (perhaps incorrect sectioning?).
make[5]: Entering directory `/c/Users/shookie/guiletest/lib/guile-2.0/libguile'
 /bin/mkdir -p '/c/Users/user/guiletest/lib/lib'

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

From: Andy Wingo <wingo <at> pobox.com>
To: shookie <at> email.de
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 20:23:38 +0100

On Sun 10 Mar 2013 18:32, Andy Wingo <wingo <at> pobox.com> writes:

>> 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]

I have made what might be a fix for this issue.  Can you try this
tarball:

  http://wingolog.org/priv/guile-2.0.7.182-e9381.tar.gz

Thanks,

Andy
-- 
http://wingolog.org/

Message #65 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 22:17:14 +0100

I immediately tried it. And after the time spec fixes it looks good so far. The first few GUILECs came through without a hitch. It takes ages though. So might be a while until you hear from me gain.

Regards

Jan Schukat




On 10.03.2013, at 20:23, Andy Wingo <wingo <at> pobox.com> wrote:

> On Sun 10 Mar 2013 18:32, Andy Wingo <wingo <at> pobox.com> writes:
> 
>>> 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]
> 
> I have made what might be a fix for this issue.  Can you try this
> tarball:
> 
>  http://wingolog.org/priv/guile-2.0.7.182-e9381.tar.gz
> 
> Thanks,
> 
> Andy
> -- 
> http://wingolog.org/

Message #68 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 23:03:08 +0100

Ok, came pretty far, but then, during the GUILEC phase it started complaining that "poll" is not available, poll.go was't created then, and finally it failed to install poll.go

Here's the log. I tried it both with and without posix and threads enabled.



wrote `web/server.go'
  GUILEC web/server/http.go
Backtrace:
In system/base/compile.scm:
 153: 19 [#<procedure 1f1e400 at system/base/compile.scm:151:8 (port)> #<closed: file 0>]
 216: 18 [read-and-compile #<input: web/server/http.scm 5> #:from ...]
 232: 17 [lp () #f #<module (#{ g96}#) 1f5e900>]
 180: 16 [lp (#<procedure compile-tree-il (x e opts)>) (define-module # # ...) ...]
In ice-9/boot-9.scm:
2191: 15 [save-module-excursion #<procedure 21348e8 at language/scheme/compile-tree-il.scm:29:3 ()>]
In language/scheme/compile-tree-il.scm:
  31: 14 [#<procedure 21348e8 at language/scheme/compile-tree-il.scm:29:3 ()>]
In ice-9/psyntax.scm:
1091: 13 [expand-top-sequence ((define-module # # # ...)) () ((top)) ...]
 976: 12 [scan ((define-module (web server http) #:use-module ...)) () ...]
 270: 11 [scan ((#(syntax-object let # ...) (#) (# #) ...)) () ...]
In ice-9/eval.scm:
 411: 10 [eval # ()]
In ice-9/boot-9.scm:
2741: 9 [define-module* (web server http) #:filename ...]
2716: 8 [resolve-imports ((# # #) (#) (#) (#) ...)]
2654: 7 [resolve-interface (ice-9 poll) #:select ...]
2579: 6 [#<procedure 1d54f70 at ice-9/boot-9.scm:2567:4 (name #:optional autoload version #:key ensure)> # ...]
2850: 5 [try-module-autoload (ice-9 poll) #f]
2191: 4 [save-module-excursion #<procedure 21cde70 at ice-9/boot-9.scm:2851:17 ()>]
2870: 3 [#<procedure 21cde70 at ice-9/boot-9.scm:2851:17 ()>]
In unknown file:
   ?: 2 [primitive-load-path "ice-9\\poll" ...]
   ?: 1 [load-extension "libguile-2.0" "scm_init_poll"]
In ice-9/boot-9.scm:
 106: 0 [#<procedure 1f1e3a0 at ice-9/boot-9.scm:97:6 (thrown-k . args)> misc-error ...]

ice-9/boot-9.scm:106:20: In procedure #<procedure 1f1e3a0 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
ice-9/boot-9.scm:106:20: In procedure %init-poll: `poll' unavailable on this platform
  GUILEC web/uri.go
wrote `web/uri.go'
make[4]: Entering directory `/c/Users/shookie/guiletest/lib/guile-2.0/module'
make[4]: Nothing to be done for `install-exec-am'.
  GUILEC ice-9/poll.go
Backtrace:
In ice-9/eval.scm:
 432: 19 [eval # #]
 387: 18 [eval # #]
In srfi/srfi-1.scm:
 619: 17 [for-each #<procedure 1f10ac0 at scripts/compile.scm:179:14 (file)> #]
In scripts/compile.scm:
 182: 16 [#<procedure 1f10ac0 at scripts/compile.scm:179:14 (file)> "ice-9/poll.scm"]
In system/base/target.scm:
  59: 15 [with-target "i686-pc-mingw32" ...]
In system/base/compile.scm:
 150: 14 [compile-file "ice-9/poll.scm" #:output-file ...]
  43: 13 [call-once #<procedure 1f103e0 at system/base/compile.scm:56:5 ()>]
In ice-9/boot-9.scm:
 171: 12 [with-throw-handler #t ...]
In system/base/compile.scm:
  59: 11 [#<procedure 1f103c0 at system/base/compile.scm:58:9 ()>]
 153: 10 [#<procedure 1f10400 at system/base/compile.scm:151:8 (port)> #<closed: file 0>]
 216: 9 [read-and-compile #<input: ice-9/poll.scm 5> #:from ...]
 232: 8 [lp (#<tree-il (let # # ...)>) #<directory (ice-9 poll) 214ddc8> ...]
 180: 7 [lp (#<procedure compile-tree-il (x e opts)>) (eval-when # #) ...]
In ice-9/boot-9.scm:
2191: 6 [save-module-excursion #<procedure 2158c18 at language/scheme/compile-tree-il.scm:29:3 ()>]
In language/scheme/compile-tree-il.scm:
  31: 5 [#<procedure 2158c18 at language/scheme/compile-tree-il.scm:29:3 ()>]
In ice-9/psyntax.scm:
1091: 4 [expand-top-sequence ((eval-when # #)) () ((top)) ...]
 976: 3 [scan ((eval-when # #)) () ((top)) ...]
 270: 2 [scan ((load-extension # "scm_init_poll")) () ((top)) ...]
In unknown file:
   ?: 1 [load-extension "libguile-2.0" "scm_init_poll"]
In ice-9/boot-9.scm:
 106: 0 [#<procedure 1f103a0 at ice-9/boot-9.scm:97:6 (thrown-k . args)> misc-error ...]

ice-9/boot-9.scm:106:20: In procedure #<procedure 1f103a0 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
ice-9/boot-9.scm:106:20: In procedure %init-poll: `poll' unavailable on this platform
  GUILEC scripts/autofrisk.go
Backtrace:
In ice-9/psyntax.scm:
1101: 19 [expand-top-sequence ((define (unglob pattern) (let # #))) () ...]
1259: 18 [#<procedure 2181540 at ice-9/psyntax.scm:1067:36 ()>]
1605: 17 [expand-simple-lambda (# . #) () (()) ...]
1509: 16 [parse (((# #) . #(syntax-object # # #))) () () () () () ()]
In ice-9/boot-9.scm:
 627: 15 [map #<procedure 21add50 at ice-9/psyntax.scm:1510:50 (x)> ((# . #))]
In ice-9/psyntax.scm:
2114: 14 [expand-let (let # #) (# #) (# # #) ...]
In ice-9/boot-9.scm:
 627: 13 [map #<procedure 21acf20 at ice-9/psyntax.scm:2114:49 (x)> (#)]
In ice-9/psyntax.scm:
1257: 12 [#<procedure 21acf20 at ice-9/psyntax.scm:2114:49 (x)> (open-input-pipe #)]
1186: 11 [syntax-type (open-input-pipe #) (# #) (# # #) ...]
 579: 10 [syntax-type open-input-pipe (# #) (# # #) ...]
 292: 9 [get-global-definition-hook open-input-pipe (hygiene scripts autofrisk)]
In unknown file:
   ?: 8 [module-variable #<directory (scripts autofrisk) 214ddc8> open-input-pipe]
In ice-9/boot-9.scm:
2790: 7 [b #<autoload (ice-9 popen) 214d6c0> open-input-pipe #f]
2579: 6 [#<procedure 1d53f50 at ice-9/boot-9.scm:2567:4 (name #:optional autoload version #:key ensure)> # ...]
2850: 5 [try-module-autoload (ice-9 popen) #f]
2191: 4 [save-module-excursion #<procedure 21adc60 at ice-9/boot-9.scm:2851:17 ()>]
2870: 3 [#<procedure 21adc60 at ice-9/boot-9.scm:2851:17 ()>]
In unknown file:
   ?: 2 [primitive-load-path "ice-9\\popen" ...]
   ?: 1 [load-extension "libguile-2.0" "scm_init_popen"]
In ice-9/boot-9.scm:
 106: 0 [#<procedure 1f103a0 at ice-9/boot-9.scm:97:6 (thrown-k . args)> misc-error ...]

ice-9/boot-9.scm:106:20: In procedure #<procedure 1f103a0 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
ice-9/boot-9.scm:106:20: In procedure dynamic-link: file: "libguile-2.0", message: "The specified module could not be found."
  GUILEC scripts/scan-api.go
Backtrace:
In system/base/compile.scm:
 153: 19 [#<procedure 1f10400 at system/base/compile.scm:151:8 (port)> #<closed: file 0>]
 216: 18 [read-and-compile #<input: scripts/scan-api.scm 5> #:from ...]
 232: 17 [lp () #f #<module (#{ g96}#) 1f51900>]
 180: 16 [lp # # # ...]
In ice-9/boot-9.scm:
2191: 15 [save-module-excursion #<procedure 2107840 at language/scheme/compile-tree-il.scm:29:3 ()>]
In language/scheme/compile-tree-il.scm:
  31: 14 [#<procedure 2107840 at language/scheme/compile-tree-il.scm:29:3 ()>]
In ice-9/psyntax.scm:
1091: 13 [expand-top-sequence ((define-module # :use-module # ...)) () ((top)) ...]
 976: 12 [scan ((define-module (scripts scan-api) :use-module ...)) () ...]
 270: 11 [scan ((#(syntax-object let # ...) (#) (# #) ...)) () ...]
In ice-9/eval.scm:
 411: 10 [eval # ()]
In ice-9/boot-9.scm:
2741: 9 [define-module* (scripts scan-api) #:filename ...]
2716: 8 [resolve-imports (((ice-9 popen)) ((ice-9 rdelim)) ((ice-9 regex)))]
2654: 7 [resolve-interface (ice-9 popen) #:select ...]
2579: 6 [#<procedure 1d53f70 at ice-9/boot-9.scm:2567:4 (name #:optional autoload version #:key ensure)> # ...]
2850: 5 [try-module-autoload (ice-9 popen) #f]
2191: 4 [save-module-excursion #<procedure 2134108 at ice-9/boot-9.scm:2851:17 ()>]
2870: 3 [#<procedure 2134108 at ice-9/boot-9.scm:2851:17 ()>]
In unknown file:
   ?: 2 [primitive-load-path "ice-9\\popen" ...]
   ?: 1 [load-extension "libguile-2.0" "scm_init_popen"]
In ice-9/boot-9.scm:
 106: 0 [#<procedure 1f103a0 at ice-9/boot-9.scm:97:6 (thrown-k . args)> misc-error ...]

ice-9/boot-9.scm:106:20: In procedure #<procedure 1f103a0 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
ice-9/boot-9.scm:106:20: In procedure dynamic-link: file: "libguile-2.0", message: "The specified module could not be found."
  GUILEC web/server/http.go
Backtrace:
In system/base/compile.scm:
 153: 19 [#<procedure 1f1b400 at system/base/compile.scm:151:8 (port)> #<closed: file 0>]
 216: 18 [read-and-compile #<input: web/server/http.scm 5> #:from ...]
 232: 17 [lp () #f #<module (#{ g96}#) 1f5b900>]
 180: 16 [lp (#<procedure compile-tree-il (x e opts)>) (define-module # # ...) ...]
In ice-9/boot-9.scm:
2191: 15 [save-module-excursion #<procedure 2112960 at language/scheme/compile-tree-il.scm:29:3 ()>]
In language/scheme/compile-tree-il.scm:
  31: 14 [#<procedure 2112960 at language/scheme/compile-tree-il.scm:29:3 ()>]
In ice-9/psyntax.scm:
1091: 13 [expand-top-sequence ((define-module # # # ...)) () ((top)) ...]
 976: 12 [scan ((define-module (web server http) #:use-module ...)) () ...]
 270: 11 [scan ((#(syntax-object let # ...) (#) (# #) ...)) () ...]
In ice-9/eval.scm:
 411: 10 [eval # ()]
In ice-9/boot-9.scm:
2741: 9 [define-module* (web server http) #:filename ...]
2716: 8 [resolve-imports ((# # #) (#) (#) (#) ...)]
2654: 7 [resolve-interface (ice-9 poll) #:select ...]
2579: 6 [#<procedure 1d53f60 at ice-9/boot-9.scm:2567:4 (name #:optional autoload version #:key ensure)> # ...]
2850: 5 [try-module-autoload (ice-9 poll) #f]
2191: 4 [save-module-excursion #<procedure 2304db0 at ice-9/boot-9.scm:2851:17 ()>]
2870: 3 [#<procedure 2304db0 at ice-9/boot-9.scm:2851:17 ()>]
In unknown file:
   ?: 2 [primitive-load-path "ice-9\\poll" ...]
   ?: 1 [load-extension "libguile-2.0" "scm_init_poll"]
In ice-9/boot-9.scm:
 106: 0 [#<procedure 1f1b3a0 at ice-9/boot-9.scm:97:6 (thrown-k . args)> misc-error ...]

ice-9/boot-9.scm:106:20: In procedure #<procedure 1f1b3a0 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
ice-9/boot-9.scm:106:20: In procedure %init-poll: `poll' unavailable on this platform


 /bin/install -c -m 644  ice-9/psyntax-pp.go ice-9/boot-9.go ice-9/vlist.go ice-9/r4rs.go ice-9/r5rs.go ice-9/deprecated.go ice-9/and-let-star.go ice-9/binary-ports.go ice-9/calling.go ice-9/command-line.go ice-9/common-list.go ice-9/con
trol.go ice-9/curried-definitions.go ice-9/debug.go ice-9/documentation.go ice-9/eval-string.go ice-9/expect.go ice-9/format.go ice-9/futures.go ice-9/getopt-long.go ice-9/hcons.go ice-9/i18n.go ice-9/iconv.go ice-9/lineio.go ice-9/ls.go
 ice-9/mapping.go ice-9/match.go ice-9/networking.go ice-9/null.go ice-9/occam-channel.go ice-9/optargs.go ice-9/poe.go ./ice-9/poll.go ice-9/posix.go ice-9/q.go ice-9/rdelim.go ice-9/receive.go ice-9/regex.go ice-9/runq.go ice-9/rw.go '
/c/Users/shookie/guiletest/lib/lib/guile/2.0/ccache//ice-9'
/bin/install: cannot stat `./ice-9/poll.go': No such file or directory
make[4]: *** [install-nobase_ccacheDATA] Error 1
make[4]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0/module'
make[3]: *** [install-am] Error 2
make[3]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0/module'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0'
make: *** [lib/lib/libguile-2.0.a] Error 2





On 10.03.2013, at 20:23, Andy Wingo <wingo <at> pobox.com> wrote:

> On Sun 10 Mar 2013 18:32, Andy Wingo <wingo <at> pobox.com> writes:
> 
>>> 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]
> 
> I have made what might be a fix for this issue.  Can you try this
> tarball:
> 
>  http://wingolog.org/priv/guile-2.0.7.182-e9381.tar.gz
> 
> Thanks,
> 
> Andy
> -- 
> http://wingolog.org/

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

From: Andy Wingo <wingo <at> pobox.com>
To: shookie <at> email.de
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 23:53:01 +0100

On Sun 10 Mar 2013 23:03, shookie <at> email.de writes:

> Ok, came pretty far, but then, during the GUILEC phase it started
> complaining that "poll" is not available, poll.go was't created then,
> and finally it failed to install poll.go

Strange.  There are a few ways to work around this I guess but I ended
up importing the gnulib `poll' module, which will provide `poll' on
mingw.

Here's a new tarball:

  http://wingolog.org/priv/guile-2.0.7.187-b5870.tar.gz

I wonder about your compile slowness.  Could it be that somehow Guile is
not using the .go files that it is compiling?  Normally the compile
should be slow at the beginning, but as the bootstrap progresses, things
speed up.  I'm sure you've seen that when building on GNU/Linux.  Do you
not see that on your mingw build?

It sounds like we're getting really close :)

Andy
-- 
http://wingolog.org/

Message #74 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: Mon, 11 Mar 2013 01:07:08 +0100

It does get faster with time on windows too, yes, but it is overall about 3 times slower than linux compiles. But that's true for all the compiling I do on windows. Even VC projects tend to really slow compared to what I see on Linux (it is the same machine in dual boot). My guess is that this is primarily for IO reasons. There are a lot more tricks like pipes and the like that gcc and make can use on true posix systems.

I will try the new tar ball right now. You'll hear from me.

Regards

Jan Schukat

On 10.03.2013, at 23:53, Andy Wingo <wingo <at> pobox.com> wrote:

> On Sun 10 Mar 2013 23:03, shookie <at> email.de writes:
> 
>> Ok, came pretty far, but then, during the GUILEC phase it started
>> complaining that "poll" is not available, poll.go was't created then,
>> and finally it failed to install poll.go
> 
> Strange.  There are a few ways to work around this I guess but I ended
> up importing the gnulib `poll' module, which will provide `poll' on
> mingw.
> 
> Here's a new tarball:
> 
>  http://wingolog.org/priv/guile-2.0.7.187-b5870.tar.gz
> 
> I wonder about your compile slowness.  Could it be that somehow Guile is
> not using the .go files that it is compiling?  Normally the compile
> should be slow at the beginning, but as the bootstrap progresses, things
> speed up.  I'm sure you've seen that when building on GNU/Linux.  Do you
> not see that on your mingw build?
> 
> It sounds like we're getting really close :)
> 
> Andy
> -- 
> http://wingolog.org/

Message #77 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: Mon, 11 Mar 2013 02:43:31 +0100

Ok, another build that got a little further. Again, after putting my two timespec definitions in.

The next GUILEC to fail is this one, happens regardless of whether posix is enabled or disabled in configure:

  GUILEC scripts/autofrisk.go
Backtrace:
In ice-9/psyntax.scm:
1101: 19 [expand-top-sequence ((define (unglob pattern) (let # #))) () ...]
1259: 18 [#<procedure 2205150 at ice-9/psyntax.scm:1067:36 ()>]
1605: 17 [expand-simple-lambda (# . #) () (()) ...]
1509: 16 [parse (((# #) . #(syntax-object # # #))) () () () () () ()]
In ice-9/boot-9.scm:
 627: 15 [map #<procedure 223e8d0 at ice-9/psyntax.scm:1510:50 (x)> ((# . #))]
In ice-9/psyntax.scm:
2114: 14 [expand-let (let # #) (# #) (# # #) ...]
In ice-9/boot-9.scm:
 627: 13 [map #<procedure 223ab20 at ice-9/psyntax.scm:2114:49 (x)> (#)]
In ice-9/psyntax.scm:
1257: 12 [#<procedure 223ab20 at ice-9/psyntax.scm:2114:49 (x)> (open-input-pipe #)]
1186: 11 [syntax-type (open-input-pipe #) (# #) (# # #) ...]
 579: 10 [syntax-type open-input-pipe (# #) (# # #) ...]
 292: 9 [get-global-definition-hook open-input-pipe (hygiene scripts autofrisk)]
In unknown file:
   ?: 8 [module-variable #<directory (scripts autofrisk) 2184d80> open-input-pipe]
In ice-9/boot-9.scm:
2790: 7 [b #<autoload (ice-9 popen) 2216d80> open-input-pipe #f]
2579: 6 [#<procedure 1d05530 at ice-9/boot-9.scm:2567:4 (name #:optional autoload version #:key ensure)> # ...]
2850: 5 [try-module-autoload (ice-9 popen) #f]
2191: 4 [save-module-excursion #<procedure 223e7e0 at ice-9/boot-9.scm:2851:17 ()>]
2870: 3 [#<procedure 223e7e0 at ice-9/boot-9.scm:2851:17 ()>]
In unknown file:
   ?: 2 [primitive-load-path "ice-9\\popen" ...]
   ?: 1 [load-extension "libguile-2.0" "scm_init_popen"]
In ice-9/boot-9.scm:
 106: 0 [#<procedure 200ace0 at ice-9/boot-9.scm:97:6 (thrown-k . args)> misc-error ...]

ice-9/boot-9.scm:106:20: In procedure #<procedure 200ace0 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
ice-9/boot-9.scm:106:20: In procedure dynamic-link: file: "libguile-2.0", message: "The specified module could not be found."
make[3]: *** [scripts/autofrisk.go] Error 1
make[3]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0/module'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0'
make: *** [lib/lib/libguile-2.0.a] Error 2


On 10.03.2013, at 23:53, Andy Wingo <wingo <at> pobox.com> wrote:

> On Sun 10 Mar 2013 23:03, shookie <at> email.de writes:
> 
>> Ok, came pretty far, but then, during the GUILEC phase it started
>> complaining that "poll" is not available, poll.go was't created then,
>> and finally it failed to install poll.go
> 
> Strange.  There are a few ways to work around this I guess but I ended
> up importing the gnulib `poll' module, which will provide `poll' on
> mingw.
> 
> Here's a new tarball:
> 
>  http://wingolog.org/priv/guile-2.0.7.187-b5870.tar.gz
> 
> I wonder about your compile slowness.  Could it be that somehow Guile is
> not using the .go files that it is compiling?  Normally the compile
> should be slow at the beginning, but as the bootstrap progresses, things
> speed up.  I'm sure you've seen that when building on GNU/Linux.  Do you
> not see that on your mingw build?
> 
> It sounds like we're getting really close :)
> 
> Andy
> -- 
> http://wingolog.org/

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

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

On Mon 11 Mar 2013 02:43, shookie <at> email.de writes:

>   GUILEC scripts/autofrisk.go
> Backtrace:
> In ice-9/psyntax.scm:
> 1101: 19 [expand-top-sequence ((define (unglob pattern) (let # #))) () ...]
> 1259: 18 [#<procedure 2205150 at ice-9/psyntax.scm:1067:36 ()>]
> 1605: 17 [expand-simple-lambda (# . #) () (()) ...]
> 1509: 16 [parse (((# #) . #(syntax-object # # #))) () () () () () ()]
> In ice-9/boot-9.scm:
>  627: 15 [map #<procedure 223e8d0 at ice-9/psyntax.scm:1510:50 (x)> ((# . #))]
> In ice-9/psyntax.scm:
> 2114: 14 [expand-let (let # #) (# #) (# # #) ...]
> In ice-9/boot-9.scm:
>  627: 13 [map #<procedure 223ab20 at ice-9/psyntax.scm:2114:49 (x)> (#)]
> In ice-9/psyntax.scm:
> 1257: 12 [#<procedure 223ab20 at ice-9/psyntax.scm:2114:49 (x)> (open-input-pipe #)]
> 1186: 11 [syntax-type (open-input-pipe #) (# #) (# # #) ...]
>  579: 10 [syntax-type open-input-pipe (# #) (# # #) ...]
>  292: 9 [get-global-definition-hook open-input-pipe (hygiene scripts autofrisk)]
> In unknown file:
>    ?: 8 [module-variable #<directory (scripts autofrisk) 2184d80> open-input-pipe]
> In ice-9/boot-9.scm:
> 2790: 7 [b #<autoload (ice-9 popen) 2216d80> open-input-pipe #f]
> 2579: 6 [#<procedure 1d05530 at ice-9/boot-9.scm:2567:4 (name #:optional autoload version #:key ensure)> # ...]
> 2850: 5 [try-module-autoload (ice-9 popen) #f]
> 2191: 4 [save-module-excursion #<procedure 223e7e0 at ice-9/boot-9.scm:2851:17 ()>]
> 2870: 3 [#<procedure 223e7e0 at ice-9/boot-9.scm:2851:17 ()>]
> In unknown file:
>    ?: 2 [primitive-load-path "ice-9\\popen" ...]
>    ?: 1 [load-extension "libguile-2.0" "scm_init_popen"]
> In ice-9/boot-9.scm:
>  106: 0 [#<procedure 200ace0 at ice-9/boot-9.scm:97:6 (thrown-k . args)> misc-error ...]
>
> ice-9/boot-9.scm:106:20: In procedure #<procedure 200ace0 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
> ice-9/boot-9.scm:106:20: In procedure dynamic-link: file: "libguile-2.0", message: "The specified module could not be found."
> make[3]: *** [scripts/autofrisk.go] Error 1
> make[3]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0/module'
> make[2]: *** [install-recursive] Error 1
> make[2]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0'
> make[1]: *** [install] Error 2
> make[1]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0'
> make: *** [lib/lib/libguile-2.0.a] Error 2

Interesting; seems to be an instance of
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12202.

Can you try "make -k" and see what other errors you uncover?  At this
point it has compiled pretty much all of the needed code, using the
built guile, so we're really close.

Andy
-- 
http://wingolog.org/

Message #83 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: Mon, 11 Mar 2013 10:30:25 +0100

[Message part 1 (text/plain, inline)]

You're right, that wasn't a very efficient work process. So I attached two complete build logs with make -k. One with posix and threads, and one without.

Both have some slight differences, but the major hiccups happen at the same places: one is the autofrisk from be fore, the other is with the scan-api.

I'm definitely too tired now though to do anything productive. Good night.

Jan Schukat

[build1.log (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

[build.log (application/octet-stream, attachment)]

[Message part 5 (text/plain, inline)]

On 11.03.2013, at 09:26, Andy Wingo <wingo <at> pobox.com> wrote:

> On Mon 11 Mar 2013 02:43, shookie <at> email.de writes:
> 
>>  GUILEC scripts/autofrisk.go
>> Backtrace:
>> In ice-9/psyntax.scm:
>> 1101: 19 [expand-top-sequence ((define (unglob pattern) (let # #))) () ...]
>> 1259: 18 [#<procedure 2205150 at ice-9/psyntax.scm:1067:36 ()>]
>> 1605: 17 [expand-simple-lambda (# . #) () (()) ...]
>> 1509: 16 [parse (((# #) . #(syntax-object # # #))) () () () () () ()]
>> In ice-9/boot-9.scm:
>> 627: 15 [map #<procedure 223e8d0 at ice-9/psyntax.scm:1510:50 (x)> ((# . #))]
>> In ice-9/psyntax.scm:
>> 2114: 14 [expand-let (let # #) (# #) (# # #) ...]
>> In ice-9/boot-9.scm:
>> 627: 13 [map #<procedure 223ab20 at ice-9/psyntax.scm:2114:49 (x)> (#)]
>> In ice-9/psyntax.scm:
>> 1257: 12 [#<procedure 223ab20 at ice-9/psyntax.scm:2114:49 (x)> (open-input-pipe #)]
>> 1186: 11 [syntax-type (open-input-pipe #) (# #) (# # #) ...]
>> 579: 10 [syntax-type open-input-pipe (# #) (# # #) ...]
>> 292: 9 [get-global-definition-hook open-input-pipe (hygiene scripts autofrisk)]
>> In unknown file:
>>   ?: 8 [module-variable #<directory (scripts autofrisk) 2184d80> open-input-pipe]
>> In ice-9/boot-9.scm:
>> 2790: 7 [b #<autoload (ice-9 popen) 2216d80> open-input-pipe #f]
>> 2579: 6 [#<procedure 1d05530 at ice-9/boot-9.scm:2567:4 (name #:optional autoload version #:key ensure)> # ...]
>> 2850: 5 [try-module-autoload (ice-9 popen) #f]
>> 2191: 4 [save-module-excursion #<procedure 223e7e0 at ice-9/boot-9.scm:2851:17 ()>]
>> 2870: 3 [#<procedure 223e7e0 at ice-9/boot-9.scm:2851:17 ()>]
>> In unknown file:
>>   ?: 2 [primitive-load-path "ice-9\\popen" ...]
>>   ?: 1 [load-extension "libguile-2.0" "scm_init_popen"]
>> In ice-9/boot-9.scm:
>> 106: 0 [#<procedure 200ace0 at ice-9/boot-9.scm:97:6 (thrown-k . args)> misc-error ...]
>> 
>> ice-9/boot-9.scm:106:20: In procedure #<procedure 200ace0 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
>> ice-9/boot-9.scm:106:20: In procedure dynamic-link: file: "libguile-2.0", message: "The specified module could not be found."
>> make[3]: *** [scripts/autofrisk.go] Error 1
>> make[3]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0/module'
>> make[2]: *** [install-recursive] Error 1
>> make[2]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0'
>> make[1]: *** [install] Error 2
>> make[1]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0'
>> make: *** [lib/lib/libguile-2.0.a] Error 2
> 
> Interesting; seems to be an instance of
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12202.
> 
> Can you try "make -k" and see what other errors you uncover?  At this
> point it has compiled pretty much all of the needed code, using the
> built guile, so we're really close.
> 
> Andy
> -- 
> http://wingolog.org/

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

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

Hi,

On Mon 11 Mar 2013 10:30, shookie <at> email.de writes:

>   GUILEC scripts/autofrisk.go
> Backtrace:
> In ice-9/psyntax.scm:
> 1101: 19 [expand-top-sequence ((define (unglob pattern) (let # #))) () ...]
> 1259: 18 [#<procedure 21d8540 at ice-9/psyntax.scm:1067:36 ()>]
> 1605: 17 [expand-simple-lambda (# . #) () (()) ...]
> 1509: 16 [parse (((# #) . #(syntax-object # # #))) () () () () () ()]
> In ice-9/boot-9.scm:
>  627: 15 [map #<procedure 2205e10 at ice-9/psyntax.scm:1510:50 (x)> ((# . #))]
> In ice-9/psyntax.scm:
> 2114: 14 [expand-let (let # #) (# #) (# # #) ...]
> In ice-9/boot-9.scm:
>  627: 13 [map #<procedure 2204ec0 at ice-9/psyntax.scm:2114:49 (x)> (#)]
> In ice-9/psyntax.scm:
> 1257: 12 [#<procedure 2204ec0 at ice-9/psyntax.scm:2114:49 (x)> (open-input-pipe #)]
> 1186: 11 [syntax-type (open-input-pipe #) (# #) (# # #) ...]
>  579: 10 [syntax-type open-input-pipe (# #) (# # #) ...]
>  292: 9 [get-global-definition-hook open-input-pipe (hygiene scripts autofrisk)]
> In unknown file:
>    ?: 8 [module-variable #<directory (scripts autofrisk) 21a8dc8> open-input-pipe]
> In ice-9/boot-9.scm:
> 2790: 7 [b #<autoload (ice-9 popen) 21a86c0> open-input-pipe #f]
> 2579: 6 [#<procedure 1d76530 at ice-9/boot-9.scm:2567:4 (name #:optional autoload version #:key ensure)> # ...]
> 2850: 5 [try-module-autoload (ice-9 popen) #f]
> 2191: 4 [save-module-excursion #<procedure 2205d20 at ice-9/boot-9.scm:2851:17 ()>]
> 2870: 3 [#<procedure 2205d20 at ice-9/boot-9.scm:2851:17 ()>]
> In unknown file:
>    ?: 2 [primitive-load-path "ice-9\\popen" ...]
>    ?: 1 [load-extension "libguile-2.0" "scm_init_popen"]
> In ice-9/boot-9.scm:
>  106: 0 [#<procedure 1f55340 at ice-9/boot-9.scm:97:6 (thrown-k . args)> misc-error ...]
> 
> ice-9/boot-9.scm:106:20: In procedure #<procedure 1f55340 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
> ice-9/boot-9.scm:106:20: In procedure dynamic-link: file: "libguile-2.0", message: "The specified module could not be found."
> make[3]: *** [scripts/autofrisk.go] Error 1

I believe I have fixed this one (and the scan-api one).  You will see a
warning when building these two files but that is all.  I think at this
point the build should complete.

New tarball:

  http://wingolog.org/priv/guile-2.0.7.194-dfd1d.tar.gz

This has been a very long bug report, but productive.  Thank you for
following through with these tests, and for checking the above tarball.

The next step, after moving on to actually build your application ;), is
to get the test suite working.  I suspect you will run into some issues.
Will you please run a make check -k, and send the resulting log (if it
has errors) to bug-guile <at> gnu.org?  Thanks :-) Please include
check-guile.log as well.

I'll close this report, in optimistic hope that these fixes do indeed
allow the build to complete.  Let me know how it goes, and happy hacking!

(Actually while I'm at it: would you also mail the complete set of
patches that you locally apply to your copy?  They'll be helpful in
future reports.  Thanks!)

Andy
-- 
http://wingolog.org/

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

From: "Jan Schukat" <shookie <at> email.de>
To: "Andy Wingo" <wingo <at> pobox.com>
Cc: "Ludovic Courtès" <ludo <at> gnu.org>,
	13848-done <at> debbugs.gnu.org
Subject: Aw: Re: bug#13848: Statically linking guile-2.0.
Date: Wed, 13 Mar 2013 20:04:32 +0100 (CET)

[Message part 1 (text/html, inline)]

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Andy Wingo <wingo <at> pobox.com>
Cc: 13848 <at> debbugs.gnu.org, Jan Schukat <shookie <at> email.de>
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Thu, 14 Mar 2013 14:54:34 +0100

Andy Wingo <wingo <at> pobox.com> skribis:

> 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 ;)

Indeed.  :-)

The problem was that the ‘tarball’ job would fail:

--8<---------------cut here---------------start------------->8---
perf -m 10 ./iconv_open-hpux.gperf > ./iconv_open-hpux.h-t
/bin/sh: gperf: command not found
make[2]: *** [iconv_open-hpux.h] Error 127
--8<---------------cut here---------------end--------------->8---

(From <http://hydra.nixos.org/build/4395876>, caused by an upgrade to
glibc 2.17 etc.)

Should be fixed with
<http://git.savannah.gnu.org/cgit/hydra-recipes.git/commit/?id=5096b05a2f552646d148ad161df023293df49536>.

Ludo’.

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

From: Jan Schukat <shookie <at> email.de>
To: Andy Wingo <wingo <at> pobox.com>
Cc: Ludovic Courtès <ludo <at> gnu.org>,
	13848-done <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Sat, 16 Mar 2013 02:36:29 +0100

[Message part 1 (text/plain, inline)]

Ok finally got to it. Made 3 builds from the 194-dfd1d tarball: mingw 
with posix and threads, without posix and threads and linux with posix 
and threads.

All three still have problems compiling the scheme code. All three have 
problems with scan-api and two of them with popen.

All 3 build logs attached.

Regards

Jan Schukat

On 03/13/2013 10:30 AM, Andy Wingo wrote:
> Hi,
>
> On Mon 11 Mar 2013 10:30, shookie <at> email.de writes:
>
>>    GUILEC scripts/autofrisk.go
>> Backtrace:
>> In ice-9/psyntax.scm:
>> 1101: 19 [expand-top-sequence ((define (unglob pattern) (let # #))) () ...]
>> 1259: 18 [#<procedure 21d8540 at ice-9/psyntax.scm:1067:36 ()>]
>> 1605: 17 [expand-simple-lambda (# . #) () (()) ...]
>> 1509: 16 [parse (((# #) . #(syntax-object # # #))) () () () () () ()]
>> In ice-9/boot-9.scm:
>>   627: 15 [map #<procedure 2205e10 at ice-9/psyntax.scm:1510:50 (x)> ((# . #))]
>> In ice-9/psyntax.scm:
>> 2114: 14 [expand-let (let # #) (# #) (# # #) ...]
>> In ice-9/boot-9.scm:
>>   627: 13 [map #<procedure 2204ec0 at ice-9/psyntax.scm:2114:49 (x)> (#)]
>> In ice-9/psyntax.scm:
>> 1257: 12 [#<procedure 2204ec0 at ice-9/psyntax.scm:2114:49 (x)> (open-input-pipe #)]
>> 1186: 11 [syntax-type (open-input-pipe #) (# #) (# # #) ...]
>>   579: 10 [syntax-type open-input-pipe (# #) (# # #) ...]
>>   292: 9 [get-global-definition-hook open-input-pipe (hygiene scripts autofrisk)]
>> In unknown file:
>>     ?: 8 [module-variable #<directory (scripts autofrisk) 21a8dc8> open-input-pipe]
>> In ice-9/boot-9.scm:
>> 2790: 7 [b #<autoload (ice-9 popen) 21a86c0> open-input-pipe #f]
>> 2579: 6 [#<procedure 1d76530 at ice-9/boot-9.scm:2567:4 (name #:optional autoload version #:key ensure)> # ...]
>> 2850: 5 [try-module-autoload (ice-9 popen) #f]
>> 2191: 4 [save-module-excursion #<procedure 2205d20 at ice-9/boot-9.scm:2851:17 ()>]
>> 2870: 3 [#<procedure 2205d20 at ice-9/boot-9.scm:2851:17 ()>]
>> In unknown file:
>>     ?: 2 [primitive-load-path "ice-9\\popen" ...]
>>     ?: 1 [load-extension "libguile-2.0" "scm_init_popen"]
>> In ice-9/boot-9.scm:
>>   106: 0 [#<procedure 1f55340 at ice-9/boot-9.scm:97:6 (thrown-k . args)> misc-error ...]
>>
>> ice-9/boot-9.scm:106:20: In procedure #<procedure 1f55340 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
>> ice-9/boot-9.scm:106:20: In procedure dynamic-link: file: "libguile-2.0", message: "The specified module could not be found."
>> make[3]: *** [scripts/autofrisk.go] Error 1
> I believe I have fixed this one (and the scan-api one).  You will see a
> warning when building these two files but that is all.  I think at this
> point the build should complete.
>
> New tarball:
>
>    http://wingolog.org/priv/guile-2.0.7.194-dfd1d.tar.gz
>
> This has been a very long bug report, but productive.  Thank you for
> following through with these tests, and for checking the above tarball.
>
> The next step, after moving on to actually build your application ;), is
> to get the test suite working.  I suspect you will run into some issues.
> Will you please run a make check -k, and send the resulting log (if it
> has errors) to bug-guile <at> gnu.org?  Thanks :-) Please include
> check-guile.log as well.
>
> I'll close this report, in optimistic hope that these fixes do indeed
> allow the build to complete.  Let me know how it goes, and happy hacking!
>
> (Actually while I'm at it: would you also mail the complete set of
> patches that you locally apply to your copy?  They'll be helpful in
> future reports.  Thanks!)
>
> Andy

[build_linux.log (text/x-log, attachment)]

[build.log (text/x-log, attachment)]

[build_noposix_nothreads.log (text/x-log, attachment)]

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Jan Schukat <shookie <at> email.de>
Cc: Andy Wingo <wingo <at> pobox.com>, 13848-done <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Fri, 29 Mar 2013 20:35:40 +0100

Jan Schukat <shookie <at> email.de> skribis:

> Ok finally got to it. Made 3 builds from the 194-dfd1d tarball: mingw
> with posix and threads, without posix and threads and linux with posix
> and threads.
>
> All three still have problems compiling the scheme code. All three
> have problems with scan-api and two of them with popen.

I believe the popen-related issues are fixed by
<http://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.0&id=df3d365a99311ecfe921d1dfd1848ff65112e572>.

You can check with a tarball from
<http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest/download>.

Thanks!

Ludo’.

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

From: Jan Schukat <shookie <at> email.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Andy Wingo <wingo <at> pobox.com>, 13848-done <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Sat, 30 Mar 2013 01:20:45 +0100

[Message part 1 (text/plain, inline)]

Must be psychic! Today I was just thinking about giving it a try on 
windows again.

It builds with only a few warnings, and as far as I have seen all scheme 
modules are compiled into .go files in the ccache.

Starting the guile.exe or my own guiletest.exe still fails due to init 
not finding the paths to the scheme modules, but that is something I 
need to look into anyway, and will do that over Easter. It's possible 
that that is due to the different path treatment in mingw and windows 
proper, or it could just be that guile can't handle windows paths with 
drive letters, colons and backslashes.

I have attached my build log anyway, in case that is of interest.

Regards

Jan Schukat

On 03/29/2013 08:35 PM, Ludovic Courtès wrote:
> Jan Schukat <shookie <at> email.de> skribis:
>
>> Ok finally got to it. Made 3 builds from the 194-dfd1d tarball: mingw
>> with posix and threads, without posix and threads and linux with posix
>> and threads.
>>
>> All three still have problems compiling the scheme code. All three
>> have problems with scan-api and two of them with popen.
> I believe the popen-related issues are fixed by
> <http://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.0&id=df3d365a99311ecfe921d1dfd1848ff65112e572>.
>
> You can check with a tarball from
> <http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest/download>.
>
> Thanks!
>
> Ludo’.
>

[build_windows.log (text/x-log, attachment)]

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Jan Schukat <shookie <at> email.de>
Cc: Andy Wingo <wingo <at> pobox.com>, 13848-done <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Sat, 30 Mar 2013 22:27:56 +0100

Jan Schukat <shookie <at> email.de> skribis:

> Starting the guile.exe or my own guiletest.exe still fails due to init
> not finding the paths to the scheme modules,

Did you try after running “make install”?  If you try before, it’s
normal that it doesn’t find.

> but that is something I need to look into anyway, and will do that
> over Easter. It's possible that that is due to the different path
> treatment in mingw and windows proper, or it could just be that guile
> can't handle windows paths with drive letters, colons and backslashes.

It can handle that now (until 2.0.7 included that didn’t work
correctly.)

Ludo’.

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

From: Jan Schukat <shookie <at> email.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Andy Wingo <wingo <at> pobox.com>, 13848-done <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Sat, 06 Apr 2013 01:14:46 +0200

Finally got to look into the load path issues on windows. Did so by 
adding some debug output into scm_init_load_path and 
scm_primitive_load_path.

When during the build/compile the load paths are are normal windows 
paths, with output like this:

  GEN      libguile/guile-procedures.txt

path:    (c:\Users\shookie\guiletest\lib\guile-2.0\module 
c:\Users\shookie\guiletest\lib\guile-2.0\guile-readline)
full_filename: 
c:\Users\shookie\guiletest\lib\guile-2.0\module\ice-9/boot-9.scm
compiled_filename: 
c:\Users\shookie\guiletest\lib\guile-2.0\module\ice-9/boot-9.go

full_filename: 
c:\Users\shookie\guiletest\lib\guile-2.0\module\ice-9/r4rs.scm
compiled_filename: 
c:\Users\shookie\guiletest\lib\guile-2.0\module\ice-9/r4rs.go


But when I start the installed guile.exe, the output is like this and it 
can't find the scheme modules:

path:   (/c/Users/shookie/guiletest/lib/share/guile/2.0 
/c/Users/shookie/guiletest/lib/share/guile/site/2.0 
/c/Users/shookie/guiletest/lib/share/guile/site 
/c/Users/shookie/guiletest/lib/sh are/guile)
full_filename:  #f
compiled_filename:      #f

So as I suspected a conflict between mingw-paths and windows paths. I 
suspect the mingw paths in the installed exe are the static #defines 
that configure sets up since those /c/User/... paths also show up when 
you extract the strings fromthe binary with strings guile.exe|grep "/lib".

Now when I export 
GUILE_LOAD_PATH="/c/Users/shookie/guiletest/lib/share/guile/2.0" and 
GUILE_LOAD_COMPILE_PATH=""/c/Users/shookie/guiletest/lib/lib/guile/2.0/ccache" 
before invoking the installed guile.exe it finds the modules, but it 
doesn't seem to like compile path and tries to recompile all the modules 
which eventually fails with a stall, usually at q.scm or thread.scm

Here is output from that case:

$ export 
GUILE_LOAD_PATH="/c/Users/shookie/guiletest/lib/share/guile/2.0/" 
GUILE_LOAD_COMPILED_PATH="/c/Users/shookie/guiletest/lib(lib/guile/2.0/ccache/";./lib/bin/guile 


path:   (c:/Users/shookie/guiletest/lib/share/guile/2.0/ 
/c/Users/shookie/guiletest/lib/share/guile/2.0 
/c/Users/shookie/guiletest/lib/share/guile/site/2.0 
/c/Users/shookie/guiletest/lib/share/guile/site 
/c/Users/shookie/guiletest/lib/sh
are/guile)
full_filename: 
c:/Users/shookie/guiletest/lib/share/guile/2.0/ice-9/boot-9.scm
compiled_filename:      #fb

full_filename: 
c:/Users/shookie/guiletest/lib/share/guile/2.0/ice-9/r4rs.scm
compiled_filename:      #f

full_filename: 
c:/Users/shookie/guiletest/lib/share/guile/2.0/ice-9/psyntax-pp.scm
compiled_filename:      #f

full_filename: 
c:/Users/shookie/guiletest/lib/share/guile/2.0/ice-9/posix.scm
compiled_filename:      #f

full_filename: 
c:/Users/shookie/guiletest/lib/share/guile/2.0/ice-9/networking.scm
compiled_filename:      #f

full_filename: 
c:/Users/shookie/guiletest/lib/share/guile/2.0/srfi\srfi-4.scm
compiled_filename:      #f

full_filename: 
c:/Users/shookie/guiletest/lib/share/guile/2.0/rnrs\bytevectors.scm
compiled_filename:      #f

full_filename: 
c:/Users/shookie/guiletest/lib/share/guile/2.0/ice-9\command-line.scm
compiled_filename: 
c:/Users/shookie/.cache/guile/ccache/2.0-LE-4-2.0\c/Users/shookie/guiletest/lib/share/guile/2.0/ice-9/command-line.scm.go

......snip.....

full_filename: 
c:/Users/shookie/guiletest/lib/share/guile/2.0/ice-9\futures.scm
compiled_filename: 
c:/Users/shookie/.cache/guile/ccache/2.0-LE-4-2.0\c/Users/shookie/guiletest/lib/share/guile/2.0/ice-9/futures.scm.go 


full_filename: 
c:/Users/shookie/guiletest/lib/share/guile/2.0/srfi\srfi-11.scm
compiled_filename:      #f
;;; compiling 
c:/Users/shookie/guiletest/lib/share/guile/2.0/srfi\srfi-11.scm
;;; it seems 
c:/Users/shookie/guiletest/lib/share/guile/2.0/srfi\srfi-11.scm
;;; is part of the compiler; skipping auto-compilation

full_filename: c:/Users/shookie/guiletest/lib/share/guile/2.0/ice-9\q.scm
compiled_filename: 
c:/Users/shookie/.cache/guile/ccache/2.0-LE-4-2.0\c/Users/shookie/guiletest/lib/share/guile/2.0/ice-9/q.scm.go

And at that point it stalls.

I will look more into it, but I hope this is already useful. But as 
usual each build takes quite a while, so progress is slow, since I 
always go away doing other things after I initiated a build and test-run.

Regards

Jan Schukat

On 03/30/2013 10:27 PM, Ludovic Courtès wrote:
> Jan Schukat <shookie <at> email.de> skribis:
>
>> Starting the guile.exe or my own guiletest.exe still fails due to init
>> not finding the paths to the scheme modules,
> Did you try after running “make install”?  If you try before, it’s
> normal that it doesn’t find.
>
>> but that is something I need to look into anyway, and will do that
>> over Easter. It's possible that that is due to the different path
>> treatment in mingw and windows proper, or it could just be that guile
>> can't handle windows paths with drive letters, colons and backslashes.
> It can handle that now (until 2.0.7 included that didn’t work
> correctly.)
>
> Ludo’.

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Jan Schukat <shookie <at> email.de>
Cc: Andy Wingo <wingo <at> pobox.com>, 13848-done <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Sun, 07 Apr 2013 12:20:45 +0200

Hi Jan,

Jan Schukat <shookie <at> email.de> skribis:

> But when I start the installed guile.exe, the output is like this and
> it can't find the scheme modules:
>
> path:   (/c/Users/shookie/guiletest/lib/share/guile/2.0
> /c/Users/shookie/guiletest/lib/share/guile/site/2.0
> /c/Users/shookie/guiletest/lib/share/guile/site
> /c/Users/shookie/guiletest/lib/sh are/guile)
> full_filename:  #f
> compiled_filename:      #f
>
> So as I suspected a conflict between mingw-paths and windows paths. I
> suspect the mingw paths in the installed exe are the static #defines
> that configure sets up since those /c/User/... paths also show up when
> you extract the strings fromthe binary with strings guile.exe|grep
> "/lib".

Yes.

> Now when I export
> GUILE_LOAD_PATH="/c/Users/shookie/guiletest/lib/share/guile/2.0" and
> GUILE_LOAD_COMPILE_PATH=""/c/Users/shookie/guiletest/lib/lib/guile/2.0/ccache"

You miss a ‘D’ here: ‘GUILE_LOAD_COMPILED_PATH’.

> before invoking the installed guile.exe it finds the modules, but it
> doesn't seem to like compile path and tries to recompile all the
> modules which eventually fails with a stall, usually at q.scm or
> thread.scm

That’s probably because of the above.

> Here is output from that case:
> 
> $ export
> GUILE_LOAD_PATH="/c/Users/shookie/guiletest/lib/share/guile/2.0/"
> GUILE_LOAD_COMPILED_PATH="/c/Users/shookie/guiletest/lib(lib/guile/2.0/ccache/";./lib/bin/guile 
> 
> 
> path:   (c:/Users/shookie/guiletest/lib/share/guile/2.0/
> /c/Users/shookie/guiletest/lib/share/guile/2.0
> /c/Users/shookie/guiletest/lib/share/guile/site/2.0
> /c/Users/shookie/guiletest/lib/share/guile/site
> /c/Users/shookie/guiletest/lib/sh
> are/guile)

IIUC the difference is that the first element in the path starts with
c:/ instead of /c.  That’s probably because of the conversion that MinGW
does when reading the environment variable (see
<http://www.mingw.org/wiki/Posix_path_conversion>.)

So that means that the file names obtained by ‘configure’ should be
rewritten in Windows style, I suppose.  I’m not sure exactly how this
should be done though.  Suggestions?

Ludo’.

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

From: "Jan Schukat" <shookie <at> email.de>
To: "Ludovic Courtès" <ludo <at> gnu.org>
Cc: Andy Wingo <wingo <at> pobox.com>, 13848-done <at> debbugs.gnu.org
Subject: Aw: Re: bug#13848: Statically linking guile-2.0.
Date: Sun, 7 Apr 2013 18:20:24 +0200 (CEST)

[Message part 1 (text/html, inline)]

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

From: Andy Wingo <wingo <at> pobox.com>
To: "Jan Schukat" <shookie <at> email.de>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 13848-done <at> debbugs.gnu.org
Subject: Re: Aw: Re: bug#13848: Statically linking guile-2.0.
Date: Sun, 07 Apr 2013 20:22:43 +0200

On Sun 07 Apr 2013 18:20, "Jan Schukat" <shookie <at> email.de> writes:

>> path: (/c/Users/shookie/guiletest/lib/share/guile/2.0
>> /c/Users/shookie/guiletest/lib/share/guile/site/2.0
>> /c/Users/shookie/guiletest/lib/share/guile/site
>> /c/Users/shookie/guiletest/lib/sh are/guile)

Have you tried configuring with --prefix="c:\\Users\\shookie\\guiletest"
?  I.e., a windows-style path?

Andy
-- 
http://wingolog.org/

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

From: "Jan Schukat" <shookie <at> email.de>
To: "Andy Wingo" <wingo <at> pobox.com>
Cc: "Ludovic Courtès" <ludo <at> gnu.org>,
	13848-done <at> debbugs.gnu.org
Subject: Aw: Re:  Re: bug#13848: Statically linking guile-2.0.
Date: Sun, 7 Apr 2013 21:18:48 +0200 (CEST)

[Message part 1 (text/html, inline)]

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: "Jan Schukat" <shookie <at> email.de>
Cc: Andy Wingo <wingo <at> pobox.com>, 13848-done <at> debbugs.gnu.org
Subject: Re: Aw: Re:  Re: bug#13848: Statically linking guile-2.0.
Date: Sun, 07 Apr 2013 22:00:26 +0200

"Jan Schukat" <shookie <at> email.de> skribis:

> cd C:\Users\shookie\guiletest\lib/bin && rm -f "$guile_tools" && \
> cp -pR "$guild" "$guile_tools"
> /bin/sh: line 4: cd: C:Usersshookieguiletestlib/bin: No such file or
> directory

Can you try with forward slashes instead?  That should fix the above
issue.  That is:

  --prefix=c:/users/shookie/guiletest/

Ludo’.

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

From: "Jan Schukat" <shookie <at> email.de>
To: "Ludovic Courtès" <ludo <at> gnu.org>
Cc: Andy Wingo <wingo <at> pobox.com>, 13848-done <at> debbugs.gnu.org
Subject: Aw: Re:  Re:  Re: bug#13848: Statically linking guile-2.0.
Date: Sun, 7 Apr 2013 23:06:30 +0200 (CEST)

[Message part 1 (text/html, inline)]

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: "Jan Schukat" <shookie <at> email.de>
Cc: Andy Wingo <wingo <at> pobox.com>, 13848-done <at> debbugs.gnu.org
Subject: Re: Aw: Re:  Re:  Re: bug#13848: Statically linking guile-2.0.
Date: Mon, 08 Apr 2013 09:48:50 +0200

"Jan Schukat" <shookie <at> email.de> skribis:

> Ok, windows paths with forward slashes work, I can now start the
> installed guile.exe without setting environment variables. Always nice
> when the inconsistent formats are the working ones :)

Heh.

> The remaining issue is that it hangs itself after printing that it is
> loading q.scm. Not sure how exactly to appreoach this problem. I guess
> I'm gonna put a lot more debug output into the the various load
> functions. Or I'm gonna make debug builds and fire up gdb on windows.
> Or maybe you have an idea.

No idea.  If you could get a backtrace with gdb, that’d be helpful, yes.

Ludo’.

Previous Next

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