From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10219 Path: news.gmane.org!not-for-mail From: Andrei Pozolotin Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl ldd: swt build: Error relocating / symbol not found Date: Fri, 24 Jun 2016 16:23:55 +0000 Message-ID: <576D5E9B.4070608@gmail.com> References: <576B58E6.6040400@gmail.com> <20160623042448.GX10893@brightrain.aerifal.cx> <576C02C2.7070006@gmail.com> <20160623171008.GY10893@brightrain.aerifal.cx> <576C3BB4.3010307@gmail.com> <20160623231527.GZ22574@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010904000304060809000905" X-Trace: ger.gmane.org 1466785475 23023 80.91.229.3 (24 Jun 2016 16:24:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jun 2016 16:24:35 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10232-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jun 24 18:24:26 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1bGTu6-0001W8-67 for gllmg-musl@m.gmane.org; Fri, 24 Jun 2016 18:24:26 +0200 Original-Received: (qmail 12052 invoked by uid 550); 24 Jun 2016 16:24:22 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 12029 invoked from network); 24 Jun 2016 16:24:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:references:to:message-id:date:user-agent:mime-version :in-reply-to; bh=1WNq/Qu6g02T2PSW7hfAb4trYP+PZEMv6OjfOYEAA6E=; b=ZQyDmOrBeVNM3rC3dpmDl4ZEp5OZ7LdmLXO+Nc1MW04FzGDBBfu+rl0wy+JhT71kEj 8nCFO63gSquphoLV+GfQch9GPNcCJiGbM06bks3/nqGNH98AntXzFqvJ0WQjiFpmaSE2 z8nY1PTyjnPi2YWH6uNCIO9SuJz9UPMrQFWpEGmg3CaRHpN8R6d2aG6jtXLaBCaHgO5H fWMzxJ7bne1e0XAXqWFOMyl0VPBiuQAjvI9D7GtUgy+NBvA4kmqR1BRgRTsbDeGRIu2I jcs1OL79Rv3VmotGjc5S1xih76XKH1oohILHLfvB3fgTc7lXBqOBAWF2Tlh5UIUIwiK6 SsVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:references:to:message-id:date :user-agent:mime-version:in-reply-to; bh=1WNq/Qu6g02T2PSW7hfAb4trYP+PZEMv6OjfOYEAA6E=; b=DrVdjFZgoMxmy+LUJ4u+l/INOdz9312jpR4e2aJ5MfbnN5b8OPOTazTbUI4Le3Q/+G JS1FqsFCdgrvpNjw10yOw7iYpnvHlnLp4vNbzmzGqIzURvXUeVRT74svOhXf5cw9Trwc NIeIZDBV1ATqSY8ZQVQugAT2km/8owBKWsBwUtudusNU3dJsoVW8bxjksePbpTG7oPEb 6VOMONfa/9uejM8/EVd96b77bxbw32a2/xqXRbfYstHLMjvVAq846h3+6Th1ztsDmu48 vxXMRYQZtjs5F5UvYGPSMPebPmPN4f4F+tN0PJG5+7P8HqjwZCo6ySEWlp2rQvhPG+YN 127g== X-Gm-Message-State: ALyK8tJ8TZXE1e+60g0xTCOCtrFUH+TohanmdWdFDSKvBysLj9M/JGZKeCkF8sWUeRuPdQ== X-Received: by 10.107.11.206 with SMTP id 75mr7247340iol.55.1466785449688; Fri, 24 Jun 2016 09:24:09 -0700 (PDT) X-Google-Original-From: Andrei Pozolotin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 In-Reply-To: <20160623231527.GZ22574@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:10219 Archived-At: This is a multi-part message in MIME format. --------------010904000304060809000905 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Szabolcs: On 06/23/2016 11:15 PM, Szabolcs Nagy wrote: > * Andrei Pozolotin [2016-06-23 19:42:44 +0000]: >> b) while at the same time musl ldd reporting that library dependency >> tree is resolved with no error: >> >> lddtree /usr/lib/libswt-atk-gtk-4530.so > that's not musl's ldd, but scanelf from pax-utils thank you for pointing out. > when debugging such a complicated setup the output > of tools that may use subtly different library paths > and symbol resolution logic is not very helpful. ok, got it. > ldd /usr/lib/libswt-gtk-4530.so ldd /usr/lib/libswt-gtk-4530.so ldd (0x55e333e6c000) libc.musl-x86_64.so.1 => ldd (0x55e333e6c000) > ldd /usr/lib/libswt-atk-gtk-4530.so ldd /usr/lib/libswt-atk-gtk-4530.so ldd (0x55edc6edc000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x7fc763298000) libc.musl-x86_64.so.1 => ldd (0x55edc6edc000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x7fc763058000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x7fc762d6d000) libintl.so.8 => /usr/lib/libintl.so.8 (0x7fc762b5f000) libffi.so.6 => /usr/lib/libffi.so.6 (0x7fc762957000) libpcre.so.1 => /usr/lib/libpcre.so.1 (0x7fc7626fe000) > would be more interesting.. > > but even then we don't know what's going on > (if libswt-gtk-4530.so is dlopened with RTLD_LOCAL > then its libgobject dependency might not be visible > to libswt-atk-gtk-4530) OK. here is the story: * java native interface: NativeLibrary.load() http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/74e5fc94c77b/src/share/classes/java/lang/ClassLoader.java#l1726 * java JNI implementation: Java_java_lang_ClassLoader_00024NativeLibrary_load http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/74e5fc94c77b/src/share/native/java/lang/ClassLoader.c#l369 * libjvm.so entry point: os::dll_load http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/share/vm/prims/jvm.cpp#l3959 * libjvm.so linux implementation http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/4529ee76d3f9/src/share/vm/runtime/os.hpp#l564 http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/4529ee76d3f9/src/os/linux/vm/os_linux.cpp#l1773 http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/4529ee76d3f9/src/os/linux/vm/os_linux.cpp#l1767 http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/4529ee76d3f9/src/os/linux/vm/os_linux.cpp#l1997 http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/4529ee76d3f9/src/os/linux/vm/os_linux.cpp#l1988 * and finally: it says: dlopen RTLD_LAZY: http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/4529ee76d3f9/src/os/linux/vm/os_linux.cpp#l1988 void * result = ::dlopen(filename, RTLD_LAZY); http://linux.die.net/man/3/dlopen RTLD_LAZY: Perform lazy binding. Only resolve symbols as the code that references them is executed. If the symbol is never referenced, then it is never resolved. (Lazy binding is only performed for function references; references to variables are always immediately bound when the library is loaded.) RTLD_LAZY is good, right? :-) --------------010904000304060809000905 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Szabolcs:

