[Linuxppc-users] Toolchain version for RHEL 7.1

Wed Nov 14 05:34:30 AEDT 2018

OK, that's good so far.   I still don't understand why you're seeing the
error then.   A number of additional questions:

1) I see weird names in some of logs below:
/lib64/ld64.30.2
libm.30.6
libc.30.6
Note the number "30" in place of the string "so" (shared object).  Is this
actually real, or was this just somehow corrupted in the output?

2) When executing the "erlc" binary, do you have either LD_PRELOAD or
LD_LIBRARY_PATH (or any LD_... variable, really) set to anything?   If so,
can you try with those variables unset?

3) Can you send me the output (stderr) of running "erlc" with
LD_DEBUG=all ?

Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  STSM, GNU/Linux compilers and toolchain
  IBM Deutschland Research & Development GmbH
  Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294

From:	Ben Hood <ben at relops.com>
To:	linuxppc-users at lists.ozlabs.org
Date:	13.11.2018 18:50
Subject:	Re: [Linuxppc-users] Toolchain version for RHEL 7.1
Sent by:	"Linuxppc-users" <linuxppc-users-bounces
            +ulrich.weigand=de.ibm.com at lists.ozlabs.org>

Here is the output - it appears to have the line you expected:

$ readelf -1 /tmp/c4/erts-10.1.1/bin/erlc
Elf file type is EXEC (Executable file)
Entry point OxlOOOOecO
fhere are 9 program headers, starting at offset 64
Program Headers:
Type		     Offset		            VirtAddr
PhysAddr
            FileSiz		            MemSiz
Flags Align
PHDR		     0x0000000000000040 0x0000000010000040
0x0000000010000040
            OxOOOOOOOOOOOOOlf8 OxOOOOOOOOOOOOOlf8		 R		 8
INTERP		     0x0000000000000238 0x0000000010000238
0x0000000010000238
            0x000000000000001c 0x000000000000001c		 R		 1
    [Requesting program interpreter: /opt/atl2.0/lib64/ld64.so.2]
LOAD		     0x0000000000000000 0x0000000010000000
0x0000000010000000
            0x0000000000008134 0x0000000000008134		 R		 E
	 10000
LOAD		     OxOOOOOOOOOOOOfcbO OxOOOOOOOOlOOlfcbO
OxOOOOOOOOlOOlfcbO
            0x00000000000004b9 0x0000000000000518		 RW
10000
DYNAMIC		     OxOOOOOOOOOOOOfccO OxOOOOOOOOlOOlfccO
OxOOOOOOOOlOOlfccO
            0x0000000000000240 0x0000000000000240		 RW		 8
NOTE		     0x0000000000000254 0x0000000010000254
0x0000000010000254
            0x0000000000000044 0x0000000000000044		 R		 4
GNU_EH_FRAME 0x0000000000007838		 0x0000000010007838
0x0000000010007838
            0x00000000000001c4 0x00000000000001c4		 R		 4
GNU_STACK		 0x0000000000000000 0x0000000000000000
0x0000000000000000
            0x0000000000000000 0x0000000000000000		 RW		 10
GNU_RELRO		 OxOOOOOOOOOOOOfcbO OxOOOOOOOOlOOlfcbO
OxOOOOOOOOlOOlfcbO
            0x0000000000000350 0x0000000000000350		 R		 1
Section to Segment mapping:
Segment Sections...
00
01		 .interp
02		 .interp .note.ABI-tag .note.gnu.build-id .hash .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .
 init .text .fini .rodata .eh_frame_hdr .eh_frame
03		 .init_array .fini_array		 .dynamic		 .got .pit .data .bss
04		 .dynamic
05		 .note.ABI-tag .note.gnu.build-id
06		 .eh_frame_hdr
07
08		 .init_array .fini_array		 .dynamic		 .got

When I compiled this, I supplied this LD arg:

LD="/opt/at12.0/bin/powerpc64le-linux-gnu-ld"

--
Ben Hood
Technical Director | RelOps Ltd
+44 782 4631586 | ben at relops.com |
http://relops.com

