From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1606 invoked by alias); 18 Oct 2011 02:06:58 -0000 Received: (qmail 1594 invoked by uid 22791); 18 Oct 2011 02:06:56 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-iy0-f175.google.com (HELO mail-iy0-f175.google.com) (209.85.210.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 18 Oct 2011 02:06:40 +0000 Received: by iafi7 with SMTP id i7so141360iaf.20 for ; Mon, 17 Oct 2011 19:06:40 -0700 (PDT) Received: by 10.43.52.136 with SMTP id vm8mr662949icb.26.1318903600220; Mon, 17 Oct 2011 19:06:40 -0700 (PDT) Received: from [10.0.0.4] ([64.128.19.234]) by mx.google.com with ESMTPS id g16sm1206510ibs.8.2011.10.17.19.05.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Oct 2011 19:05:39 -0700 (PDT) From: Perry Smith Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: AIX library issues Date: Tue, 18 Oct 2011 04:48:00 -0000 Message-Id: To: gcc@gcc.gnu.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00263.txt.bz2 I've discovered an issue which I can't believe I'm the first to bump in to. But I've checked older gcc installs and find the same issue. I did a brief internet search and found sorta similar issues but I'm not sure if they explained it as I see it. I bumped into this while trying to build lzma. What follows is from a gcc 4.5.2 build using gcc 4.5.2 to compile it running AIX 6.1 TL05 SP06. But, as I said, I've compared this to output produced by a gcc 4.3.1 running on AIX 5.3 with the same results. On AIX, there is a tool called dump. dump -H dumps out the header of the loader section. When I link lzma and try to run it, it dies with a long error (that I won't post). In essence it boils down to this: lzma needs libstdc++. In that archive is one shared object. The loader can find lzma and can find the libstdc++ object but it can not load either because libstc++ depends upon another library that the loader can not find. Here is why: dump -H libstdc++.so.6 ./powerpc-ibm-aix6.1.0.0/libstdc++-v3/src/.libs/libstdc++.so.6.orig: ***Loader Section*** Loader Header Information VERSION# #SYMtableENT #RELOCent LENidSTR 0x00000001 0x00000fe0 0x000033b6 0x000000da=20=20=20=20= =20=20=20 #IMPfilID OFFidSTR LENstrTBL OFFstrTBL 0x00000003 0x0003e9a8 0x0002dec7 0x0003ea82=20=20=20=20= =20=20=20 ***Import File Strings*** INDEX PATH BASE MEMBER=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 0 /usr/work/build/gcc-4.5.2/powerpc-ibm-aix6.1.0.0/libstdc++-v3/src:/u= sr/work/build/gcc-4.5.2/powerpc-ibm-aix6.1.0.0/libstdc++-v3/src/.libs:/usr/= work/build/gcc-4.5.2/./gcc:/usr/lib:/lib=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 1 libc.a shr.o=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20 2 libgcc_s.a shr.o=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20 What this is telling us is that libstdc++.so.6 needs libc.a(shr.o) and libgcc_s.a(shr.o) and it is also telling us that when libc.a(shr.o) and libgcc_s.a(shr.o) is needed at run time, the list of places searched is the list of directories listed in entry 0. But the list is the list of where the library is built -- not where it (or more importantly where libgcc_s.a) will be installed. When I configured and built this gcc, prefix path was set to /gsa/ausgsa/projects/r/ruby. Here are the first few lines of my config.log: /usr/work/src/gcc-4.5.2/configure --prefix=3D/gsa/ausgsa/projects/r/ruby -= -with-gmp=3D/gsa/ausgsa/projects/r/ruby --with-mpfr=3D/gsa/ausgsa/projects/= r/ruby --with-mpc=3D/gsa/ausgsa/projects/r/ruby --disable-nls --enable-thre= ads=3Daix --with-libiconv-prefix=3D/usr --enable-languages=3Dc,c++ I have told configure that /gsa/ausgsa/projects/r/ruby is the place I plan to install this compiler. Yet its search path does not include this path at all. For most (perhaps all) of the other shared objects, the path doesn't make THAT much difference because the only library needed is libc.a and it will be found in /usr/lib. The executables suffer from the same thing. Again, it doesn't seem to matter since they only include libc.a. I've been told but I do not know for sure that libtool understands AIX's peculiarities. In particular, what needs to happen is a relink needs to be done. The executables and libraries are correct for testing the results in the current directory. But they are not correct when the final result is moved into the place it was designed to go in to. The good news is that a program compiled with gcc produces an object file with the proper path so all the programs produced from the final gcc are correct. I'm fairly sure that this isn't a pilot error (I somehow botched the call to configure or something like that) but I sure would be happy to find out it was my fault. This seems like a rather hard nut to crack. I hope all this is clear. I'm more than happy to help out in solving this. Thank you, pedz