<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 8, 2017 at 8:21 PM, cls <span dir="ltr"><<a href="mailto:cls@seawood.org" target="_blank">cls@seawood.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
It appears as though the devtoolset toolchain rpms do not come with a copy of the libstdc++ shared library nor a handful of other shared libraries usually provided by gcc. Comparing the SCL and non-SCL gcc.spec files, it's clear that someone deliberately removed those shared libs. Why is that? I didn't see any mention of this in the mailing list archives.<br>
<br>
I'm seeing a weird segfault during the destruction of a std::string derived-object that I do not see with the system compiler (gcc 4.8.5). I thought that it may have been a compiler error but then while debugging, I noticed that the c++ programs & libraries are linked against the system version of libstdc++.so.6 instead of the devtoolset-6 version. That seems like that could cause major problems.<br>
<br>
I'm using the pre-built devtoolset-6 from <a href="http://vault.centos.org/7.2.1511/sclo/x86_64/rh/devtoolset-6/" rel="noreferrer" target="_blank">http://vault.centos.org/7.2.15<wbr>11/sclo/x86_64/rh/devtoolset-<wbr>6/</a> on CentOS 7.2.1511. I modified the boost package to build as part of the collection since it is highly dependent upon the toolchain. You can see the runtime dependency upon the system library below as well as the ld script that causes the system library to get referenced at link time.<br>
<br>
[build@cls-scelbuild-72 tmp]$ scl enable devtoolset-6 'ldd /opt/rh/devtoolset-6/root/usr/<wbr>lib64/libboost_filesystem.so.1<wbr>.53.0'<br>
        linux-vdso.so.1 =>  (0x00007ffecfbbe000)<br>
        libboost_system.so.1.53.0 => /opt/rh/devtoolset-6/root/usr/<wbr>lib64/libboost_system.so.1.53.<wbr>0 (0x00007f52ac67d000)<br>
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f52ac365000)<br>
        libm.so.6 => /lib64/libm.so.6 (0x00007f52ac063000)<br>
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f52abe4d000)<br>
        libc.so.6 => /lib64/libc.so.6 (0x00007f52aba8a000)<br>
        /lib64/ld-linux-x86-64.so.2 (0x00007f52acab6000)<br>
[build@cls-scelbuild-72 tmp]$ find /opt/rh/devtoolset-6/root/ -name 'libstdc++*.so*' | grep -v gdb<br>
find: ‘/opt/rh/devtoolset-6/root/roo<wbr>t’: Permission denied<br>
/opt/rh/devtoolset-6/root/usr/<wbr>lib/gcc/x86_64-redhat-linux/6.<wbr>2.1/libstdc++.so<br>
/opt/rh/devtoolset-6/root/usr/<wbr>lib/gcc/x86_64-redhat-linux/6.<wbr>2.1/32/libstdc++.so<br>
[build@cls-scelbuild-72 tmp]$ cat /opt/rh/devtoolset-6/root/usr/<wbr>lib/gcc/x86_64-redhat-linux/6.<wbr>2.1/libstdc++.so<br>
/* GNU ld script<br>
   Use the shared library, but some functions are only in<br>
   the static library, so try that secondarily.  */<br>
OUTPUT_FORMAT(elf64-x86-64)<br>
INPUT ( /usr/lib64/libstdc++.so.6 -lstdc++_nonshared )<br>
[build@cls-scelbuild-72 tmp]$<br></blockquote><div><br></div><div>One of the main selling points of the devtoolset is that it uses the libraries from the system and statically links in features that aren't available. That allows the binaries built with it to be used on other machines without needing to install devtoolset or any other additional dependencies. </div></div></div></div>