bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture

[Vasiliy]

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 address@hidden
==================================


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