<html><body><p><font size="2">OK, that's good so far. I still don't understand why you're seeing the error then. A number of additional questions:</font><br><br><font size="2">1) I see weird names in some of logs below:</font><br><tt><font size="2">/lib64/ld64.30.2</font></tt><br><tt><font size="2">libm.30.6</font></tt><font size="2"><br></font><tt><font size="2">libc.30.6</font></tt><br><font size="2">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?</font><br><br><font size="2">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?</font><br><br><font size="2">3) Can you send me the output (stderr) of running "erlc" with LD_DEBUG=all ?</font><br><br><font size="2"><br>Mit freundlichen Gruessen / Best Regards<br><br>Ulrich Weigand<br><br>-- <br> Dr. Ulrich Weigand | Phone: +49-7031/16-3727<br> STSM, GNU/Linux compilers and toolchain<br> IBM Deutschland Research & Development GmbH<br> Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp<br> Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294</font><br><br><img width="16" height="16" src="cid:1__=4EBB09D7DFF6057B8f9e8a93df938690918c4EB@" border="0" alt="Inactive hide details for Ben Hood ---13.11.2018 18:50:13---Here is the output - it appears to have the line you expected: $ re"><font size="2" color="#424282">Ben Hood ---13.11.2018 18:50:13---Here is the output - it appears to have the line you expected: $ readelf -1 /tmp/c4/erts-10.1.1/bin/</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Ben Hood <ben@relops.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">linuxppc-users@lists.ozlabs.org</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">13.11.2018 18:50</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [Linuxppc-users] Toolchain version for RHEL 7.1</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2">"Linuxppc-users" <linuxppc-users-bounces+ulrich.weigand=de.ibm.com@lists.ozlabs.org></font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt><font size="2">Here is the output - it appears to have the line you expected:<br><br>$ readelf -1 /tmp/c4/erts-10.1.1/bin/erlc<br>Elf file type is EXEC (Executable file)<br>Entry point OxlOOOOecO<br>fhere are 9 program headers, starting at offset 64<br>Program Headers:<br>Type Offset VirtAddr PhysAddr<br> FileSiz MemSiz Flags Align<br>PHDR 0x0000000000000040 0x0000000010000040 0x0000000010000040<br> OxOOOOOOOOOOOOOlf8 OxOOOOOOOOOOOOOlf8 R 8<br>INTERP 0x0000000000000238 0x0000000010000238 0x0000000010000238<br> 0x000000000000001c 0x000000000000001c R 1<br> [Requesting program interpreter: /opt/atl2.0/lib64/ld64.so.2]<br>LOAD 0x0000000000000000 0x0000000010000000 0x0000000010000000<br> 0x0000000000008134 0x0000000000008134 R E 10000<br>LOAD OxOOOOOOOOOOOOfcbO OxOOOOOOOOlOOlfcbO OxOOOOOOOOlOOlfcbO<br> 0x00000000000004b9 0x0000000000000518 RW 10000<br>DYNAMIC OxOOOOOOOOOOOOfccO OxOOOOOOOOlOOlfccO OxOOOOOOOOlOOlfccO<br> 0x0000000000000240 0x0000000000000240 RW 8<br>NOTE 0x0000000000000254 0x0000000010000254 0x0000000010000254<br> 0x0000000000000044 0x0000000000000044 R 4<br>GNU_EH_FRAME 0x0000000000007838 0x0000000010007838 0x0000000010007838<br> 0x00000000000001c4 0x00000000000001c4 R 4<br>GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000<br> 0x0000000000000000 0x0000000000000000 RW 10<br>GNU_RELRO OxOOOOOOOOOOOOfcbO OxOOOOOOOOlOOlfcbO OxOOOOOOOOlOOlfcbO<br> 0x0000000000000350 0x0000000000000350 R 1<br>Section to Segment mapping:<br>Segment Sections...<br>00<br>01 .interp<br>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<br>03 .init_array .fini_array .dynamic .got .pit .data .bss<br>04 .dynamic<br>05 .note.ABI-tag .note.gnu.build-id<br>06 .eh_frame_hdr<br>07<br>08 .init_array .fini_array .dynamic .got<br><br><br>When I compiled this, I supplied this LD arg:<br><br>LD="/opt/at12.0/bin/powerpc64le-linux-gnu-ld"<br><br>--<br>Ben Hood<br>Technical Director | RelOps Ltd<br>+44 782 4631586 | ben@relops.com | </font></tt><tt><font size="2"><a href="http://relops.com">http://relops.com</a></font></tt><tt><font size="2"><br>> On 13 Nov 2018, at 17:34, Ulrich Weigand <Ulrich.Weigand@de.ibm.com> wrote:<br>> <br>> Aha, the loader is actually complaining about missing symbols in *the loader itself*, not in libc.<br>> <br>> This seems strange:<br>> /opt/atl2.0/lib64/ld64.so.2 => /Iib64/ld64.so.2<br>> <br>> /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).<br>> <br>> If you run "readelf -l" on your binary, what does it say under the INTERP segment (it should have something like "Requesting program interpreter: ...")?<br>> <br>> 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.<br>> <br>> <br>> Mit freundlichen Gruessen / Best Regards<br>> <br>> Ulrich Weigand<br>> <br>> -- <br>> Dr. Ulrich Weigand | Phone: +49-7031/16-3727<br>> STSM, GNU/Linux compilers and toolchain<br>> IBM Deutschland Research & Development GmbH<br>> Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp<br>> Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294<br>> <br>> <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<br>> <br>> From: Ben Hood <ben@relops.com><br>> To: linuxppc-users@lists.ozlabs.org<br>> Date: 13.11.2018 18:25<br>> Subject: Re: [Linuxppc-users] Toolchain version for RHEL 7.1<br>> Sent by: "Linuxppc-users" <linuxppc-users-bounces+ulrich.weigand=de.ibm.com@lists.ozlabs.org><br>> <br>> <br>> <br>> <br>> Here’s the output from ldd:<br>> <br>> $ ldd /tmp/c4/erts-10.1.1/bin/erlc<br>> /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)<br>> /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)<br>> linux-vdso64.so.1 => (0x00003fff7acb0000)<br>> libutil.so.l => /opt/atl2.0/lib64/power8/libutil.so.1 (0x00003fff7ac80000)<br>> libdl.so.2 => /opt/atl2.0/lib64/power8/libdl.so.2 (0x00003fff7ac50000)<br>> libm.30.6 => /opt/atl2.0/lib64/power8/libm.so.6 (0x00003fff7aaf0000)<br>> libc.30.6 => /opt/atl2.0/lib64/power8/libc.so.6 (0x00003fff7a8a0000)<br>> /opt/atl2.0/lib64/ld64.so.2 => /Iib64/ld64.so.2 (0x000000002d750000<br>> <br>> 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?<br>> On 13 Nov 2018, at 16:33, Ulrich Weigand <Ulrich.Weigand@de.ibm.com> wrote:<br>> That runtime package is supposed to install the AT glibc (under /opt/atX.X/lib64/...).<br>> <br>> 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/...<br>> <br>> AT-built binaries should have the AT dynamic loader pre-configured so they always use it.<br>> <br>> 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" ?<br>> <br>> <br>> Mit freundlichen Gruessen / Best Regards<br>> <br>> Ulrich Weigand<br>> <br>> -- <br>> Dr. Ulrich Weigand | Phone: +49-7031/16-3727<br>> STSM, GNU/Linux compilers and toolchain<br>> IBM Deutschland Research & Development GmbH<br>> Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp<br>> Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294<br>> <br>> <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,<br>> <br>> From: Ben Hood <ben@relops.com><br>> To: linuxppc-users@lists.ozlabs.org<br>> Date: 13.11.2018 16:28<br>> Subject: Re: [Linuxppc-users] Toolchain version for RHEL 7.1<br>> Sent by: "Linuxppc-users" <linuxppc-users-bounces+ulrich.weigand=de.ibm.com@lists.ozlabs.org><br>> <br>> <br>> <br>> <br>> <br>> Many thanks for the heads up.<br>> <br>> 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.<br>> <br>> Is this in another AT RPM package?<br>> <br>> Perusing the FAQS<br>> <br>> </font></tt><tt><font size="2"><a href="https://developer.ibm.com/linuxonpower/advance-toolchain/adv-tool-usage/#faq1A">https://developer.ibm.com/linuxonpower/advance-toolchain/adv-tool-usage/#faq1A</a></font></tt><tt><font size="2"><br>> <br>> 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.<br>> <br>> Other FAQs indicate that you can use<br>> <br>> /opt/atX.X/sbin/ldconfig<br>> <br>> To cache the correct library path, but running this hasn’t resolved the missing glibc object.<br>> <br>> Am I looking at the wrong FAQs?<br>> <br>> <br>> > On 13 Nov 2018, at 13:52, Ulrich Weigand <Ulrich.Weigand@de.ibm.com> wrote:<br>> > <br>> > The AT uses a completely separate runtime library which is incompatible with the system library.<br>> > <br>> > 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.<br>> > <br>> > <br>> > Mit freundlichen Gruessen / Best Regards<br>> > <br>> > Ulrich Weigand<br>> > <br>> > -- <br>> > Dr. Ulrich Weigand | Phone: +49-7031/16-3727<br>> > STSM, GNU/Linux compilers and toolchain<br>> > IBM Deutschland Research & Development GmbH<br>> > Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp<br>> > Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294<br>> > <br>> > <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:<br>> > <br>> > From: Ben Hood <ben@relops.com><br>> > To: linuxppc-users@lists.ozlabs.org<br>> > Date: 13.11.2018 14:50<br>> > Subject: [Linuxppc-users] Toolchain version for RHEL 7.1<br>> > Sent by: "Linuxppc-users" <linuxppc-users-bounces+ulrich.weigand=de.ibm.com@lists.ozlabs.org><br>> > <br>> > <br>> > <br>> > <br>> > Hi list,<br>> > <br>> > I’m having issues loading the binary I’ve cross compiled for ppc64le/RHEL 7.1:<br>> > <br>> > /lib64/ld64.so.2: version ‘GLIBC_2.23’ not found (required by /opt/at12.0/lib64/power8/libm.so.6)<br>> > <br>> > The onboard version of glibc appears to be 2.17-157.el7.<br>> > <br>> > What is the idiomatic way to supply the required glibc version?<br>> > <br>> > 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?<br>> > <br>> > Thanks in advance,<br>> > <br>> > Ben<br>> > <br>> > <br>> > _______________________________________________<br>> > Linuxppc-users mailing list<br>> > Linuxppc-users@lists.ozlabs.org<br>> > </font></tt><tt><font size="2"><a href="https://lists.ozlabs.org/listinfo/linuxppc-users">https://lists.ozlabs.org/listinfo/linuxppc-users</a></font></tt><tt><font size="2"><br>> > <br>> > <br>> > <br>> > <br>> <br>> _______________________________________________<br>> Linuxppc-users mailing list<br>> Linuxppc-users@lists.ozlabs.org<br>> </font></tt><tt><font size="2"><a href="https://lists.ozlabs.org/listinfo/linuxppc-users">https://lists.ozlabs.org/listinfo/linuxppc-users</a></font></tt><tt><font size="2"><br>> <br>> <br>> <br>> _______________________________________________<br>> Linuxppc-users mailing list<br>> Linuxppc-users@lists.ozlabs.org<br>> </font></tt><tt><font size="2"><a href="https://lists.ozlabs.org/listinfo/linuxppc-users">https://lists.ozlabs.org/listinfo/linuxppc-users</a></font></tt><tt><font size="2"><br>> <br>> <br>> <br><br>_______________________________________________<br>Linuxppc-users mailing list<br>Linuxppc-users@lists.ozlabs.org<br></font></tt><tt><font size="2"><a href="https://lists.ozlabs.org/listinfo/linuxppc-users">https://lists.ozlabs.org/listinfo/linuxppc-users</a></font></tt><tt><font size="2"><br><br></font></tt><br><br><BR>
</body></html>