This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Problem with differences with DLOPEN / DLSYM compared to ubuntu (16.04) / debian (stretch).
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