X-Original-To: alpine-user@lists.alpinelinux.org
Received: from mail-qt0-f182.google.com (mail-qt0-f182.google.com [209.85.216.182])
	by lists.alpinelinux.org (Postfix) with ESMTP id 269555C4E54
	for <alpine-user@lists.alpinelinux.org>; Wed,  7 Feb 2018 18:49:15 +0000 (GMT)
Received: by mail-qt0-f182.google.com with SMTP id g14so3013074qti.2
        for <alpine-user@lists.alpinelinux.org>; Wed, 07 Feb 2018 10:49:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=mime-version:from:date:message-id:subject:to;
        bh=ODp+YX8m7mURLq0yq/yE/T8a86STrhIxpesAxmGWpFM=;
        b=AsByq6T2Eb0oKTb8A7CuHbwc/Xvh/XolirRz7OLbSR6NMoJcBSsKWoirHmfFjA4zdq
         Rk+gfbtefHxWziGzQhnMD23B/sBG2/paoBUrNlLdtL1oPWuJf3aaFD/4Q9eb4BcdULcn
         wxBqGdrEy9u3nFm+NgQfPXTsOOCjwX3u3PMWtVc/b09bwRnEFHx+qtztF5IkpTRFDX+C
         qRGh98Aq88yMHQnIzoJAO4B3+oqxM2sy8iIcpapRIkT4CcFcJ/G7IwnXICA2HRwRtVMP
         jTlsX188G6A11/2M6RgmrpMnV116h+Qf9GSAbMmnOWblRfzymgDTqxy96f/7n3sTMn7v
         FUDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
        bh=ODp+YX8m7mURLq0yq/yE/T8a86STrhIxpesAxmGWpFM=;
        b=DzeLquXcN2WIx3RtCAjT+qcMeyXciWqi5bBx12MPTy/cPKvfYVm0w+o4GOmICqh/yb
         +4baZ0OJBkZet9BOChrkhaaudpG7q+PBRBOkOYtjrK7ts5XKrqL3CE1xsXwYARgriSys
         ECGZNnRU9RliTyBIoLNohPMgV+uFz9iKEhKfFXBsOdXrb6JDDnSfUzwe49axtVBCg/vy
         BX0Ya9GpQ1Qymak1NMfyoFl/p2VV9I6/tSQVkT3BUHJond2lL0Em0epkDbFNpyaZ8z5E
         xGo3Ju4oaY7mXIOqhECHYf8KkJFC8O3bDV0IBVxrmrPs9v0HzailwIaiWeR8FrHStBCr
         jnJw==
X-Gm-Message-State: APf1xPDi5retcq0k+bpSMEAj0fGwE5Fq5XHfkx9WZ+j1r6GBUR1YdVoi
	bATweyLDArRcKgvrPQwJ6dxlMlNFjS2YU75Cg8AQ7Q==
X-Google-Smtp-Source: AH8x2261ouDOf8c2+2xMQ7O/TUoF0yFH562GGCADBPtD7ASJ7oWv/1Cb1QFAr+rcGvJUIfdflNk7kjuLD8fimINGHWw=
X-Received: by 10.200.23.98 with SMTP id u31mr10963251qtk.209.1518029354433;
 Wed, 07 Feb 2018 10:49:14 -0800 (PST)
X-Mailinglist: alpine-user
Precedence: list
List-Id: Alpine Development <alpine-user.lists.alpinelinux.org>
List-Unsubscribe: 
	<mailto:alpine-user+unsubscribe@lists.alpinelinux.org?subject=unsubscribe>
List-Post: <mailto:alpine-user@lists.alpinelinux.org>
List-Help: <mailto:alpine-user+help@lists.alpinelinux.org?subject=help>
List-Subscribe: 
	<mailto:alpine-user+subscribe@lists.alpinelinux.org?subject=subscribe>
MIME-Version: 1.0
Received: by 10.12.178.203 with HTTP; Wed, 7 Feb 2018 10:49:14 -0800 (PST)
From: Andrew Bell <andrew.bell.ia@gmail.com>
Date: Wed, 7 Feb 2018 13:49:14 -0500
Message-ID: <CACJ51z03eDEYduFEATzQ=UstLK-Mebn1erVsaNZbn8v62_x3iw@mail.gmail.com>
Subject: [alpine-user] ld-musl not resolving symbols
To: alpine-user@lists.alpinelinux.org
Content-Type: multipart/alternative; boundary="94eb2c128c026e00860564a3c0d6"

--94eb2c128c026e00860564a3c0d6
Content-Type: text/plain; charset="UTF-8"

Hi,

I'm trying to run a program I've written that opens a library with
dlopen("libname", RTLD_NOW).   dlopen() succeeds without error and I can
use dlsym() to get a good address of an entry point in the .so, but global
symbols in the dlopen'ed library seem not to be resolved (they're null).

The really strange thing is that this only happens if I run my code as a
python extension through the python2.7 binary.  If I invoke my code through
my own driver, things work fine.

Is there anything that python could be doing that would tell ld-musl not to
resolve all the symbols when dlopen'ing a library?  The documentation I've
seen says that ld-musl always resolves all the symbols in a library when
dlopen() is called.  Are there exceptions to this?  Is there some way I can
trace the behavior of ld-musl?

Thanks,

-- 
Andrew Bell
andrew.bell.ia@gmail.com

--94eb2c128c026e00860564a3c0d6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>I&#39;m trying to run a program I&#=
39;ve written that opens a library with dlopen(&quot;libname&quot;, RTLD_NO=
W).=C2=A0 =C2=A0dlopen() succeeds without error and I can use dlsym() to=C2=
=A0get a good address of an entry point in the .so, but=C2=A0global symbols=
 in the dlopen&#39;ed library seem not to be resolved (they&#39;re null).</=
div><div><br></div><div>The really strange thing is that this only happens =
if I run my code as a python extension through the python2.7 binary.=C2=A0 =
If I invoke my code through my own driver, things work fine.</div><div><br>=
</div><div>Is there anything that python could be doing that would tell ld-=
musl=C2=A0not to resolve all the symbols when dlopen&#39;ing a library?=C2=
=A0 The documentation I&#39;ve seen says that ld-musl=C2=A0always resolves =
all the symbols in a library when dlopen() is called.=C2=A0 Are there excep=
tions to this?=C2=A0 Is there some way I can trace the behavior of ld-musl?=
</div><div><br></div><div>Thanks,</div><div><br>-- <br><div class=3D"gmail_=
signature" data-smartmail=3D"gmail_signature">Andrew Bell<br><a href=3D"mai=
lto:andrew.bell.ia@gmail.com" target=3D"_blank">andrew.bell.ia@gmail.com</a=
></div>
</div></div>

--94eb2c128c026e00860564a3c0d6--


---
Unsubscribe:  alpine-user+unsubscribe@lists.alpinelinux.org
Help:         alpine-user+help@lists.alpinelinux.org
---