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

[Gary Schneir <gary at fhoosh dot com>]

I am finding a behavior difference with DLOPEN / DLSYM compared to
ubuntu (16.04) and debian (stretch), specifically when the DLOPEN is
passed NULL for the filename.

I have a shared library (.so) file that contains some functions that I
need to location by name.
The code executing this is within the same .so file.  I am trying to
avoid naming the file in the DLOPEN statement.
According to the documentation, the NULL should indicate the "main
program".  It is unclear if this is just the executable, the executable
and its associated libraries, or the library that is running this
function.  Ubuntu and Debian, both seem to treat it as able to find
within the shared library  Regardless of this, there are still
differences / issues, if the filename happens to be invalid.



ubuntu
   $ uname -a
   Linux vm 4.4.0-93-generic #116-Ubuntu SMP Fri Aug 11 21:17:51 UTC
2017 x86_64 x86_64 x86_64 GNU/Linux

   $ g++ --version
   g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609

cygwin
   $ uname -a
   CYGWIN_NT-10.0 DESKTOP-FCHFNAG 2.9.0(0.318/5/3) 2017-09-08 10:19
x86_64 Cygwin

   $ g++ --version
   g++ (GCC) 6.4.0

debian
   $ uname -a
   Linux debian 4.9.0-2-amd64 #1 SMP Debian 4.9.18-1 (2017-03-30) x86_64
GNU/Linux

   $ g++ --version
   g++ (Debian 6.3.0-18) 6.3.0 20170516



LD_LIBRARY_PATH is set the same in all three environments.

===========================

I have the following code in both ubuntu

    std::unique_ptr<const myobject> myobject;
    void * handle, * symbol;
    const char * errorStr;

    /* 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;
    }
    /*
     * if the associated function is found, the string is parsed.
     * if not, then a nullptr is returned to the caller.
     */
    if (symbol)
    {
        std::clog << " calling symbol " << std::endl;
        myobject = (*(from_string_type *)symbol)(str);
    }
.....

================================


If I pass a NULL parameter to DLOPEN - different behavior

handle = dlopen(NULL, RTLD_LAZY)

under ubuntu
 handle ok
 dlsym symbol ok
 calling symbol

>> Correctly finds symbol and works correctly.

under cygwin
 handle ok
 dlsym symbol NULL
 dlsym error 'No such process'

>> Cannot find symbol and therefore fails


under debian
 handle ok
 dlsym symbol ok
 calling symbol

>> Correctly finds symbol and works correctly.

================================

If I pass an invalid library name parameter to DLOPEN - different behvior

handle = dlopen("invalidname", RTLD_LAZY)


On ubuntu,
 dlopen error 'invalidname: cannot open shared object file: No such file
or directory'
 handle NULL
 dlsym symbol ok
 calling symbol
 Segmentation fault (core dumped)

>> Symbol was not correct, even though it was not null an no error was
returned

on cygwin,
 dlopen error 'No such file or directory'
 handle NULL
 dlsym symbol ok
 calling symbol

>> Correctly finds symbol and works correctly.

On debian,
 dlopen error 'invalidname: cannot open shared object file: No such file
or directory'
 handle NULL
 dlsym symbol ok
 calling symbol
 Segmentation fault

>> Symbol was not correct, even though it was not null an no error was
returned

================================

If I pass an correct library name parameter to DLOPEN - same behvior

handle = dlopen("libmine.so", RTLD_LAZY)
On ubuntu,
 handle ok
 dlsym symbol ok
 calling symbol

>> Correctly finds symbol and works correctly.

on cygwin,
 handle ok
 dlsym symbol ok
 calling symbol

>> Correctly finds symbol and works correctly.

On debian,
 handle ok
 dlsym symbol ok
 calling symbol

>> Correctly finds symbol and works correctly.


Can anyone provide some assistance to understanding the differences and
a way get a single code base to work in all three environments without
naming the library file?


Thanks


--
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