From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24232 invoked by alias); 20 Jun 2005 15:22:35 -0000 Mailing-List: contact sid-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sources.redhat.com Received: (qmail 24075 invoked by uid 22791); 20 Jun 2005 15:21:48 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 20 Jun 2005 15:21:48 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j5KFLkiY015568 for ; Mon, 20 Jun 2005 11:21:46 -0400 Received: from zenia.home.redhat.com (sebastian-int.corp.redhat.com [172.16.52.221]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j5KFLju12960; Mon, 20 Jun 2005 11:21:45 -0400 To: Dave Brolley Cc: "Frank Ch. Eigler" , sid@sources.redhat.com Subject: Re: SID configury, libtoolery updated References: <42A9F652.3050802@redhat.com> <42A9F94A.4080109@redhat.com> <20050617192444.GB2259@redhat.com> <42B33EAD.5040000@redhat.com> From: Jim Blandy Date: Mon, 20 Jun 2005 15:22:00 -0000 In-Reply-To: <42B33EAD.5040000@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-q2/txt/msg00049.txt.bz2 Dave Brolley writes: > --enable-shared used to tbe the default. It is no longer? Here's (I think) the logic in libiberty/config.table, from 'cvs annotate': 1.10 (dj 27-Dec-04): # If they didn't specify --enable-shared, don't generate shared libs. 1.10 (dj 27-Dec-04): case "${enable_shared}" in 1.10 (dj 27-Dec-04): yes) shared=yes ;; 1.10 (dj 27-Dec-04): no) shared=no ;; 1.10 (dj 27-Dec-04): "") shared=no ;; 1.10 (dj 27-Dec-04): *) shared=yes ;; 1.10 (dj 27-Dec-04): esac I think there are two reasons this hasn't shown up in the past: - Older libtools did only loose sanity checking when linking IA-32 shared libraries, so they didn't mind being given a .a file as a dependency for a .so. (The deplibs_check_method var in the libtool script was set to 'pass_all'.) And (I believe) the .o files from libiberty/pic/libiberty.a that actually got used by SID don't contain any non-PIC relocs. So the link would actually use the non-PIC libiberty/libiberty.a, but it would go fine anyway. - Those same older libtools would object to linking any .so against any .a on the x86_64. (The deplibs_check_method var was set to a file_magic string. The newer libtools treat the x86_64 like the IA-32.) And if you did get it past libtool, libiberty/libiberty.a contained non-PIC relocs, and the linker itself complained. So to get SID to work on the x86_64, we needed to upgrade libtool, and fix the long-standing (but until now silent) bug in the choice of libiberty. My first choice solution would be to use libtool to build libiberty. But that's what was tried in December 2004, and then backed out; see the binutils archives. So libtoolizing libiberty requires technical and political effort. It wouldn't be bad to have an alternative. Which is why I like Frank's suggestion that we simply remove SID's dependence on libiberty by copying over source files --- the code duplication is probably less trouble than negotiating with libiberty.