From: Jim Blandy <jimb@redhat.com>
To: Dave Brolley <brolley@redhat.com>
Cc: "Frank Ch. Eigler" <fche@redhat.com>, sid@sources.redhat.com
Subject: Re: SID configury, libtoolery updated
Date: Mon, 20 Jun 2005 15:22:00 -0000 [thread overview]
Message-ID: <vt2k6kp5a5p.fsf@zenia.home> (raw)
In-Reply-To: <42B33EAD.5040000@redhat.com>
Dave Brolley <brolley@redhat.com> 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.
next prev parent reply other threads:[~2005-06-20 15:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-04 3:18 Jim Blandy
2005-06-04 12:25 ` Frank Ch. Eigler
2005-06-04 15:22 ` Jim Blandy
2005-06-10 20:21 ` Dave Brolley
2005-06-10 20:34 ` Dave Brolley
2005-06-17 19:18 ` Jim Blandy
2005-06-17 19:24 ` Frank Ch. Eigler
2005-06-17 21:20 ` Dave Brolley
2005-06-20 15:22 ` Jim Blandy [this message]
2005-06-20 16:00 ` Dave Brolley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vt2k6kp5a5p.fsf@zenia.home \
--to=jimb@redhat.com \
--cc=brolley@redhat.com \
--cc=fche@redhat.com \
--cc=sid@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).