On 2017-09-15 10:59, Jon Turney wrote: > On 15/09/2017 17:07, cyg Simple wrote: >> Please consider using an interleaving method of posting on this list. >> Top posting is considered rude. >> >> On 9/15/2017 9:51 AM, Gary Schneir wrote: >>> Thanks for the response but I am a little confused by it. If Cygwin is >>> supposed to provide POSIX API functionality and DLOPEN / DLSYM are >>> supported in CYGWIN, then I shouldn't care about the underlying >>> complexity or restrictions of running within the Windows environment and >>> using DLLs. The behavior should be the same as in other POSIX environments. >> >> You presented your case well and I was waiting on someone familiar with >> the code to respond. I'm not sure that would be Kaz, he was just trying >> to be helpful from his experiences. I agree with your surmise that >> Cygwin should perform similar results as Linux in this case. > > ... > >>> If you are saying that I did not include some sort of >>> __declspec(dllexport) directive in my code so that it can find my >>> symbols, that is something else but you indicate that you think cygwin >>> hides that complexity in shared libraries. >> >> Actually it would be binutils, regardless of Cygwin or MinGW, that is >> trying to hide the complexity of needing to supply the >> __declspec([export|import]) declarations. The logic for that is a bit >> confusing but if none is given then all symbols are exported. > > You need to decorate the symbols you wish to be visible with '__attribute__ > ((dllexport))' or '__declspec(dllexport)' (MSVC syntax which is also supported > by gcc) > > See [1] for an example of this done portably > > [1] https://gcc.gnu.org/wiki/Visibility > > Alternatively, you can use the ld flag --export-all-symbols (cf. with the ELF > option --export-dynamic, which I think you must be using to get the observed > behaviour on linux) to make all symbols visible. > > Taking your example, and making it compilable: > > $ cat dlopen.cc > #include <iostream> > #include <memory> > #include <dlfcn.h> > > void * handle, * symbol; > const char * errorStr; > > int main() > { > /* get access to the executable's symbol table */ > handle = dlopen(NULL, RTLD_LAZY); > errorStr = dlerror(); > > if (errorStr) > { > std::clog << "dlopen error '" << errorStr << "'" << std::endl; > } > if (handle) > { > std::clog << "handle ok " << std::endl; > } > else > { > std::clog << "handle NULL " << std::endl; > } > > /* look up the from_string function */ > symbol = dlsym(handle, "functionname"); > errorStr = dlerror(); > > if (symbol) > { > std::clog << "dlsym symbol ok " << std::endl; > } > else > { > std::clog << "dlsym symbol NULL " << std::endl; > } > if (errorStr) > { > std::clog << "dlsym error '" << errorStr << "'" << std::endl; > } > } > > extern "C" __attribute__ ((dllexport)) > void functionname() > { > } > > $ g++ dlopen.cc -o dlopen > > $ ./dlopen > handle ok > dlsym symbol ok
No really comparable as the OP example was in a .dll/.so. You would have to make your main e.g test, build into a dll, and call from a separate main program. The issue appears to be that dlopen( NULL, ...) should work as if it was a reference to the dll containing the call, not the main program. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
