> From: l...@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.