On 06/23/2016 11:15 PM, Szabolcs Nagy wrote:
* Andrei Pozolotin <andrei.pozolotin@gmail.com> [2016-06-23 19:42:44 +0000]:

b) while at the same time musl ldd reporting that library dependency
tree is resolved with no error:

lddtree /usr/lib/libswt-atk-gtk-4530.so

that's not musl's ldd, but scanelf from pax-utils
thank you for pointing out.
when debugging such a complicated setup the output
of tools that may use subtly different library paths
and symbol resolution logic is not very helpful.
ok, got it.
ldd /usr/lib/libswt-gtk-4530.so
ldd /usr/lib/libswt-gtk-4530.so
        ldd (0x55e333e6c000)
        libc.musl-x86_64.so.1 => ldd (0x55e333e6c000)
ldd /usr/lib/libswt-atk-gtk-4530.so
ldd /usr/lib/libswt-atk-gtk-4530.so
        ldd (0x55edc6edc000)
        libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x7fc763298000)
        libc.musl-x86_64.so.1 => ldd (0x55edc6edc000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x7fc763058000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x7fc762d6d000)
        libintl.so.8 => /usr/lib/libintl.so.8 (0x7fc762b5f000)
        libffi.so.6 => /usr/lib/libffi.so.6 (0x7fc762957000)
        libpcre.so.1 => /usr/lib/libpcre.so.1 (0x7fc7626fe000)
would be more interesting..

but even then we don't know what's going on
(if libswt-gtk-4530.so is dlopened with RTLD_LOCAL
then its libgobject dependency might not be visible
to libswt-atk-gtk-4530)
OK. here is the story:

* java native interface: NativeLibrary.load()
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/74e5fc94c77b/src/share/classes/java/lang/ClassLoader.java#l1726

* java JNI implementation: Java_java_lang_ClassLoader_00024NativeLibrary_load
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/74e5fc94c77b/src/share/native/java/lang/ClassLoader.c#l369

* libjvm.so entry point: os::dll_load
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/share/vm/prims/jvm.cpp#l3959

* libjvm.so linux implementation
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/4529ee76d3f9/src/share/vm/runtime/os.hpp#l564
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/4529ee76d3f9/src/os/linux/vm/os_linux.cpp#l1773
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/4529ee76d3f9/src/os/linux/vm/os_linux.cpp#l1767
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/4529ee76d3f9/src/os/linux/vm/os_linux.cpp#l1997
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/4529ee76d3f9/src/os/linux/vm/os_linux.cpp#l1988

* and finally: it says: dlopen RTLD_LAZY:
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/4529ee76d3f9/src/os/linux/vm/os_linux.cpp#l1988
void * result = ::dlopen(filename, RTLD_LAZY);

http://linux.die.net/man/3/dlopen
RTLD_LAZY: Perform lazy binding. Only resolve symbols as the code that references them is executed.
If the symbol is never referenced, then it is never resolved.
(Lazy binding is only performed for function references;
references to variables are always immediately bound when the library is loaded.)

RTLD_LAZY is good, right? :-)

--------------010904000304060809000905--