From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10973 invoked by alias); 24 Oct 2011 00:59:54 -0000 Received: (qmail 10962 invoked by uid 22791); 24 Oct 2011 00:59:53 -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 X-Spam-Check-By: sourceware.org Received: from mail-gx0-f175.google.com (HELO mail-gx0-f175.google.com) (209.85.161.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 24 Oct 2011 00:59:38 +0000 Received: by ggnj1 with SMTP id j1so4353332ggn.20 for ; Sun, 23 Oct 2011 17:59:37 -0700 (PDT) Received: by 10.100.39.15 with SMTP id m15mr4731455anm.130.1319417977732; Sun, 23 Oct 2011 17:59:37 -0700 (PDT) Received: from [10.0.0.4] ([64.128.19.234]) by mx.google.com with ESMTPS id l27sm24248010ani.21.2011.10.23.17.59.36 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 23 Oct 2011 17:59:36 -0700 (PDT) Subject: Re: AIX library issues Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Perry Smith In-Reply-To: Date: Mon, 24 Oct 2011 09:45:00 -0000 Cc: gcc@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <1A81E3FB-BB92-4057-AA3F-66C0FC853895@gmail.com> References: <25EA9ADB-AC03-42B9-9090-545D5FC9ADC7@gmail.com> To: David Edelsohn 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/msg00415.txt.bz2 On Oct 23, 2011, at 1:59 PM, David Edelsohn wrote: > On Sun, Oct 23, 2011 at 10:16 AM, Perry Smith wrote: >=20 >> libgomp.so.1 wants libc.a, libpthreads.a, and libgcc_s.a. The first two= do not present a problem. But there are four libgcc_s.a (normal, ppc64, p= thread, and ppc64+pthread). >>=20 >> Note that there is also four versions of libgomp.so.1 (normal, ppc64, pt= hread, ppc64+pthread). >>=20 >> My question is: which libgcc_s.a should I link to? (this question is fo= r each of the four versions of libgomp.so.1). >>=20 >> Setting LIBPATH or whatever I do is going to override the internal path = (since the internal path is broken). So, this may be a question that has n= ever been asked or answered. >>=20 >> My knee jerk is that the normal libgomp.so.1 wants the normal libgcc_s.a= , the ppc64 wants the ppc64, etc. But I notice that it will always include= pthread so that is what caused me to pause and ask. >>=20 >> Part of me wonders if the two non-pthread versions of libgomp make any s= ense. I don't really know anything about libgomp. >=20 > libgomp (-fopenmp) does not make sense without pthreads. -fopenmp > implies pthreads. >=20 > One thing to note: AIX tools default to 32 bit mode, although all > systems are 64 bit, unlike GNU/Linux, which defaults to 64 bit mode > (on x86-64 and PPC64). >=20 > Only two of the four libgomp multilibs truly are necessary, but > avoiding the non-pthread builds is not worth the trouble. The > non-pthread libgomp libraries never will be used, unless GCC is > invoked incorrectly. Each library, including libgomp, should list its > multilib install directory first, e.g., ppc64 pthread would be >=20 > -Wl,-blibpath:.../lib/gcc/powerpc-ibm-aix6.1.3.0/4.6.0/pthread/ppc64:.../= lib/pthread/ppc64:/usr/lib:/lib >=20 > and default would be >=20 > -Wl,-blibpath:.../lib/gcc/powerpc-ibm-aix6.1.3.0/4.6.0:.../lib:/usr/lib:/= lib >=20 > The GCC build process and driver directory search process make a lot > of assumptions that the system directories follow a Linux/SVR4/Solaris > layout. To follow AIX style, the PPC64 and PPC32 non-reentrant > (non-pthreads) libraries should be archived into the same file > libgomp.a (which never would be referenced) and the reentrant > (pthreads) libraries for PPC64 and PPC32 should be archived into > libgomp_r.a. The benefit has not been shown to be worth the effort. Thanks David, One more question on this quest (drifting a little more off topic). In my log files I see a lot of these errors: > ld: 0711-768 WARNING: Object ../libsupc++/.libs/libsupc++convenience.a[eh= _terminate.o], section 1, function .std::terminate(): > The branch at address 0x10c is not followed by a recognized no-op > or TOC-reload instruction. The unrecognized instruction is 0x0. The build continues and completes. I just want to make sure that I can saf= ely ignore them. Surfing the web, sometimes I see people flag the as error= s and other times not. Thank you again, pedz