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