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
