From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24552 invoked by alias); 21 Apr 2004 14:35:56 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 24539 invoked from network); 21 Apr 2004 14:35:55 -0000 Received: from unknown (HELO rwcrmhc13.comcast.net) (204.127.198.39) by sources.redhat.com with SMTP; 21 Apr 2004 14:35:55 -0000 Received: from lucon.org ([24.6.43.109]) by comcast.net (rwcrmhc13) with ESMTP id <2004042114355401500pv4u9e>; Wed, 21 Apr 2004 14:35:54 +0000 Received: by lucon.org (Postfix, from userid 1000) id 169B464D01; Wed, 21 Apr 2004 07:35:54 -0700 (PDT) Date: Wed, 21 Apr 2004 15:10:00 -0000 From: "H. J. Lu" To: Jim Wilson Cc: gcc-patches@gcc.gnu.org, David Mosberger , gcc@gcc.gnu.org Subject: Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols Message-ID: <20040421143554.GB15381@lucon.org> References: <16516.6915.86308.779779@napali.hpl.hp.com> <4085A6D9.2000003@specifixinc.com> <20040420232802.GB657@lucon.org> <16517.46034.449201.262407@napali.hpl.hp.com> <20040420234152.GA966@lucon.org> <16517.46957.842543.155986@napali.hpl.hp.com> <1082507163.1062.51.camel@leaf.tuliptree.org> <20040421055729.GA6998@lucon.org> <1082529516.1065.177.camel@leaf.tuliptree.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1082529516.1065.177.camel@leaf.tuliptree.org> User-Agent: Mutt/1.4.1i X-SW-Source: 2004-04/txt/msg00975.txt.bz2 On Tue, Apr 20, 2004 at 11:38:36PM -0700, Jim Wilson wrote: > On Tue, 2004-04-20 at 22:57, H. J. Lu wrote: > > This patch puts libunwind.a in libgcc_s.so.1. The test result is at > > We can do it on ia64 since PIC is default on ia64. > > IA-64 code is PIC by default. However, it is not true that static > library code and shared library code are the same. There are > differences because of the IA-64 ABI, for instance, the rules that say > "own" data can be put in the small data section, but what qualifies as > "own" data is different for shared libraries and static libraries. This > stuff is controlled by the -fpic option. You must use -fpic for all > code that goes into a shared library. Note: -fpic has always meant > compile this code for shared libraries, this is even true on systems > like IA-64 where code is PIC by default. There is no guarantee that > code in libunwind.a was compiled with -fpic. I don't see how this can > work. We can always require to compile the static libunwind library with -fpic. H.J.