On 05/12/18 06:53, Eli Zaretskii wrote: >> Date: Wed, 05 Dec 2018 10:40:04 +0800 >> From: Walter Zambotti <zambo****@iinet*****> >> >> I am looking for a guide that will assist me with creating a >> library that is compatible with dlopen. >> >> I have already managed to create a shared library that links and >> works as expected but dlopen refuses to open this. > > There's nothing special about MinGW dlopen, ... Actually, there is ... > ... AFAICT: it is just a fancy way of calling LoadLibrary. While you may consider it as such, this trite dismissal may serve to denigrate the additional features it offers; e.g.:-- - Support for RTLD_ALL_GLOBAL and RTLD_DEFAULT symbol lookup, when GetProcAddress() is supplanted by MinGW's dlsym(): (DLLs loaded directly by LoadLibrary() will not be included in the search list for dlsym( RTLD_ALL_GLOBAL, ... ); dlopen() is required to make that work. - Facility for marking any explicitly loaded module as RTLD_LOCAL, thus excluding its symbols from a dlsym( RTLD_ALL_GLOBAL, ... ) search; (this may seem to be roughly the same as a direct call to LoadLibrary(), but failure to use dlopen() may cause the loaded DLL's symbols to appear in a dlsym( RTLD_DEFAULT, ... ) search, where they do not belong). - Support for module path names specified with slashes, rather than backslashes; (Microsoft cautions against using the former style in LoadLibrary() call, in spite of their documented suitability in other contexts). So yes, if you consider MinGW's dlopen() merely as a convenient porting substitute for LoadLibrary(), (and you don't care for the convenience of its slash vs. backslash handling), then maybe you could think in terms of dlopen() as just a fancy way to call LoadLibrary(), but, when used in conjunction with MinGW's dlsym(), (which is also more than just a fancy way to call GetProcAddress()), it *does* offer more. > So the question you should ask yourself is did you put the library in > one of the directories where LoadLibrary looks for DLLs. The > Microsoft documentation of LoadLibrary describes those directories, > as well as the order in which they are searched. Yes, indeed. Since dlopen() does, ultimately, call LoadLibrary(), any DLL to be loaded by dlopen() must reside where LoadLibrary() will look for it. -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <https://lists.osdn.me/mailman/archives/mingw-users/attachments/20181206/0cc715d2/attachment.sig>
Fork