Re: [bug-gnu-libiconv] configure using iconv.m4 on 64-bit systems failing

[Bruno Haible]

Hi,

Ben Taylor wrote on 2008-07-15 in a reply to
<http://lists.gnu.org/archive/html/bug-gnu-libiconv/2008-07/msg00011.html>:

> > When you built libiconv for both ABIs, you hopefully did this with different
> > --prefix options (e.g. --prefix=/usr/local32 and --prefix=/usr/local64,
> > respectively), otherwise big confusion will happen, like the one you are 
> > seeing.
> 
> Sun doesn't do their libraries this way.  Their hierarchy is
> {prefix}/lib, and {prefix}/lib/amd64 or {prefix}/lib/sparcv9
> depending on the hardware.
> 
> So this means you can have separate packages for 32-bit and 64-bit, but
> they live in the same hierarchy.

You can use this Solaris convention with Autoconf based packages, if you
specify
  1) the --libdir explicitly (for the location where to install libraries),
  2) augment CPPFLAGS and LDFLAGS (for where to search for installed libraries),
     instead of using the various --with-*-prefix options. The --with-*-prefix
     are handy shortcuts for managing CPPFLAGS and LDFLAGS. If they don't work
     with a particular convention, then blech.

> Would you consider generating a package config since autoconf
> is incapable of handling this kind of infrastructure.

No, this is not a solution. The usual config scripts can either
  - omit the runtime path dependencies, leading to binaries that don't run,
or
  - use -R options, leading to errors if the library is being used with gcc,
or
  - use -Wl,-rpath options, leading to errors if the library is being used
    with Sun cc.
A dead end.

Bruno