Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

no RTLD_NOLOAD #84

Open
LightSun opened this issue Sep 24, 2020 · 6 comments
Open

no RTLD_NOLOAD #84

LightSun opened this issue Sep 24, 2020 · 6 comments

Comments

@LightSun
Copy link

LightSun commented Sep 24, 2020

how to check if it is load?

@markand
Copy link

markand commented Dec 13, 2020

It isn't part of POSIX so it should stay out for portability reasons IMHO.

@nicowilliams
Copy link

nicowilliams commented Jan 26, 2021

What I tend to do is have code like:

#ifndef RTLD_WHATEVER
#define RTLD_WHATEVER 0
#endif

Admittedly that won't do here if you really want to... not load. One thing you can do is dlsym(RTLD_DEFAULT, some_sym_only_in_target_DLL) to check if some symbol you know would only come from that DLL is available, and if it is then you infer that that DLL is loaded. That's not foolproof.

IMO useful extensions should get supported, but if upstream doesn't want them...

@nicowilliams
Copy link

It isn't part of POSIX so it should stay out for portability reasons IMHO.

But @markand, the whole purpose of this repository is enhancing portability by bringing to WIN32 an API that's foreign to it. One could just as well say "don't use POSIX dlfcn on WIN32, use WIN32 native APIs".

Useful extensions to POSIX are still useful, and if widely used, then one tends to build compatible implementations for systems where those extensions are not available.

@pali
Copy link
Collaborator

pali commented Jan 29, 2021

Well, RTLD_NOLOAD is not really part of POSIX and I do not think that it is possible to implement this GNU flag on Windows. So I do not see any reason to implement a new flag RTLD_NOLOAD which would be incompatible with GNU dlopen implementation. Applications would still need to #ifdef code for windows, so it does not bring any value. Just cause problems as people would think that this flag is same as in GNU dlopen which would not be truth.

@nicowilliams
Copy link

FYI, RTLD_NOLOAD is not just GNU, but also BSD (FreeBSD, NetBSD, possibly others, have it) and Solaris/Illumos. Given that, it might as well be POSIX. In any case, presumably you'd accept a PR for more non-POSIX extensions provided they are useful enough and not too complex or whatever criteria were applied to dladdr().

I'm not sure if there's many apps using it, and it's hard to find any with a GitHub code search (GH: please implement negative filters!), but if you search issues it's much easier (there's only 159 hits), one of which tells how to implement RTLD_NOLOAD on Windows:

Basically, GetModuleHandleExW() will not load the DLL if it isn't already loaded, so it can tell you if it's been loaded.

Searching commits instead of code or issues, I find that, e.g., SBCL (a Common Lisp) uses RTLD_NOLOAD. Even so, most references are in clones of bionic and what not.

Also, note the RTLD_NOLOAD | RTLD_GLOBAL combination for promoting an already-loaded object from local to global. This makes RTLD_NOLOAD at least a wee bit less trivial than just calling GetModuleHandleEx().

@pali
Copy link
Collaborator

pali commented Jan 29, 2021

Proper implementation of dladdr() tool half of year. So it is hard to do it properly and takes lot of manpower and time. Anyway can work on it, prepare pull request, but do not expect that it would be merged quickly... be prepared that people do not have time for review and also that it may take year (or more) for merging...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants