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
