how to check if it is load?

For some reason, library handles are cached (why?), using a global linked list. This makes the exported functions unsafe to use in a multithreaded setting.

To avoid bugs such as the one fixed by #69, it could make sense to try to run the tests under a Memory Checker. In the past I had good experience in Windows with Dr. Memory.

Currently testing via i586-mingw32msvc-gcc cross compiler on Travis is done only via Makefile. Extends testing of this compiler also via cmake build system. CC: @rhabacker

platform
window10
mingw 8.1.0 g++/gcc

static void initMemMonitor()
{
    malloc_f  = (malloc_t)dlsym(RTLD_NEXT, "malloc");
    if (!malloc_f) {
        fprintf(stderr, "unable to get malloc symbol!\n");
        exit(1);
    }
    fprintf(stderr, "malloc monitor : successfully wrapped!\n");
}

static thread_local bool enterDumpFunc = false; // 防止栈溢出标志位

void *malloc(size_t size)
{
    if(!malloc_f || !malloc_default)
    {
        initMemMonitor();
    }

    void *ret = nullptr;
    if(!enterDumpFunc)
    {
        enterDumpFunc = true;
        ret = malloc_f(size);
    }else
        ret = malloc_default(size);
    return ret;
}

result: stack frame recursion

1 malloc            test7.cpp 39  0x402808 
2 dlsym             dlfcn.c   557 0x401fc1 
3 initMemMonitor    test7.cpp 26  0x402784 
4 malloc            test7.cpp 41  0x402825 
5 dlsym             dlfcn.c   557 0x401fc1 
6 initMemMonitor    test7.cpp 26  0x402784 
7 malloc            test7.cpp 41  0x402825 
8 __tmainCRTStartup               0x40132e 
9 WinMainCRTStartup               0x4014cb 

How can I solve it? Thanks

Because currently their layouts look like incompatible so they cannot be treated uniformly (for example shrinkDict is on offset 32 in latter and 28 in the former if I assumme dense packing, and if packing is not guaranteed, it feels like UB).

To support users with arbitrary build systems, it should be sufficient to document that:

• You need to compile a library from the dlfcn.c file, link it in your executable and make sure that dlfcn.h is on the preprocessor include search path.
• If the library compiled from dlfcn.c file is shared, you need to define only for the dlfcn library the SHARED preprocessor definition.

Related issues:

• #43

./configure: line 157: /tmp/test.c: Permission denied
testing compiler: /Users/rdp2/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/bin/i686-w64-mingw32-gcc -shared -o /tmp/test.dll /tmp/test.c
/Users/rdp2/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/lib/gcc/i686-w64-mingw32/4.9.3/../../../../i686-w64-mingw32/bin/ld: cannot open output file /tmp/test.dll: Permission denied
collect2: error: ld returned 1 exit status

this can happen if you build once as one user, then again as another...

We are facing issues in modules that depend on dlfcn-win32. BEcause LGPL is not generally accepted in commercial product. Could you please change the license text to MIT.

Here is a related issue node-ffi/node-ffi#223

What is the recommended way of installing this library into a project?

The LOAD_WITH_ALTERED_SEARCH_PATH flag should only be used when lpFileName specifies an absolute path.

This 'issue' was discovered in code that uses a relative lpFileName.

See commit ffi/ffi@b3a0a87, which references https://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).aspx.

I used the below code from the commit, hacked it with the MSYS2 build system, and tests passed. This requires linking to shlwapi, not sure of the best way to do that...

DWORD dwFlags = PathIsRelativeA(lpFileName) ? 0 : LOAD_WITH_ALTERED_SEARCH_PATH;
hModule = LoadLibraryExA(lpFileName, NULL, dwFlags);

Hello,

I'm using the following for a tracer in std::exceptions:

extern "C"
{
  void __cxa_throw(void* ex, void* info, void (*dest)(void*))
  {
    trace code here...
    static void (*const rethrow)(void*, void*, void (*)(void*)) __attribute__((noreturn)) = (void (*)(void*, void*, void (*)(void*)))dlsym(RTLD_NEXT, "__cxa_throw");

    rethrow(ex, info, dest);
  }
}

It works well under Linux with dl however when I cross compile with dflcn-win32 I get :

