dlfcn-win32 / dlfcn-win32 Goto Github PK
View Code? Open in Web Editor NEWOfficial dlfcn-win32 repo
License: MIT License
Official dlfcn-win32 repo
License: MIT License
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
./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...
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
See #96 (comment) .
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?
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
to produce libdl.dll.a:
produce $(LIB_OBJS) first
then
run
My patch changes the rules into:
to produce libdl.dll:
produce $(LIB_OBJS) first
then
run
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.
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.
Is there an example to use with bazel, or at least an idea on how to use it with Bazel?
To support users with arbitrary build systems, it should be sufficient to document that:
dlfcn.c
file, link it in your executable and make sure that dlfcn.h
is on the preprocessor include search path.dlfcn.c
file is shared, you need to define only for the dlfcn library the SHARED
preprocessor definition.Related issues:
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.
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
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?
test.c
filetest.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;
}
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;
What is the recommended way of installing this library into a project?
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.
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
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
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!
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
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
The LOAD_WITH_ALTERED_SEARCH_PATH
flag should only be used when lpFileName
specifies an absolute path.
Lines 388 to 393 in 9d0ef11
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);
Are you planning to add dladdr & Dl_info support?
Thanks!
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.
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
For example #44 introduced some changes that is convenient to make sure that work fine on GCC-based compilers such as mingw.
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).
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 ?
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).
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/
how to check if it is load?
Once #72 is merged, probably it make sense to do a new release (minor as it adds a new functionality).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.