On Mon, Jan 28, 2013 at 4:07 AM, Michael Haubenwallner
<michael.haubenwall...@salomon.at> wrote:

> But still curious if you've been able to reproduce the problem,
> and why you didn't encounter this problem beforehand.

As I mentioned before, because of --boot-ld-flags, with earlier libgcc
and libstdc++ installed in that directory.

> Yes, but (you've asked) here is this situation I don't want to configure 
> extra deplib-prefixes
> for (remember bullfreeware is listed as provider for gcc-binaries):
>
> * bullfreeware's libiconv-1.13.1 and gettext-0.17 is installed in 
> /opt/freeware,
> * /usr/lib/libintl.a is symlinked to /opt/freeware/lib (by bullfreeware's 
> RPM),
> * /usr/lib/libiconv.a is the original AIX' one.
>
> Now, /usr/lib/libintl.a needs /opt/freeware/lib/libiconv.a[libiconv.so.2], 
> and it does
> contain the correct RUNPATH. But subsequent binaries linking against 
> /usr/lib/libintl.a
> don't (necessarily) know about the need to add /opt/freeware/lib as RUNPATH, 
> so these
> binaries break with libiconv.so.2 not being found as member of 
> /usr/lib/libiconv.a, because
> AIX unfortunately does stop its shared-library search at the first archive 
> filename found.
>
> This also is the main reason for my filename-based-shared-library-versioning 
> thing.

Over the weekend, I successfully tested a different way to configure
and build: all static libraries.  If you build and privately install
GMP, MPFR, MPC and LIBICONV configured as static libraries
(--enable-static --disable-shared) and install in /prereq, then,
combined with your patch to enable --static-libstdc++ --static-libgcc,
the resulting GCC only depends on AIX libc.a -- no other shared
libraries. Bull Freeware can distribute the shared versions of the
libraries for other applications, but they do not need to be GCC
dependencies.

- David

Reply via email to