libstdc++.a(eh_throw.o):(.text$__cxa_throw+0x0): multiple definition of `__cxa_throw'

I'm using the MingW static cross compiler, perhaps I should do dynamic linking or, perhaps link order or perhaps I need a linker flag?

Thank you

Windows 7, 32-bit
The toolchain is https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/8.1.0/threads-posix/sjlj/i686-8.1.0-release-posix-sjlj-rt_v6-rev0.7z

since aa1401b (#20) using RTLD_NOW (replace RTLD_GLOBAL in test.c) with mingw crashes:
library = dlopen( "testdll.dll", RTLD_NOW );

I discovered this while updating from 1.0.0 to 1.1.0, both i686 & x86_84, from linux/mingw/gcc6.3.1

Migrated from: https://code.google.com/p/dlfcn-win32/issues/detail?id=15

Reported by: @LRN on April 24, 2014.

What steps will reproduce the problem?

1. build a shared library

What is the expected output? What do you see instead?
Expected:
libdl.dll - a PE shlib
libdl.dll.a - an import library for that shlib
Got:
libdl.dll - a PE shlib
libdl.dll.a - a PE shlib

What version of the product are you using? On what operating system?
Windows, SVN HEAD

Please provide any additional information below.
Wrong rule in the makefile (most likely a result of a few separate changes over time).

Patch proposed:

--- Makefile.orig   2014-04-24 07:41:47.398326500 +0000
+++ Makefile    2014-04-24 07:43:23.502530200 +0000
@@ -30,9 +30,11 @@
    $(AR) cru $@ $^
    $(RANLIB) libdl.a

-libdl.dll libdl.dll.a: $(LIB_OBJS)
+libdl.dll: $(LIB_OBJS)
    $(CC) $(SHFLAGS) -shared -o $@ $^

+libdl.dll.a: libdl.dll
+
 libdl.lib: libdl.dll
    $(LIBCMD) /machine:i386 /def:libdl.def

@TimothyGu said:

I can't reproduce it here. libdl.dll.a is significantly smaller than libdl.dll and objdump shows that it is correct.

@LRN said:

Dunno, maybe it depends on the version and type of `make' program you're using.
The way i see it (and the way msys2-make sees it) is that:
to produce libdl.dll:
produce $(LIB_OBJS) first
then
run $(CC) $(SHFLAGS) -shared -o libdl.dll $(LIB_OBJS)
to produce libdl.dll.a:
produce $(LIB_OBJS) first
then
run $(CC) $(SHFLAGS) -shared -o libdl.dll.a $(LIB_OBJS)

My patch changes the rules into:

to produce libdl.dll:
produce $(LIB_OBJS) first
then
run $(CC) $(SHFLAGS) -shared -o libdl.dll $(LIB_OBJS)

to produce libdl.dll.a:
produce libdl.dll first

@TimothyGu said:

I will probably migrate to autotools soon. Also the new project page is at https://github.com/dlfcn-win32/dlfcn-win32 now. I will spend some time migrating the remaining issues there.

Once #72 is merged, probably it make sense to do a new release (minor as it adds a new functionality).

See https://cmake.org/cmake/help/v3.11/module/FetchContent.html .

See #96 (comment) .

The AppVeyor build for this project doesn't currently produce any artifacts. It'd be nice if the build made dlfcn.dll, dlfcn.a, and dlfcn.h (for example) available as dlfcn-win32.zip or something, for folks who don't wish to compile this library themselves.

See https://ci.appveyor.com/project/traversaro/dlfcn-win32/build/1.0.4 ,

Support for dladdr() has been added with #72. An addition to this function would be to examine the export table, if present, to find additional symbols

I am trying to use dlfcn to load the OpenCL.dll library (which comes with Nvidia or AMD graphics driver).
OpenCL.dll is typically located at
C:\Windows\System32\OpenCL.dll, 32bit version
C:\Windows\SysWOW64\OpenCL.dll, 64bit version.

When I try to load the library, the LoadLibraryEx() gives an error code 126. I tried to figure out what happened. But haven't found out the reason yet. These two libraries are very common, and everyone has a Nvidia or AMD graphics card should already have these two dlls installed.

Application runs well if I don't load the library manually and asks the application to find the library from the system path by itself.
Could you please help and see how to load this library correctly?
Thanks.

I attach the OpenCL.dll here in case you don't have the corresponding graphics card driver installed:
http://goo.gl/sy9F2C

Is there an example to use with bazel, or at least an idea on how to use it with Bazel?

Not everyone would download the demo project.
As per my experiment, this is the only library required by dlfcn-win32.
Please explicitly state this in the README, this could save people tons of time.

Microsoft stated Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions.

I am wondering if it is feasible to apply the MAX_PATH restriction as implemented here:

For example #44 introduced some changes that is convenient to make sure that work fine on GCC-based compilers such as mingw.

Hi, we use UTF-8 inside kodi, after PR #50 there is no chance to load widechar pathes anymore.
Could it be a solution to always convert the given path with MultiByteToWideChar and call LoadLibraryExW instead LoadLibraryExA ?

Hi there.
I was investigating what could be patch on 32bit and 64bit Windows 10, for https://go.googlesource.com/gollvm/. That project, in turn, depend on https://github.com/ianlancetaylor/libbacktrace.

In case if I would try to build libbacktrace alone (other dependencies of gollvm also have similar enforcement, on CMake) - CMake tried to read the config and perform a check on dlfcn.h. I think that is the first checked header file - and it was predicatively reporting that it was missing.

I was curious if there could be some option to use your project - but I am unsure where and how it used, for gollvm (and where).

Please share your thoughts.
I wonder about (at least) be able to pass header checks, by using your source code.

