From owner-freebsd-stable@FreeBSD.ORG Mon Oct 14 16:30:02 2013 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E3B70922 for ; Mon, 14 Oct 2013 16:30:02 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.5]) by mx1.freebsd.org (Postfix) with ESMTP id A9D3924B2 for ; Mon, 14 Oct 2013 16:30:01 +0000 (UTC) Received: from [216.82.249.51:6540] by server-5.bemta-12.messagelabs.com id 24/36-01094-D5A1C525; Mon, 14 Oct 2013 16:22:53 +0000 X-Env-Sender: mi+thun@aldan.algebra.com X-Msg-Ref: server-14.tower-190.messagelabs.com!1381767773!1782111!1 X-Originating-IP: [209.251.202.129] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7263 invoked from network); 14 Oct 2013 16:22:53 -0000 Received: from unknown (HELO PSYEXCHPMTA1.TIMEINC.COM) (209.251.202.129) by server-14.tower-190.messagelabs.com with SMTP; 14 Oct 2013 16:22:53 -0000 Received: by PSYEXCHPMTA1.TIMEINC.COM id hbgd5o19f0gd for ; Mon, 14 Oct 2013 12:22:52 -0400 (envelope-from ) Message-ID: <525C1A5C.2030605@aldan.algebra.com> Date: Mon, 14 Oct 2013 12:22:52 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; uk; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: stable@FreeBSD.org Subject: runtime linker on 9.x/i386: clang vs. gcc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 16:30:03 -0000 Hello! I'm seeing a strange problem with clang-compiled binaries on 9.x/i386 system. Here it is: if a shared library A needs a symbol provided by a shared library B, libA will fail to load into a process even if the executable is linked with libB. The only fix (work-around?) is to relink libA to explicitly depend on libB. A temporary work-around is to use LD_PRELOAD to list all of the necessary libBs... One example of this is reported in ports/180473 -- the libprldap6.so refuses to load because of the symbols it needs from libnspr4.so. For some reason, the fact, that -lnspr4 is linked into the executable (seamonkey or thunderbird), is not sufficient... As the ticket suggests, using gcc46 (Mozilla rejects gcc-4.2.x nowadays) instead of clang solves the problem (though an even better solution is in place since this weekend). Another example is xorg-server, which, for me, can not load some of the drivers because they complain of missing symbols: (EE) Failed to load /opt/lib/xorg/modules/drivers/vboxvideo_drv.so: /opt/lib/xorg/modules/drivers/vboxvideo_drv.so: Undefined symbol "DRIFinishScreenInit" The DRIFinishScreenInit is provided by libdri.so, which the server also loads... But, somehow, that is not sufficient. Rebuilding vboxvideo_drv.so (provided by emulators/virtualbox-ose-additions ) with the stock cc (gcc-4.2.1) resolves the linking problem -- even if Xorg executable and the libdri.so remain clang-compiled. I am not prepared to argue, whether that's a "right" or "wrong" behavior -- but it certainly is inconsistent, because it is only manifested on i386 and only when the compiler is clang. Any thoughts? -mi