GNU bug report logs - #14789
Test failures under Cygwin (Guile master)

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 14789 in the body.
You can then email your comments to 14789 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: Vasiliy <testtest_2005 <at> ukr.net>
To: bug-guile <at> gnu.org
Subject: BUG: Modules compile as ELF's on PE/PE+ architecture
Date: Thu, 4 Jul 2013 15:56:11 +0200

Dear Guile Team,

I have just tried to compile Guile from the git sources under Cygwin
(64-bit), and all the modules got compied by GUILEC as ELF
executables, not as PE/PE+'s as I would expect it, what was also quite
(unfortunate) surprising. Any ideas, what could be wrong?

BZW, the compiler has passed almost all tests:

PASS: test-system-cmds
PASS: test-bad-identifiers
PASS: test-require-extension
PASS: test-guile-snarf
PASS: test-import-order
PASS: test-command-line-encoding
PASS: test-command-line-encoding2
PASS: test-language
PASS: test-num2integral.exe
PASS: test-round.exe
PASS: test-asmobs
...
Backtrace:
In ice-9/boot-9.scm:
 163: 11 [catch #t #<catch-closure 600260d20> ...]
In unknown file:
   ?: 10 [apply-smob/1 #<catch-closure 600260d20>]
In ice-9/boot-9.scm:
  65: 9 [call-with-prompt # #<procedure 600268180 at
ice-9/eval.scm:414:20 ()> ...]
In ice-9/eval.scm:
 427: 8 [eval # #]
In ice-9/boot-9.scm:
2623: 7 [save-module-excursion #<procedure 600247100 at
ice-9/boot-9.scm:4118:3 ()>]
4123: 6 [#<procedure 600247100 at ice-9/boot-9.scm:4118:3 ()>]
1979: 5 [%start-stack load-stack ...]
1984: 4 [#<procedure 600269e70 ()>]
In unknown file:
   ?: 3 [primitive-load
"/usr/src/64bit/release/guile/guile-2.1.0-57/src/guile-2.1.0/test-suite/standalone/test-ffi"]
In ice-9/eval.scm:
 448: 2 [eval # ()]
 385: 1 [eval # ()]
In unknown file:
   ?: 0 [dynamic-func "strerror" #<dynamic-object #f>]

ERROR: In procedure dynamic-func:
ERROR: In procedure dynamic-pointer: Symbol not found: strerror
FAIL: test-ffi
PASS: test-list.exe
PASS: test-unwind.exe
fail: scm_from_double (1) == +nan.0
FAIL: test-conversion.exe
PASS: test-loose-ends.exe
PASS: test-fast-slot-ref
PASS: test-mb-regexp
PASS: test-use-srfi
PASS: test-scm-c-read.exe
PASS: test-scm-take-locale-symbol.exe
PASS: test-scm-take-u8vector.exe
PASS: test-scm-to-latin1-string.exe
PASS: test-scm-values.exe
PASS: test-scm-c-bind-keyword-arguments.exe
PASS: test-extensions
PASS: test-with-guile-module.exe
PASS: test-scm-with-guile.exe
PASS: test-scm-spawn-thread.exe
PASS: test-pthread-create.exe
SKIP: test-pthread-create-secondary.exe
PASS: test-smob-mark.exe
==================================
2 of 31 tests failed
(1 test was not run)
Please report to bug-guile <at> gnu.org
==================================

My CFLAGS were '-mtune=native -march=native -Ofast -fomit-frame-pointer'

Kind regards,
Vasiliy

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

From: Mark H Weaver <mhw <at> netris.org>
To: Vasiliy <testtest_2005 <at> ukr.net>
Cc: 14789 <at> debbugs.gnu.org
Subject: Re: bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture
Date: Fri, 05 Jul 2013 12:23:33 -0400

retitle 14789 Test failures under Cygwin (Guile master)
thanks

Hi,

Vasiliy <testtest_2005 <at> ukr.net> writes:

> I have just tried to compile Guile from the git sources under Cygwin
> (64-bit), and all the modules got compied by GUILEC as ELF
> executables, not as PE/PE+'s as I would expect it, what was also quite
> (unfortunate) surprising. Any ideas, what could be wrong?

This is intentional.  Guile 2.2 will use ELF as the format for .go
files, regardless of platform.

> ERROR: In procedure dynamic-func:
> ERROR: In procedure dynamic-pointer: Symbol not found: strerror
> FAIL: test-ffi

This is a portability problem in our test suite, and doesn't indicate a
problem with Guile itself.  Still, it would be good to fix it at some
point.

> fail: scm_from_double (1) == +nan.0
> FAIL: test-conversion.exe

This is a _real_ bug, either in Guile or in Cygwin itself.  That "1"
should have been NaN.  One possibility is that Cygwin's 'fprintf'
doesn't handle NaN's properly.

Another more troubling possibility is that the code in
test-suite/standalone/test-conversion.c:ieee_init, also found in
libguile/numbers.c:guile_ieee_init, is not working properly under
Cygwin.  This could be a serious problem for numerics.

Were there any failures in 'numbers.test'?

    Thanks,
      Mark

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

From: Vasiliy <testtest_2005 <at> ukr.net>
To: Mark H Weaver <mhw <at> netris.org>, 14789 <at> debbugs.gnu.org
Subject: Re: bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture
Date: Sat, 6 Jul 2013 11:01:46 +0200

Hi,

It's just to highlight I've got that error of:
fail: scm_from_double (1) == +nan.0
FAIL: test-conversion.exe

while compiling with:
CFLAGS="-mtune=native -march=native -Ofast -fomit-frame-pointer"

Guile passes the above test when recompiled with:
CFLAGS ="-mtune=native -march=native -O2"

There's, however, still an error with 'test-ffi', and there's no
automatic invocation of 'numbers.test'. Would be there any support for
-Ofast in future?

Just one point more here: the latest autogen when compiled
--with-guile=2.2 refers to 'scm_subr_table' not present in mainstream
Guile. I got it wrapped by adding the row
'scm_t_subr_entry *scm_subr_table;' to 'agen5/ag.c'. What that the
right way it should be done or could such a procedure be added back to
Guile?

There're the latest tests:
PASS: test-system-cmds
PASS: test-bad-identifiers
PASS: test-require-extension
PASS: test-guile-snarf
PASS: test-import-order
PASS: test-command-line-encoding
PASS: test-command-line-encoding2
PASS: test-language
PASS: test-num2integral.exe
PASS: test-round.exe
PASS: test-asmobs
Backtrace:
In ice-9/boot-9.scm:
 163: 11 [catch #t #<catch-closure 600260d20> ...]
In unknown file:
   ?: 10 [apply-smob/1 #<catch-closure 600260d20>]
In ice-9/boot-9.scm:
  65: 9 [call-with-prompt # #<procedure 600268180 at
ice-9/eval.scm:414:20 ()> ...]
In ice-9/eval.scm:
 427: 8 [eval # #]
In ice-9/boot-9.scm:
2623: 7 [save-module-excursion #<procedure 600246100 at
ice-9/boot-9.scm:4118:3 ()>]
4123: 6 [#<procedure 600246100 at ice-9/boot-9.scm:4118:3 ()>]
1979: 5 [%start-stack load-stack ...]
1984: 4 [#<procedure 60026be70 ()>]
In unknown file:
   ?: 3 [primitive-load
"/usr/src/64bit/release/guile/guile-2.1.0-57/src/guile-2.1.0/test-suite/standalone/test-ffi"]
In ice-9/eval.scm:
 448: 2 [eval # ()]
 385: 1 [eval # ()]
In unknown file:
   ?: 0 [dynamic-func "strerror" #<dynamic-object #f>]

ERROR: In procedure dynamic-func:
ERROR: In procedure dynamic-pointer: Symbol not found: strerror
FAIL: test-ffi
PASS: test-list.exe
PASS: test-unwind.exe
PASS: test-conversion.exe
PASS: test-loose-ends.exe
PASS: test-fast-slot-ref
PASS: test-mb-regexp
PASS: test-use-srfi
PASS: test-scm-c-read.exe
PASS: test-scm-take-locale-symbol.exe
PASS: test-scm-take-u8vector.exe
PASS: test-scm-to-latin1-string.exe
PASS: test-scm-values.exe
PASS: test-scm-c-bind-keyword-arguments.exe
PASS: test-extensions
PASS: test-with-guile-module.exe
PASS: test-scm-with-guile.exe
PASS: test-scm-spawn-thread.exe
PASS: test-pthread-create.exe
SKIP: test-pthread-create-secondary.exe
PASS: test-smob-mark.exe
==================================
1 of 31 tests failed
(1 test was not run)
Please report to bug-guile <at> gnu.org
==================================


On Fri, Jul 5, 2013 at 6:23 PM, Mark H Weaver wrote:
> retitle 14789 Test failures under Cygwin (Guile master)
> thanks
>
> Hi,
>
> Vasiliy writes:
>
>> I have just tried to compile Guile from the git sources under Cygwin
>> (64-bit), and all the modules got compied by GUILEC as ELF
>> executables, not as PE/PE+'s as I would expect it, what was also quite
>> (unfortunate) surprising. Any ideas, what could be wrong?
>
> This is intentional.  Guile 2.2 will use ELF as the format for .go
> files, regardless of platform.
>
>> ERROR: In procedure dynamic-func:
>> ERROR: In procedure dynamic-pointer: Symbol not found: strerror
>> FAIL: test-ffi
>
> This is a portability problem in our test suite, and doesn't indicate a
> problem with Guile itself.  Still, it would be good to fix it at some
> point.
>
>> fail: scm_from_double (1) == +nan.0
>> FAIL: test-conversion.exe
>
> This is a _real_ bug, either in Guile or in Cygwin itself.  That "1"
> should have been NaN.  One possibility is that Cygwin's 'fprintf'
> doesn't handle NaN's properly.
>
> Another more troubling possibility is that the code in
> test-suite/standalone/test-conversion.c:ieee_init, also found in
> libguile/numbers.c:guile_ieee_init, is not working properly under
> Cygwin.  This could be a serious problem for numerics.
>
> Were there any failures in 'numbers.test'?
>
>     Thanks,
>       Mark

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

From: Mark H Weaver <mhw <at> netris.org>
To: Vasiliy <testtest_2005 <at> ukr.net>
Cc: 14789 <at> debbugs.gnu.org
Subject: Re: bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture
Date: Sat, 06 Jul 2013 15:09:53 -0400

Vasiliy <testtest_2005 <at> ukr.net> writes:

> It's just to highlight I've got that error of:
> fail: scm_from_double (1) == +nan.0
> FAIL: test-conversion.exe
>
> while compiling with:
> CFLAGS="-mtune=native -march=native -Ofast -fomit-frame-pointer"

I now see the problem.  -Ofast implies -ffast-math, which implies
-funsafe-math-optimizations, -ffinite-math-only, etc.  Specifically,
this enabled the compiler to optimize (guile_Inf / guile_Inf) to 1.0,
which foiled Guile's attempt to create a NaN object.

From the GCC manual (Optimize Options):

`-Ofast'
     Disregard strict standards compliance.  `-Ofast' enables all `-O3'
     optimizations.  It also enables optimizations that are not valid
     for all standard compliant programs.  It turns on `-ffast-math'
     and the Fortran-specific `-fno-protect-parens' and
     `-fstack-arrays'.

My recommendation would be to avoid -Ofast, not just in Guile but in
general.  It is likely to create subtle problems in a lot of software.

Things like language interpreters in particular tend to push the
boundaries of standards compliance, and are likely to be broken in
subtle ways by -Ofast.

It's reasonable and sometimes useful to use -Ofast in isolated modules
containing hot code, but only in modules whose -Ofast safety has been
investigated by someone who understands the associated compiler
optimizations, and is familiar with the kinds of breakage that can
occur.

> There's, however, still an error with 'test-ffi', and there's no
> automatic invocation of 'numbers.test'.

Strange.  Did you run "make check" in the top-level build directory?

If that doesn't work, maybe try: "./check-guile numbers.test"

> Would be there any support for -Ofast in future?

I doubt that we would officially support it.  It's possible that the
bugs introduced by -Ofast will not affect you, I don't know.  At the
very least, you are likely to get incorrect answers from the numerics
library in some cases.  There might be more serious problems as well.
Some of these problems might be discovered by our test suite, which you
don't seem to be running most of.  Others might remain undetected.

> Just one point more here: the latest autogen when compiled
> --with-guile=2.2 refers to 'scm_subr_table' not present in mainstream
> Guile.

This indicates that you compiled against Guile 1.8's headers.  You'll
need to arrange to have Guile 2.2's headers come first in the search
path.  I guess the --with-libguile option to autogen's configure is what
you need.

     Regards,
       Mark

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

From: Vasiliy <testtest_2005 <at> ukr.net>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 14789 <at> debbugs.gnu.org
Subject: Re: bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture
Date: Sat, 6 Jul 2013 22:11:42 +0200

Hi, Mark,

Sorry for my previous double-posting to the guile-devel maillist; just
at that time I didn't have a reply from guile-bugs'.

I've run ./check-guile numbers.test, yes, it hasn't been invoked my
"make check" from the top-level build directory. For the latest Guile
compiled with CFLAGS="-mtune=native -march=native -O2" I've got the
following:

$ ./check-guile numbers.test
Testing /usr/src/64bit/release/guile/guile-2.1.0-57/build/meta/guile
... numbers.test
with GUILE_LOAD_PATH=/usr/src/64bit/release/guile/guile-2.1.0-57/src/guile-2.1.0/test-suite
Running numbers.test
FAIL: numbers.test: inexact->exact: smallest inexact: pos - arguments:
(expected-value
1/202402253307310618352495346718917307049556649764142118356901358027430339567995346891960383701437124495187077864316811911389808737385793476867013399940738509921517424276566361364466907742093216341239767678472745068562007483424692698618103355649159556340810056512358769552333414615230502532186327508646006263307707741093494784
actual-value 0)
FAIL: numbers.test: inexact->exact: smallest inexact: neg - arguments:
(expected-value
-1/202402253307310618352495346718917307049556649764142118356901358027430339567995346891960383701437124495187077864316811911389808737385793476867013399940738509921517424276566361364466907742093216341239767678472745068562007483424692698618103355649159556340810056512358769552333414615230502532186327508646006263307707741093494784
actual-value 0)
FAIL: numbers.test: inexact->exact: smallest inexact * 2: pos -
arguments: (expected-value
1/101201126653655309176247673359458653524778324882071059178450679013715169783997673445980191850718562247593538932158405955694904368692896738433506699970369254960758712138283180682233453871046608170619883839236372534281003741712346349309051677824579778170405028256179384776166707307615251266093163754323003131653853870546747392
actual-value 0)
FAIL: numbers.test: inexact->exact: smallest inexact * 2: neg -
arguments: (expected-value
-1/101201126653655309176247673359458653524778324882071059178450679013715169783997673445980191850718562247593538932158405955694904368692896738433506699970369254960758712138283180682233453871046608170619883839236372534281003741712346349309051677824579778170405028256179384776166707307615251266093163754323003131653853870546747392
actual-value 0)
FAIL: numbers.test: inexact->exact: smallest inexact * 3: pos -
arguments: (expected-value
3/202402253307310618352495346718917307049556649764142118356901358027430339567995346891960383701437124495187077864316811911389808737385793476867013399940738509921517424276566361364466907742093216341239767678472745068562007483424692698618103355649159556340810056512358769552333414615230502532186327508646006263307707741093494784
actual-value 0)
FAIL: numbers.test: inexact->exact: smallest inexact * 3: neg -
arguments: (expected-value
-3/202402253307310618352495346718917307049556649764142118356901358027430339567995346891960383701437124495187077864316811911389808737385793476867013399940738509921517424276566361364466907742093216341239767678472745068562007483424692698618103355649159556340810056512358769552333414615230502532186327508646006263307707741093494784
actual-value 0)

Totals for this test run:
passes:                 28367
failures:               6
unexpected passes:      0
expected failures:      0
unresolved test cases:  0
untested test cases:    0
unsupported test cases: 0
errors:                 0

Regards,
Vasiliy

On Sat, Jul 6, 2013 at 9:09 PM, Mark H Weaver <mhw <at> netris.org> wrote:
> Vasiliy <testtest_2005 <at> ukr.net> writes:
>
>> It's just to highlight I've got that error of:
>> fail: scm_from_double (1) == +nan.0
>> FAIL: test-conversion.exe
>>
>> while compiling with:
>> CFLAGS="-mtune=native -march=native -Ofast -fomit-frame-pointer"
>
> I now see the problem.  -Ofast implies -ffast-math, which implies
> -funsafe-math-optimizations, -ffinite-math-only, etc.  Specifically,
> this enabled the compiler to optimize (guile_Inf / guile_Inf) to 1.0,
> which foiled Guile's attempt to create a NaN object.
>
> From the GCC manual (Optimize Options):
>
> `-Ofast'
>      Disregard strict standards compliance.  `-Ofast' enables all `-O3'
>      optimizations.  It also enables optimizations that are not valid
>      for all standard compliant programs.  It turns on `-ffast-math'
>      and the Fortran-specific `-fno-protect-parens' and
>      `-fstack-arrays'.
>
> My recommendation would be to avoid -Ofast, not just in Guile but in
> general.  It is likely to create subtle problems in a lot of software.
>
> Things like language interpreters in particular tend to push the
> boundaries of standards compliance, and are likely to be broken in
> subtle ways by -Ofast.
>
> It's reasonable and sometimes useful to use -Ofast in isolated modules
> containing hot code, but only in modules whose -Ofast safety has been
> investigated by someone who understands the associated compiler
> optimizations, and is familiar with the kinds of breakage that can
> occur.
>
>> There's, however, still an error with 'test-ffi', and there's no
>> automatic invocation of 'numbers.test'.
>
> Strange.  Did you run "make check" in the top-level build directory?
>
> If that doesn't work, maybe try: "./check-guile numbers.test"
>
>> Would be there any support for -Ofast in future?
>
> I doubt that we would officially support it.  It's possible that the
> bugs introduced by -Ofast will not affect you, I don't know.  At the
> very least, you are likely to get incorrect answers from the numerics
> library in some cases.  There might be more serious problems as well.
> Some of these problems might be discovered by our test suite, which you
> don't seem to be running most of.  Others might remain undetected.
>
>> Just one point more here: the latest autogen when compiled
>> --with-guile=2.2 refers to 'scm_subr_table' not present in mainstream
>> Guile.
>
> This indicates that you compiled against Guile 1.8's headers.  You'll
> need to arrange to have Guile 2.2's headers come first in the search
> path.  I guess the --with-libguile option to autogen's configure is what
> you need.
>
>      Regards,
>        Mark

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

From: Vasiliy <testtest_2005 <at> ukr.net>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 14789 <at> debbugs.gnu.org
Subject: Re: bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture
Date: Sun, 7 Jul 2013 11:46:55 +0200

BTW, Guile says one can use 'strerror_r' instead of 'strerror' which
is available in Cygwin but there're no checks for 'strerror_r' and no
guidance was given how to introduce that.

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

From: Vasiliy <testtest_2005 <at> ukr.net>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 14789 <at> debbugs.gnu.org
Subject: Fwd: bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture
Date: Thu, 11 Jul 2013 17:33:50 +0200

It's just my previous question:

"How to replace 'strerror' with strerror_r, or better, to add it to
the table of symbols Guile could operate with?"

Regards,
Vasiliy


---------- Forwarded message ----------
From: Vasiliy
Date: Sun, Jul 7, 2013 at 11:46 AM
Subject: Re: bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture
To: Mark H Weaver
Cc: 14789


BTW, Guile says one can use 'strerror_r' instead of 'strerror' which
is available in Cygwin but there're no checks for 'strerror_r' and no
guidance was given how to introduce that.

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

From: Vasiliy <testtest_2005 <at> ukr.net>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 14789 <at> debbugs.gnu.org
Subject: Re: bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture
Date: Fri, 12 Jul 2013 12:14:43 +0200

Whatever compile options I use on the latest sources they have the
following issue:

<code>
Making all in module
make[2]: Entering directory
'/usr/src/64bit/release/guile/guile-2.1.0-57/build/module'
  GUILEC ice-9/eval.go
Backtrace:
In unknown file:
   ?: 17 [apply-smob/1 #<boot-closure 6001c9d00 (_ _ _)> #t ...]
   ?: 16 [apply-smob/1 #<boot-closure 6001c1b40 ()>]
   ?: 15 [apply-smob/1 #<catch-closure 6001c1ba0>]
   ?: 14 [primitive-eval ((@ # %) (begin # # #))]
   ?: 13 [apply-smob/1 #<boot-closure 60067be20 ()>]
   ?: 12 [apply-smob/1 #<boot-closure 60076b620 ()>]
   ?: 11 [apply-smob/1 #<boot-closure 60076b460 ()>]
   ?: 10 [apply-smob/1 #<boot-closure 60076b400 ()>]
   ?: 9 [apply-smob/1 #<boot-closure 60076b3a0 ()>]
   ?: 8 [apply-smob/1 #<boot-closure 600874640 ()>]
   ?: 7 [apply-smob/1 #<boot-closure 600874280 ()>]
   ?: 6 [apply-smob/1 #<boot-closure 6008741c0 ()>]
   ?: 5 [apply-smob/1 #<boot-closure 60209ed80 ()>]
   ?: 4 [apply-smob/1 #<boot-closure 602a53560 ()>]
   ?: 3 [apply-smob/1 #<boot-closure 602a53340 ()>]
   ?: 2 [struct-vtable #f]
   ?: 1 [apply-smob/1 #<boot-closure 6001c9cc0 (_ . _)> wrong-type-arg ...]
   ?: 0 [apply-smob/1 #<boot-closure 602bcad40 ()>]

ERROR: Makefile:2163: recipe for target 'ice-9/eval.go' failed
</code>

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

From: Vasiliy <testtest_2005 <at> ukr.net>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 14789 <at> debbugs.gnu.org
Subject: Re: bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture
Date: Fri, 12 Jul 2013 17:42:42 +0200

I've just checked the patches, and after
c32b7c4cef1c63a677a1c447a0386e90ab2ecd42 the code behavior has
changed. Compare

AFTER:
Making all in module
make[2]: Entering directory
'/usr/src/64bit/release/guile/guile-2.1.0-57/build/module'
  GUILEC ice-9/eval.go
Backtrace:
In unknown file:
   ?: 16 [apply-smob/1 #<boot-closure 6001c9d00 (_ _ _)> #t ...]
   ?: 15 [apply-smob/1 #<boot-closure 6001d6180 ()>]
   ?: 14 [apply-smob/1 #<catch-closure 6001d61e0>]
   ?: 13 [primitive-eval ((@ # %) (begin # # #))]
   ?: 12 [apply-smob/1 #<boot-closure 600743a40 ()>]
   ?: 11 [apply-smob/1 #<boot-closure 6011cd860 ()>]
   ?: 10 [apply-smob/1 #<boot-closure 6011cd6a0 ()>]
   ?: 9 [apply-smob/1 #<boot-closure 6011cd640 ()>]
   ?: 8 [apply-smob/1 #<boot-closure 6011cd5e0 ()>]
   ?: 7 [apply-smob/1 #<boot-closure 600c845a0 ()>]
   ?: 6 [apply-smob/1 #<boot-closure 600c84220 ()>]
   ?: 5 [apply-smob/1 #<boot-closure 600c84160 ()>]
   ?: 4 [apply-smob/1 #<boot-closure 603117dc0 ()>]
   ?: 3 [apply-smob/1 #<boot-closure 600956e60 ()>]
   ?: 2 [apply-smob/1 #<boot-closure 600956b20 ()>]
   ?: 1 [apply-smob/1 #<boot-closure 6001c9cc0 (_ . _)>
wrong-number-of-args ...]
   ?: 0 [apply-smob/1 #<boot-closure 602211560 ()>]

ERROR: Makefile:2163: recipe for target 'ice-9/eval.go' failed

BEFORE:
make[2]: Entering directory
'/usr/src/64bit/release/guile/guile-2.1.0-57/build/module'
  GUILEC ice-9/eval.go
Backtrace:
In unknown file:
   ?: 6 [apply-smob/1 #<boot-closure 6001c63c0 (_ _ _)> #t ...]
   ?: 5 [apply-smob/1 #<boot-closure 600627480 ()>]
   ?: 4 [apply-smob/1 #<catch-closure 6006274e0>]
   ?: 3 [primitive-eval ((@ # %) (begin # # #))]
   ?: 2 [apply-smob/1 #<boot-closure 600352860 ()>]
   ?: 1 [apply-smob/1 #<boot-closure 600c13ce0 ()>]
   ?: 0 [apply-smob/1 #<boot-closure 601ede400 ()>]

ERROR: Makefile:2163: recipe for target 'ice-9/eval.go' failed

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

From: Andy Wingo <wingo <at> pobox.com>
To: Vasiliy <testtest_2005 <at> ukr.net>
Cc: Mark H Weaver <mhw <at> netris.org>, 14789-done <at> debbugs.gnu.org
Subject: Re: bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture
Date: Tue, 21 Jun 2016 08:53:53 +0200

Hi,

Thanks fro trying the development branch.  Sorry that it was in a
non-working state when you were using it.  In the meantime, we are
getting close to a 2.2 release finally, so please do report any issues
you have with 2.1.3 as new bugs.  I'm archiving this report as there is
nothing to do.

Andy

On Fri 12 Jul 2013 17:42, Vasiliy <testtest_2005 <at> ukr.net> writes:

> I've just checked the patches, and after
> c32b7c4cef1c63a677a1c447a0386e90ab2ecd42 the code behavior has
> changed. Compare
>
> AFTER:
> Making all in module
> make[2]: Entering directory
> '/usr/src/64bit/release/guile/guile-2.1.0-57/build/module'
>   GUILEC ice-9/eval.go
> Backtrace:
> In unknown file:
>    ?: 16 [apply-smob/1 #<boot-closure 6001c9d00 (_ _ _)> #t ...]
>    ?: 15 [apply-smob/1 #<boot-closure 6001d6180 ()>]
>    ?: 14 [apply-smob/1 #<catch-closure 6001d61e0>]
>    ?: 13 [primitive-eval ((@ # %) (begin # # #))]
>    ?: 12 [apply-smob/1 #<boot-closure 600743a40 ()>]
>    ?: 11 [apply-smob/1 #<boot-closure 6011cd860 ()>]
>    ?: 10 [apply-smob/1 #<boot-closure 6011cd6a0 ()>]
>    ?: 9 [apply-smob/1 #<boot-closure 6011cd640 ()>]
>    ?: 8 [apply-smob/1 #<boot-closure 6011cd5e0 ()>]
>    ?: 7 [apply-smob/1 #<boot-closure 600c845a0 ()>]
>    ?: 6 [apply-smob/1 #<boot-closure 600c84220 ()>]
>    ?: 5 [apply-smob/1 #<boot-closure 600c84160 ()>]
>    ?: 4 [apply-smob/1 #<boot-closure 603117dc0 ()>]
>    ?: 3 [apply-smob/1 #<boot-closure 600956e60 ()>]
>    ?: 2 [apply-smob/1 #<boot-closure 600956b20 ()>]
>    ?: 1 [apply-smob/1 #<boot-closure 6001c9cc0 (_ . _)>
> wrong-number-of-args ...]
>    ?: 0 [apply-smob/1 #<boot-closure 602211560 ()>]
>
> ERROR: Makefile:2163: recipe for target 'ice-9/eval.go' failed
>
> BEFORE:
> make[2]: Entering directory
> '/usr/src/64bit/release/guile/guile-2.1.0-57/build/module'
>   GUILEC ice-9/eval.go
> Backtrace:
> In unknown file:
>    ?: 6 [apply-smob/1 #<boot-closure 6001c63c0 (_ _ _)> #t ...]
>    ?: 5 [apply-smob/1 #<boot-closure 600627480 ()>]
>    ?: 4 [apply-smob/1 #<catch-closure 6006274e0>]
>    ?: 3 [primitive-eval ((@ # %) (begin # # #))]
>    ?: 2 [apply-smob/1 #<boot-closure 600352860 ()>]
>    ?: 1 [apply-smob/1 #<boot-closure 600c13ce0 ()>]
>    ?: 0 [apply-smob/1 #<boot-closure 601ede400 ()>]
>
> ERROR: Makefile:2163: recipe for target 'ice-9/eval.go' failed

Previous Next

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