Library cannot be loaded using dlopen() about dlfcn-win32

[TimothyGu]

Can you give a reduced test case? What does dlerror output?

[robertwgh]

dlerror output is not complete for some reason, which makes it harder to
debug.
dlerror() shows "OpenCL.dll: T"

I don't know what that means.

On Tue, Apr 7, 2015 at 1:49 PM, Timothy Gu [email protected] wrote:

Can you give a reduced test case? What does dlerror output?

—
Reply to this email directly or view it on GitHub
#19 (comment)
.

[robertwgh]

The code I used is:

void * handle = dlopen("C:\\Windows\\System32\\OpenCL.dll", RTLD_LAZY);
if( handle == NULL )
{
    printf("Error code %s", dlerror());
    return -1;
}

[TimothyGu]

What language is your Windows system running on? The message is supposed to be localized.

[TimothyGu]

Also, you shouldn't need to add the full path. Simply dlopen("OpenCL.dll") should work.

[robertwgh]

I think the problem might be because of the LPSTR type cast before the lpFileName:

hModule = LoadLibraryEx( (LPSTR) lpFileName, NULL, 
                                 LOAD_WITH_ALTERED_SEARCH_PATH );

While LoadLibraryEx is defined as follows:

#ifdef UNICODE
#define LoadLibraryEx  LoadLibraryExW
#else
#define LoadLibraryEx  LoadLibraryExA
#endif // !UNICODE

The language setting of my Windows is English. The non-unicode language is English, see 1.png.
So in my VS2012 project, I chose "Use Unicode charset", see 2.png
then I got 126 error, and dlerror() reports "OpenCL.dll: T", see 3.png
Actually, when compiling, you will see the following warning:

1>c:\github\openclz\testdll\testdll\dlfcn.c(170): warning C4133: 'function' : incompatible types - from 'char *' to 'LPWSTR'
1>c:\github\openclz\testdll\testdll\dlfcn.c(260): warning C4133: 'function' : incompatible types - from 'LPSTR' to 'LPCWSTR'

If I change the VS2012 settings to "Use multi-byte charset", then the dll can be opened correctly.

So, it seems that the dlfcn library should be revised to support both unicode and wide char.

1.png

2.png

3.png

[robertwgh]

Change

hModule = LoadLibraryEx( (LPSTR) lpFileName, NULL, 
                                 LOAD_WITH_ALTERED_SEARCH_PATH );

to

#ifdef UNICODE
        wchar_t wtext[1024];
        mbstowcs(wtext, lpFileName, strlen(lpFileName) + 1);
        LPWSTR lpwstr = wtext;
        hModule = LoadLibraryEx(lpwstr, NULL, 
            LOAD_WITH_ALTERED_SEARCH_PATH );
#else
        hModule = LoadLibraryEx( (LPCSTR) lpFileName, NULL, 
            LOAD_WITH_ALTERED_SEARCH_PATH );
#endif

By using this, I can open the library in Unicode mode.

Except for LoadLibraryEx(), there is another place need to be changed. The following code gives error: dlfcn.c(170): warning C4133: 'function' : incompatible types - from 'char *' to 'LPWSTR'

pos += FormatMessage( FORMAT_MESSAGE_FROM_SYSTEM, NULL, dwMessageId,
                          MAKELANGID( LANG_NEUTRAL, SUBLANG_DEFAULT ),
                          error_buffer+pos, sizeof(error_buffer)-pos, NULL );

[robertwgh]

I can help fix these two place. Should I go ahead to start a pull request?

[TimothyGu]

Yes please!

[TimothyGu]

While at it you can change the default to unicode too.

[robertwgh]

Sure. I will work on it tonight.
I will try to make as minimal changes as I can, but support both wchar and unicode.

[TimothyGu]

@robertwgh you know what you can just drop the support for multibyte. Nobody (should) use it anymore.

Also wchar_t is Unicode in Windows IIRC.

[robertwgh]

I think the current code works well for multibyte. We had better keep it
just in case someone need it for some legacy projects.
Plus, there are not much to modify. Probably just a few places.
Using #ifdef _UNICODE should be clean enough.

On Tue, Apr 7, 2015 at 4:25 PM, Timothy Gu [email protected] wrote:

@robertwgh https://github.com/robertwgh you know what you can just drop
the support for multibyte. Nobody (should) use it anymore.

Also wchar_t is Unicode in Windows IIRC.

—
Reply to this email directly or view it on GitHub
#19 (comment)
.

[TimothyGu]

Ok sounds good.

[TimothyGu]

Should be fixed in aa1401b

[pali]

Solution in commit aa1401b is too long, complicated and adds lot of useless code. The main problem is that you should call LoadLibraryExA for Unicode builds (not LoadLibraryEx or LoadLibraryExW). Similarly with FormatMessageA. Fix is in pull request #50