guile-devel
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]