[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Failure in test-suite/standalone/test-ffi test
From: |
Eli Zaretskii |
Subject: |
Re: Failure in test-suite/standalone/test-ffi test |
Date: |
Fri, 30 Oct 2015 17:33:19 +0200 |
> From: address@hidden (Ludovic Courtès)
> Cc: guile-devel <address@hidden>
> 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.