Re: [v3] use AM_ICONV

["Kaveh R. GHAZI" <ghazi at caip dot rutgers dot edu>]

On Tue, 6 Feb 2007, Paolo Carlini wrote:

> Benjamin Kosnik wrote:
>
> >> I have been able to reproduce such failures: the problem is at link
> >> time, the _libiconv symbol remains undefined, apparently on such
> >> targets libiconv should be linked to the final executable. Is that
> >> doable?
> >
> > I think this should already be happening, due to LIBICONV substitution.
> >
> > Maybe this isn't being picked up from the site.exp by dejagnu? Or
> > something in conformance.exp needs to add in LIBICONV flags?
>
> Thanks, I can probably further investigate the issue along that
> direction relatively soon (conditional to access to darwin-powerpc
> hardware ;) Maybe Kaveh can do the same on Solaris?!?
> Paolo.

Hi Guys - I'd like to reiterate my opposition to *ever* linking gnu
libiconv from /usr/local/foo or wherever with target executables on
bi-arch 32/64 systems like solaris2.  This is completely wrong because
either 32-bit or 64-bit executables will all fail to link with
/usr/local/lib/libiconv.a due to 32/64 incompatibilities.  I first
explained the problem here:
http://gcc.gnu.org/ml/libstdc++/2006-12/msg00079.html

This problem is not solaris2-specific.  On any bi-arch systems you would
have to require *two* libraries i.e. think multilibbed, or only link gnu
libiconv.a with the appropriate arch and avoid it in the other.  But this
would lead to one set of features being supported in say 32-bit mode and
another set in 64-bit.  Users would find that situation odd and I don't
know that GCC gracefully handles that well at all layers either.

Note the --without-libiconv-prefix (without!) is working again and I have
obtained testsuite results on solaris2.  That's all I care about for
myself, but I fear any hapless bi-arch user with gnu libiconv installed
will not know they have to use this flag when building GCC.  They'll get
massive failures for the libstdc++ and/or libjava testsuite depending on
their particular setup and whether they test 32 or 64 bit mode and what
mode the gnu libiconv.a is built for.


Here's my take on a solution:

1.  Only ever auto-detect iconv et al. from the system area, either in
libc or libiconv.  But if it's libiconv, then don't use a copy in e.g.
/usr/local, only take it from the system areas.  Presumably the OS would
provide both 32 and 64 bit copies if the system supported more than one
arch.

2.  If we must support gnu libiconv, never do so unless the user asks for
it via a configure flag.  Require them to specify all arches somehow.
Then if they are missing an arch on a bi-arch system it's their fault.

3.  Better would be allow building and multilibbing libiconv from the top
level bootstrap.  We would have to install multilibbed copies of libiconv
for the target just like we install multiple copies of libstdc++.  This is
the only real clean solution to the multilib problem AFAICT.

I think at a minimum we need to do 1 and 3.  I don't like 2 really.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu