From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id C521C3858D28 for ; Sat, 4 Dec 2021 16:19:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C521C3858D28 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-528-_zLinVfJMruAZCTnygFHjg-1; Sat, 04 Dec 2021 11:19:36 -0500 X-MC-Unique: _zLinVfJMruAZCTnygFHjg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id F22D9108088A; Sat, 4 Dec 2021 16:19:34 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.194.188]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6218C60BE5; Sat, 4 Dec 2021 16:19:33 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 1B4GJT96417537 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 4 Dec 2021 17:19:30 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 1B4GJSnI417536; Sat, 4 Dec 2021 17:19:28 +0100 Date: Sat, 4 Dec 2021 17:19:28 +0100 From: Jakub Jelinek To: Peter Bergner Cc: Michael Meissner , Thomas Koenig , gcc mailing list , Bill Schmidt , David Edelsohn , Segher Boessenkool , "fortran@gcc.gnu.org" Subject: Re: [power-ieee128] What should the math functions be annotated with? Message-ID: <20211204161928.GF2646553@tucnak> Reply-To: Jakub Jelinek References: <20211203113536.GQ2646553@tucnak> <99088f27-59cf-abec-8dc7-388ee2d2c5a8@netcologne.de> <20211204102919.GD2646553@tucnak> <021be175-077b-7121-d9a7-b06e6311ca90@netcologne.de> <5813f8b5-df89-b67b-58e3-f1dd5c674724@linux.ibm.com> MIME-Version: 1.0 In-Reply-To: <5813f8b5-df89-b67b-58e3-f1dd5c674724@linux.ibm.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2021 16:19:41 -0000 On Sat, Dec 04, 2021 at 10:12:37AM -0600, Peter Bergner via Gcc wrote: > On 12/4/21 9:37 AM, Peter Bergner wrote: > > On 12/4/21 9:25 AM, Michael Meissner wrote: > > ubuntu@gcc-fortran:/home/tkoenig/Tst$ ldd ./a.out > > ./a.out: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./a.out) > > linux-vdso64.so.1 (0x00007f6339620000) > > libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6 (0x00007f63393d0000) > > /opt/at15.0/lib64/ld64.so.2 => /lib64/ld64.so.2 (0x00007f6339640000) > > To go into a little more in depth, the important thing is your a.out > was linked with the correct loader: > > ubuntu@gcc-fortran:/home/tkoenig/Tst$ readelf -l a.out | grep interpreter > [Requesting program interpreter: /opt/at15.0/lib64/ld64.so.2] > > > ...and the error message you saw was a good thing, it showed your a.out was > expecting to see the newer GLIBC 2.34 and didn't. The reason it didn't > was that the system ldd which you used does some magic and overrides the > a.out runtime loader with the system loader and that loader uses its > own ld.so.cache which doesn't include AT15's library paths. The AT15 > loader has its own /opt/at15.0/etc/ld.so.cache which includes its lib dirs > as well the system lib dirs. This way, the AT15 libs are found first and > any library AT15 doesn't provide it automatically picked up from the system. > As long as you keep the AT15 bin path before the system bin dirs, you should > be fine. But when Thomas is working on the vanilla gcc tree, trying to make it work for Fortran, I think he'll need to patch that gcc tree too to use the AT15's dynamic linker and rpath like the AT15 gcc is. Jakub