Re: SID configury, libtoolery updated

Dave Brolley <[email protected]> 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.