From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56103 invoked by alias); 19 Aug 2017 08:11:34 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 55067 invoked by uid 89); 19 Aug 2017 08:11:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=doubts, H*M:stream, risk, our X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 19 Aug 2017 08:11:06 +0000 Received: from stream.wildebeest.org (ADijon-357-1-27-209.w109-217.abo.wanadoo.fr [109.217.50.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id A25BF33138DF; Sat, 19 Aug 2017 10:11:03 +0200 (CEST) Received: by stream.wildebeest.org (Postfix, from userid 1000) id 6C2FB101F91; Fri, 18 Aug 2017 22:38:37 +0200 (CEST) Date: Sat, 19 Aug 2017 08:11:00 -0000 From: Mark Wielaard To: Ulf Hermann Cc: elfutils-devel@sourceware.org Subject: Re: [PATCH v2] Check if gcc complains about __attribute__ (visibility(..)) Message-ID: <20170818203837.GB3169@stream> References: <5e89ee5d-ecdf-1e3a-3e67-0d617b524da6@qt.io> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5e89ee5d-ecdf-1e3a-3e67-0d617b524da6@qt.io> User-Agent: Mutt/1.8.3 (2017-05-23) X-IsSubscribed: yes X-SW-Source: 2017-q3/txt/msg00091.txt.bz2 On Fri, Aug 18, 2017 at 01:06:36PM +0200, Ulf Hermann wrote: > If so, define attribute_hidden to be empty. Also, use attribute_hidden > in all places where we hide symbols. If this attribute is missing, it > simply means that we cannot hide private symbols in the binary using > attributes. This disables some optimizations and may increase the risk > of symbol name clashes with other libraries, but is not fatal. > > However, we still employ linker version scripts to explicitly define > the exported symbols. This serves much of the same purpose. Also, as > all our symbols are prefixed with the library name, and "__" for > private ones, the chance of clashes is low anyway. Like the previous one, I have my doubts. But it actually makes the source code slightly more consistent. So applied. Thanks, Mark