Re: Guile test-ffi uses an unportable assumption

[Mark H Weaver]

Eli Zaretskii <address@hidden> writes:

>> From: Andy Wingo <address@hidden>
>> Cc: address@hidden
>> DATE: sat, 23 Jul 2016 23:17:58 +0200
>> 
>> > It assumes that libltdl can only produce a handle for a symbol in the
>> > the program itself, as opposed to those loaded from shared libraries.
>> > It tries 'strerror'.  This cannot work on MS-Windows, unless the
>> > program was linked with -export-dynamic, which is not true for
>> > the test program.
>> 
>> Interesting.  The test program is a Scheme script which looks up
>> strerror in the dlopen(NULL).  Libguile is compiled with -export-dynamic
>> but the guile binary is not.  Which part needs to be compiled with
>> -export-dynamic, do you think?
>
> The guile binary.  Here's what the libltdl documentation has to say
> about this:
>
>  -- Function: lt_dlhandle lt_dlopen (const char *FILENAME)
>     [...]
>      If FILENAME is `NULL' and the program was linked with
>      `-export-dynamic' or `-dlopen self', `lt_dlopen' will return a
>      handle for the program itself, which can be used to access its
>      symbols.
>     [...]
>      If you use `lt_dlopen (NULL)' to get a HANDLE for the running
>      binary, that handle will always be marked as resident, and
>      consequently cannot be successfully `lt_dlclose'd.
>
> However, in the case in point even compiling guile with -export-dynamic
> won't help, because the function being used by the test, strerror,
> comes from the C library, and is not statically linked into the guile
> binary.  So I suggest to modify the test to use a function that is
> part of the guile binary's own sources.

Sounds good to me.  Here's a proposed patch.  Can you test it on MinGW
and report back?

     Thanks,
       Mark

0001-test-ffi-In-global-symbol-test-use-functions-from-li.patch
Description: [PATCH] test-ffi: In global symbol test, use functions from libguile only.