* bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture @ 2013-07-04 13:56 Vasiliy 2013-07-05 16:23 ` Mark H Weaver 2013-07-12 10:14 ` Vasiliy 0 siblings, 2 replies; 10+ messages in thread From: Vasiliy @ 2013-07-04 13:56 UTC (permalink / raw) To: 14789 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@gnu.org ================================== My CFLAGS were '-mtune=native -march=native -Ofast -fomit-frame-pointer' Kind regards, Vasiliy ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture 2013-07-04 13:56 bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture Vasiliy @ 2013-07-05 16:23 ` Mark H Weaver 2013-07-06 9:01 ` Vasiliy 2013-07-12 10:14 ` Vasiliy 1 sibling, 1 reply; 10+ messages in thread From: Mark H Weaver @ 2013-07-05 16:23 UTC (permalink / raw) To: Vasiliy; +Cc: 14789 retitle 14789 Test failures under Cygwin (Guile master) thanks Hi, Vasiliy <testtest_2005@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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture 2013-07-05 16:23 ` Mark H Weaver @ 2013-07-06 9:01 ` Vasiliy 2013-07-06 19:09 ` Mark H Weaver 0 siblings, 1 reply; 10+ messages in thread From: Vasiliy @ 2013-07-06 9:01 UTC (permalink / raw) To: Mark H Weaver, 14789 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@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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture 2013-07-06 9:01 ` Vasiliy @ 2013-07-06 19:09 ` Mark H Weaver 2013-07-06 20:11 ` Vasiliy 0 siblings, 1 reply; 10+ messages in thread From: Mark H Weaver @ 2013-07-06 19:09 UTC (permalink / raw) To: Vasiliy; +Cc: 14789 Vasiliy <testtest_2005@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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture 2013-07-06 19:09 ` Mark H Weaver @ 2013-07-06 20:11 ` Vasiliy 2013-07-07 9:46 ` Vasiliy 0 siblings, 1 reply; 10+ messages in thread From: Vasiliy @ 2013-07-06 20:11 UTC (permalink / raw) To: Mark H Weaver; +Cc: 14789 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@netris.org> wrote: > Vasiliy <testtest_2005@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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture 2013-07-06 20:11 ` Vasiliy @ 2013-07-07 9:46 ` Vasiliy 2013-07-11 15:33 ` bug#14789: Fwd: " Vasiliy 0 siblings, 1 reply; 10+ messages in thread From: Vasiliy @ 2013-07-07 9:46 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14789: Fwd: bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture 2013-07-07 9:46 ` Vasiliy @ 2013-07-11 15:33 ` Vasiliy 0 siblings, 0 replies; 10+ messages in thread From: Vasiliy @ 2013-07-11 15:33 UTC (permalink / raw) To: Mark H Weaver; +Cc: 14789 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture 2013-07-04 13:56 bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture Vasiliy 2013-07-05 16:23 ` Mark H Weaver @ 2013-07-12 10:14 ` Vasiliy 2013-07-12 15:42 ` Vasiliy 1 sibling, 1 reply; 10+ messages in thread From: Vasiliy @ 2013-07-12 10:14 UTC (permalink / raw) To: Mark H Weaver; +Cc: 14789 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> ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture 2013-07-12 10:14 ` Vasiliy @ 2013-07-12 15:42 ` Vasiliy 2016-06-21 6:53 ` Andy Wingo 0 siblings, 1 reply; 10+ messages in thread From: Vasiliy @ 2013-07-12 15:42 UTC (permalink / raw) To: Mark H Weaver; +Cc: 14789 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture 2013-07-12 15:42 ` Vasiliy @ 2016-06-21 6:53 ` Andy Wingo 0 siblings, 0 replies; 10+ messages in thread From: Andy Wingo @ 2016-06-21 6:53 UTC (permalink / raw) To: Vasiliy; +Cc: 14789-done 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@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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-06-21 6:53 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-07-04 13:56 bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture Vasiliy 2013-07-05 16:23 ` Mark H Weaver 2013-07-06 9:01 ` Vasiliy 2013-07-06 19:09 ` Mark H Weaver 2013-07-06 20:11 ` Vasiliy 2013-07-07 9:46 ` Vasiliy 2013-07-11 15:33 ` bug#14789: Fwd: " Vasiliy 2013-07-12 10:14 ` Vasiliy 2013-07-12 15:42 ` Vasiliy 2016-06-21 6:53 ` Andy Wingo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).