X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:to:from:subject:message-id:date:mime-version
	:content-type:content-transfer-encoding; q=dns; s=default; b=vw1
	16VmpTvPvGpHBpISFSbfq6+HBiE446DoFQiVvxtkTl6QBfyVWYBH+q7shfsUEzLt
	UG7mxpv52NEXIr1uepMiCoMOPKTOihJJGwWMcj/4PdKitb9LSCoSU2MrecXw7HYw
	L4CK3afVSTT2dy9s6dQDeGVCC1Z6OW6tnrw3PgYI=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:to:from:subject:message-id:date:mime-version
	:content-type:content-transfer-encoding; s=default; bh=/q/r98ag5
	RgTbPxrVtXaBS836lo=; b=D0vgJiMIeGiTLP+c2EJ+R9O4sYBpJdexvePtWUOkM
	KpIzr4OUMX712COZU3gxniZ6t2bE/EP77yhd9keJu0y8c54V+b2cUhO5K6LcvoIG
	6dfPXrnoa9+A9Vh0N1uPCdtRFr1rPsORDEBrH2SmJ08vZ4s3uzsrCLQMcAI4GuXr
	kg=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-0.0 required=5.0 tests=AWL,BAYES_00,KAM_ASCII_DIVIDERS,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=uname, H*Ad:U*gary
X-HELO:	z8.zimbrahostedemail.com
To:	cygwin AT cygwin DOT com
From:	Gary Schneir <gary AT fhoosh DOT com>
Subject:	Problem with differences with DLOPEN / DLSYM compared to ubuntu (16.04) / debian (stretch).
Message-ID:	<eebff651-8e32-68fa-70f5-9d003516db36@fhoosh.com>
Date:	Thu, 14 Sep 2017 08:44:58 -0700
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version:	1.0
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id v8EFjFor029835

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

- Raw text -