Failure in test-suite/standalone/test-ffi test

Failure in test-suite/standalone/test-ffi test

[Eli Zaretskii]

This test fails on MS-Windows in the MinGW build as follows:

     Backtrace:
     In ice-9/boot-9.scm:
      157: 11 [catch #t #<catch-closure d9f620> ...]
     In unknown file:
	?: 10 [apply-smob/1 #<catch-closure d9f620>]
     In ice-9/boot-9.scm:
       63: 9 [call-with-prompt prompt0 ...]
     In ice-9/eval.scm:
      432: 8 [eval # #]
     In ice-9/boot-9.scm:
     2401: 7 [save-module-excursion #<procedure db6c80 at ice-9/boot-9.scm:4045:3 ()>]
     4050: 6 [#<procedure db6c80 at ice-9/boot-9.scm:4045:3 ()>]
     1724: 5 [%start-stack load-stack #<procedure ce4900 at ice-9/boot-9.scm:4041:10 ()>]
     1729: 4 [#<procedure c0ecd8 ()>]
     In unknown file:
	?: 3 [primitive-load "d:/gnu/guile-2.0.11/test-suite/standalone/test-ffi"]
     In ice-9/eval.scm:
      453: 2 [eval # ()]
      387: 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

Does this test make some unportable assumptions about the 'strerror'
symbol?  Or should I debug this?

TIA

Re: Failure in test-suite/standalone/test-ffi test

[Eli Zaretskii]

> Date: Sat, 16 Aug 2014 15:28:00 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
>    ERROR: In procedure dynamic-func:
>      ERROR: In procedure dynamic-pointer: Symbol not found: strerror
>      FAIL: test-ffi
> 
> Does this test make some unportable assumptions about the 'strerror'
> symbol?  Or should I debug this?

Answering myself here: according to libltdl documentation, the call to
lt_dlopen with the argument FILENAME being NULL will only work if the
program was linked with the -export-dynamic option to the linker.

So yes, this test does make some non-portable assumptions.

Re: Failure in test-suite/standalone/test-ffi test

[Ludovic Courtès]

Eli Zaretskii <eliz@gnu.org> skribis:

> This test fails on MS-Windows in the MinGW build as follows:
>
>      Backtrace:
>      In ice-9/boot-9.scm:
>       157: 11 [catch #t #<catch-closure d9f620> ...]
>      In unknown file:
> 	?: 10 [apply-smob/1 #<catch-closure d9f620>]
>      In ice-9/boot-9.scm:
>        63: 9 [call-with-prompt prompt0 ...]
>      In ice-9/eval.scm:
>       432: 8 [eval # #]
>      In ice-9/boot-9.scm:
>      2401: 7 [save-module-excursion #<procedure db6c80 at ice-9/boot-9.scm:4045:3 ()>]
>      4050: 6 [#<procedure db6c80 at ice-9/boot-9.scm:4045:3 ()>]
>      1724: 5 [%start-stack load-stack #<procedure ce4900 at ice-9/boot-9.scm:4041:10 ()>]
>      1729: 4 [#<procedure c0ecd8 ()>]
>      In unknown file:
> 	?: 3 [primitive-load "d:/gnu/guile-2.0.11/test-suite/standalone/test-ffi"]
>      In ice-9/eval.scm:
>       453: 2 [eval # ()]
>       387: 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
>
> Does this test make some unportable assumptions about the 'strerror'
> symbol?

Yes.

Since the test just tries to use a global symbol exported from libc, we
could use something else.

Would ‘gethostname’ work on Windows?  That is, does:

  (dynamic-func "gethostname" (dynamic-link))

return a valid pointer?

If the answer is yes, I’ll adapt this test to use this symbol instead.

Thanks,
Ludo’.

Re: Failure in test-suite/standalone/test-ffi test

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: guile-devel <guile-devel@gnu.org>
> Date: Fri, 30 Oct 2015 15:59:00 +0100
> 
> >      In unknown file:
> > 	?: 3 [primitive-load "d:/gnu/guile-2.0.11/test-suite/standalone/test-ffi"]
> >      In ice-9/eval.scm:
> >       453: 2 [eval # ()]
> >       387: 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
> >
> > Does this test make some unportable assumptions about the 'strerror'
> > symbol?
> 
> Yes.
> 
> Since the test just tries to use a global symbol exported from libc, we
> could use something else.

The equivalent of libc on Windows is a dynamic library, so these
functions are never statically linked into a program.

> Would ‘gethostname’ work on Windows?  That is, does:
> 
>   (dynamic-func "gethostname" (dynamic-link))
> 
> return a valid pointer?

No, that fails, but this works:

  (dynamic-func "strerror" (dynamic-link "msvcrt"))
    => #<pointer 0x77c371fa>

(msvcrt.dll is the Windows equivalent of libc.)

So I think global references will always fail on Windows, so we should
simply skip this part of the test on Windows.

Thanks.