Re: Problem with differences with DLOPEN / DLSYM compared to ubuntu (16.04) / debian (stretch).

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

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