Hence that I have formed a cross-issue:
ianlancetaylor/libbacktrace#46
. So you are welcome to comment something, out there, as well.

Ivan

While running make command at my Windows 11 machine, I got the error:

PS D:\Downloads\dlfcn-win32-master\dlfcn-win32-master> make
makefile:4: config.mak: No such file or directory
make: *** No rule to make target `config.mak'.  Stop.

Am I missing something?

After adding support for AppVeyor, we experienced several problems with AppVeyor GitHub WebHooks [1,2].
After a brief check I think this is due to the fact that I added the project to AppVeyor, but I don't have sufficient rights to create WebHooks for the dlfcn-win32/dlfcn-win32 repo [3].
@TimothyGu , I just added you to the dlfcn-win32 AppVeyor team as an admin, can you check if you are able to add the right WebHooks to this repo? Even removing and re-adding the repo to AppVeyor should be sufficient, thanks.

[1] : #30 (comment)
[2] : #31 (comment)
[3] : https://help.github.com/articles/about-webhooks/

I'm considering adding dlfcn-win32 to crosstool-ng for GCC plugin support (it's one option; perhaps GCC upstream already have something else planned!)

Would it be possible for you to make a new release and also, when you do this from now on, to release the source packages with a URL where the basename matches the final filename? Currently, only the binaries follow this rule:
https://github.com/dlfcn-win32/dlfcn-win32/releases/download/v1.0.0/dlfcn-win32-static-1.0.0.tar.gz

While the sources don't:
https://github.com/dlfcn-win32/dlfcn-win32/archive/v1.0.0.tar.gz

This breaks crosstool-ng's CT_GetFile script function.

Thanks a lot!

I am not sure what happened, but the AppVeyor tests now do not work anymore correctly, do not report the status on the PRs, and now fail on the latest master (see https://ci.appveyor.com/project/dlfcn-win32/dlfcn-win32/builds/34102698 and https://ci.appveyor.com/project/dlfcn-win32/dlfcn-win32/builds/34488023). However, the failures seems due to some change in how the AppVeyor configuration are interpreted (i.e. the wide configuration matrix generated in the past is not correctly generated anymore).

Migrated from https://code.google.com/p/dlfcn-win32/issues/detail?id=17

Originally reported by: @TooTallNate on Jun 8, 2014.

What steps will reproduce the problem?

1. Download the attached test.c file
2. Compile it against dlfcn-win32 (something like: cl.exe /I dlfcn-win32 dlfcn-win32\dlfcn.c test.c /Fetest.exe)
3. Run test.exe and witness it failing to load "printf"

What is the expected output? What do you see instead?

When I compile this code on OS X and Ubuntu, the printf symbol gets returned at line 17. When I compile it on Windows with dlfcn-win32, NULL is returned for printf. I would expect that the pointer to the printf function would be returned.

What version of the product are you using? On what operating system?

Revision 38 on Windows XP Professional with SP3.

Please provide any additional information below.

This test case is a simplified version of a failing test that was reported to me via CI on Windows. See: https://ci.appveyor.com/project/TooTallNate/node-dlfcn/build/13/job/96kayaf247q7byan

Thanks in advance!

Attached test.c:

/* Compile:
 *   Unix/OSX: gcc -ldl -o t test.c
 *   Windows via dlfcn-win32: cl.exe /I dlfcn-win32 dlfcn-win32\dlfcn.c test.c /Fetest.exe
 */

#include <dlfcn.h>
#include <stdio.h>

int main () {
  void *handle, *symbol;

  dlerror();
  handle = dlopen(NULL, RTLD_LAZY);
  printf("handle: %p\n", handle);

  dlerror();
  symbol = dlsym(handle, "printf");
  printf("symbol: %p\n", symbol);
  printf("dlerror() says: %s\n", dlerror());

  return 0;
}

how can i solve this problem.
can you help me?

$ make all install
gcc -Wall -O3 -fomit-frame-pointer -Wl,--out-implib,libdl.dll.a -DSHARED -shared -o libdl.dll dlfcn.c
dlfcn.c: In function 'dlsym':
dlfcn.c:374:14: warning: implicit declaration of function 'GetModuleHandleExA'; did you mean 'GetModuleHandleA'? [-Wimplicit-function-declaration]
374 | if( !GetModuleHandleExA( GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS | GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT, (LPCSTR) _ReturnAddress( ), &hCaller ) )
| ^~~~~~~~~~~~~~~~~~
| GetModuleHandleA
c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\SVC_YU~1.AKI\AppData\Local\Temp\cc96eNlS.o:dlfcn.c:(.text+0x688): undefined reference to `GetModuleHandleExA'
collect2.exe: error: ld returned 1 exit status
make: *** [libdl.dll] Error 1

dlerror is coded badly. It sets current_error to NULL as per the specs, but if called again, it will use it as source to memcpy.

You need to add this at the beginning of the function:

if(!current_error) return NULL;

Are you planning to add dladdr & Dl_info support?

Thanks!