From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8868 Path: news.gmane.org!not-for-mail From: u-uy74@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: some odd library loading errors Date: Tue, 17 Nov 2015 13:14:29 +0100 Message-ID: <20151117121429.GI26951@example.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1447762512 13538 80.91.229.3 (17 Nov 2015 12:15:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 12:15:12 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8881-gllmg-musl=m.gmane.org@lists.openwall.com Tue Nov 17 13:15:08 2015 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 1ZyfAA-00035k-Pu for gllmg-musl@m.gmane.org; Tue, 17 Nov 2015 13:15:06 +0100 Original-Received: (qmail 11471 invoked by uid 550); 17 Nov 2015 12:15:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 11376 invoked from network); 17 Nov 2015 12:14:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fripost.org; h= content-disposition:content-type:content-type:mime-version :message-id:subject:subject:from:from:date:date; s=20140703; t= 1447762486; x=1449576887; bh=cF2wNFvKg3CgTWesJyI4g57biM3sfYUrRc0 P4G9noZ4=; b=iCdygkv1vjqbcLXDCKI2cM3zO5iircxl4vVSi2Wqu0WIPHZw8ov clZKBXY1sUOHOAHR7Uj+cxfmBZNadfRzXDeo/sXensobBhnCz14rXafGXRKYMQKa 8+Fpu65569bocMfLG3ihdfPctVaj1ybGd04qoWAADj/aWZF7unorg9f0= X-Virus-Scanned: Debian amavisd-new at fripost.org Content-Disposition: inline Xref: news.gmane.org gmane.linux.lib.musl.general:8868 Archived-At: Hello, The environment: Linux 3.# on x#86 binutils 2.24 musl 1.1.8 compiled for i486 gcc 5.2.0 (the gcc has arch=i486 as the default) No oddities were observed with the above until trying to use libatomic which is provided by gcc-5.2.0. The test case: $ cat >a.c <<____ int main(){ return 0; } ____ $ gcc -o a a.c -L -latomic $ LD_LIBRARY_PATH= ./a Error relocating /libatomic.so.1: __atomic_store_8: symbol not found Error relocating /libatomic.so.1: __atomic_exchange_8: symbol not found Error relocating /libatomic.so.1: __atomic_load_8: symbol not found Error relocating /libatomic.so.1: __atomic_compare_exchange_8: symbol not found $ (No error if doing the same with e.g. -lgcc_s.) Of course the symbols shown in the diagnostics *are* defined in the library. When I look at the store_8_.o object file, I notice though that the __atomic_store_8 is not "a function" even though the value is the same as of select_store_8: $ objdump -t store_8_.o store_8_.o: file format elf32-i386 SYMBOL TABLE: 00000000 l df *ABS* 00000000 store_n.c 00000000 l d .text 00000000 .text 00000000 l d .data 00000000 .data 00000000 l d .bss 00000000 .bss 00000000 l d .text.unlikely 00000000 .text.unlikely 00000030 l F .text 00000016 select_store_8 00000000 l d .debug_info 00000000 .debug_info 00000000 l d .debug_abbrev 00000000 .debug_abbrev 00000000 l d .debug_loc 00000000 .debug_loc 00000000 l d .debug_aranges 00000000 .debug_aranges 00000000 l d .debug_ranges 00000000 .debug_ranges 00000000 l d .debug_line 00000000 .debug_line 00000000 l d .debug_str 00000000 .debug_str 00000000 l d .note.GNU-stack 00000000 .note.GNU-stack 00000000 l d .eh_frame 00000000 .eh_frame 00000000 l d .comment 00000000 .comment 00000000 g F .text 0000002c .hidden libat_store_8 00000000 *UND* 00000000 .hidden libat_lock_1 00000000 *UND* 00000000 .hidden libat_unlock_1 00000000 *UND* 00000000 .hidden libat_feat1_edx 00000000 *UND* 00000000 .hidden libat_store_8_i1 00000030 g .text 00000016 __atomic_store_8 $ I would appreciate help with finding out who is doing wrong: - gcc - ld - musl - myself and what is to be corrected to make it work. The actual practical problem is with the mesa library not being able to load drivers which need symbols from libatomic, but this tiny test case ought to be working, so it is not mesa who is at fault. This does not either seem to involve lazy binding, which is otherwise a known source of problems for mesa. It looks like I can avoid the usage of libatomic with "gcc -fno-sync-libcalls" but the behaviour seems wrong and I would rather see it fixed or otherwise learn if I made an error. Regards, Rune