> On 13 Nov 2018, at 17:34, Ulrich Weigand <Ulrich.Weigand at de.ibm.com>
wrote:
>
> Aha, the loader is actually complaining about missing symbols in *the
loader itself*, not in libc.
>
> This seems strange:
> /opt/atl2.0/lib64/ld64.so.2 => /Iib64/ld64.so.2
>
> /opt/atl12.0/lib64/ld64.so.2 should be the dynamic loader provided by the
AT, it should definitely not fall back to using the system dynamic loader
(/lib64/ld64.so.2).
>
> If you run "readelf -l" on your binary, what does it say under the INTERP
segment (it should have something like "Requesting program
interpreter: ...")?
>
> If this does *not* show /opt/atl12.0/lib64/ld64.so.2, then most likely
you did not use the AT to *link* your application. Note, you specifically
need to use the AT gcc also for the *link* step, not just for the compile
steps.
>
>
> Mit freundlichen Gruessen / Best Regards
>
> Ulrich Weigand
>
> --
> Dr. Ulrich Weigand | Phone: +49-7031/16-3727
> STSM, GNU/Linux compilers and toolchain
> IBM Deutschland Research & Development GmbH
> Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
> Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
>
> <graycol.gif>Ben Hood ---13.11.2018 18:25:17---Here’s the output from
ldd: $ ldd /tmp/c4/erts-10.1.1/bin/erlc
>
> From: Ben Hood <ben at relops.com>
> To: linuxppc-users at lists.ozlabs.org
> Date: 13.11.2018 18:25
> Subject: Re: [Linuxppc-users] Toolchain version for RHEL 7.1
> Sent by: "Linuxppc-users" <linuxppc-users-bounces
+ulrich.weigand=de.ibm.com at lists.ozlabs.org>
>
>
>
>
> Here’s the output from ldd:
>
> $ ldd /tmp/c4/erts-10.1.1/bin/erlc
> /tmp/c4/erts-10.1.1/bin/erlc: /lib64/ld64.30.2: version 'GLIBC2.23' not
found (required by /opt/atl2.0/lib64/power8/libc.so.6)
> /tmp/c4/erts-10.1.1/bin/erlc: /lib64/ld64.so.2: version 'GLIBC2.22' not
found (required by /opt/atl2.0/lib64/power8/libc.so.6)
> linux-vdso64.so.1 => (0x00003fff7acb0000)
> libutil.so.l => /opt/atl2.0/lib64/power8/libutil.so.1
(0x00003fff7ac80000)
> libdl.so.2 => /opt/atl2.0/lib64/power8/libdl.so.2 (0x00003fff7ac50000)
> libm.30.6 => /opt/atl2.0/lib64/power8/libm.so.6 (0x00003fff7aaf0000)
> libc.30.6 => /opt/atl2.0/lib64/power8/libc.so.6 (0x00003fff7a8a0000)
> /opt/atl2.0/lib64/ld64.so.2 => /Iib64/ld64.so.2 (0x000000002d750000
>
> I’m wondering whether when I compiled the binary, I had somehow
compiled/linked against a glibc that is only available on the build
machine, rather than instructing the compiler to 100% link against the
libraries supplied by AT?
> On 13 Nov 2018, at 16:33, Ulrich Weigand <Ulrich.Weigand at de.ibm.com>
wrote:
> That runtime package is supposed to install the AT glibc
(under /opt/atX.X/lib64/...).
>
> The AT dynamic loader (/opt/atX.X/lib64/ld64.so.2) is supposed to
automatically use the AT libraries, including glibc,
from /opt/atX.X/lib64/...
>
> AT-built binaries should have the AT dynamic loader pre-configured so
they always use it.
>
> If this doesn't work for you, one of the above three steps must have
failed somehow. What is the output when running your binary under "ldd" ?
>
>
> Mit freundlichen Gruessen / Best Regards
>
> Ulrich Weigand
>
> --
> Dr. Ulrich Weigand | Phone: +49-7031/16-3727
> STSM, GNU/Linux compilers and toolchain
> IBM Deutschland Research & Development GmbH
> Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
> Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
>
> <graycol.gif>Ben Hood ---13.11.2018 16:28:15---Many thanks for the heads
up. I’ve installed advance-toolchain-at12.0-runtime on the target machine,
>
> From: Ben Hood <ben at relops.com>
> To: linuxppc-users at lists.ozlabs.org
> Date: 13.11.2018 16:28
> Subject: Re: [Linuxppc-users] Toolchain version for RHEL 7.1
> Sent by: "Linuxppc-users" <linuxppc-users-bounces
+ulrich.weigand=de.ibm.com at lists.ozlabs.org>
>
>
>
>
>
> Many thanks for the heads up.
>
> I’ve installed advance-toolchain-at12.0-runtime on the target machine,
but this does not appear to supply a glibc of the required version.
>
> Is this in another AT RPM package?
>
> Perusing the FAQS
>
>
https://developer.ibm.com/linuxonpower/advance-toolchain/adv-tool-usage/#faq1A

>
> Indicates that advance-toolchain-at12.0-runtime is mandatory, but I’m
wondering if a GLIBC_2.23 object is supplied by a different package. I
guess I could go through and install all of them to find out what works,
but it feels like glibc is quite a fundamental building block.
>
> Other FAQs indicate that you can use
>
> /opt/atX.X/sbin/ldconfig
>
> To cache the correct library path, but running this hasn’t resolved the
missing glibc object.
>
> Am I looking at the wrong FAQs?
>
>
> > On 13 Nov 2018, at 13:52, Ulrich Weigand <Ulrich.Weigand at de.ibm.com>
wrote:
> >
> > The AT uses a completely separate runtime library which is incompatible
with the system library.
> >
> > In order to run any binary compiled with AT, you must always install
(at least the runtime components of) the AT on the system that is to run
the binary.
> >
> >
> > Mit freundlichen Gruessen / Best Regards
> >
> > Ulrich Weigand
> >
> > --
> > Dr. Ulrich Weigand | Phone: +49-7031/16-3727
> > STSM, GNU/Linux compilers and toolchain
> > IBM Deutschland Research & Development GmbH
> > Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung:
Dirk Wittkopp
> > Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
> >
> > <graycol.gif>Ben Hood ---13.11.2018 14:50:38---Hi list, I’m having
issues loading the binary I’ve cross compiled for ppc64le/RHEL 7.1:
> >
> > From: Ben Hood <ben at relops.com>
> > To: linuxppc-users at lists.ozlabs.org
> > Date: 13.11.2018 14:50
> > Subject: [Linuxppc-users] Toolchain version for RHEL 7.1
> > Sent by: "Linuxppc-users" <linuxppc-users-bounces
+ulrich.weigand=de.ibm.com at lists.ozlabs.org>
> >
> >
> >
> >
> > Hi list,
> >
> > I’m having issues loading the binary I’ve cross compiled for
ppc64le/RHEL 7.1:
> >
> > /lib64/ld64.so.2: version ‘GLIBC_2.23’ not found (required
by /opt/at12.0/lib64/power8/libm.so.6)
> >
> > The onboard version of glibc appears to be 2.17-157.el7.
> >
> > What is the idiomatic way to supply the required glibc version?
> >
> > Is there some kind of incompatibility between the AT runtime version
(and the choice of toolchain version on the build machine)? Can I solve
this issue by using a different version of AT?
> >
> > Thanks in advance,
> >
> > Ben
> >
> >
> > _______________________________________________
> > Linuxppc-users mailing list
> > Linuxppc-users at lists.ozlabs.org
> >
https://lists.ozlabs.org/listinfo/linuxppc-users

> >
> >
> >
> >
>
> _______________________________________________
> Linuxppc-users mailing list
> Linuxppc-users at lists.ozlabs.org
>
https://lists.ozlabs.org/listinfo/linuxppc-users

>
>
>
> _______________________________________________
> Linuxppc-users mailing list
> Linuxppc-users at lists.ozlabs.org
>
https://lists.ozlabs.org/listinfo/linuxppc-users

>
>
>

_______________________________________________
Linuxppc-users mailing list
Linuxppc-users at lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-users/attachments/20181113/084f08fa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-users/attachments/20181113/084f08fa/attachment-0001.gif>