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