From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43137 invoked by alias); 20 Sep 2017 00:20:20 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 43121 invoked by uid 89); 20 Sep 2017 00:20:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=decades X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Sep 2017 00:20:17 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1duSkM-0006au-R4 from joseph_myers@mentor.com ; Tue, 19 Sep 2017 17:20:10 -0700 Received: from digraph.polyomino.org.uk (137.202.0.87) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 20 Sep 2017 01:20:07 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.86_2) (envelope-from ) id 1duSkF-0007Gg-EK; Wed, 20 Sep 2017 00:20:03 +0000 Date: Wed, 20 Sep 2017 00:20:00 -0000 From: Joseph Myers To: Howard Chu CC: Subject: Re: dependency list for static libraries In-Reply-To: <64fe82bd-9c00-b232-98d2-f46182fb16ba@symas.com> Message-ID: References: <53b8973b-40a4-2550-3307-66d7f13707d5@symas.com> <64fe82bd-9c00-b232-98d2-f46182fb16ba@symas.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2017-09/txt/msg00171.txt.bz2 On Tue, 19 Sep 2017, Howard Chu wrote: > Thanks for the suggestion, but that still means introducing > additional/auxiliary files, so it has much the same drawback as libtool files. But it works with the linker itself, without requiring an external tool. > I also find this particularly gross because it breaks the principle of least > surprise; when I see a *.a file I expect ar, nm, and ranlib to work on it. I'm > kind of shocked that such a solution ever flew. It's just doing what glibc has done with libc.so (a linker script) for a very long time (decades?). And libieee.a (removed in glibc 2.27) is/was a single object file, not an archive, because archive semantics wouldn't have been right for it (the object needed to be linked in with -lieee, regardless of whether there were undefined references to any symbol from it). -- Joseph S. Myers joseph@codesourcery.com