<div dir="ltr"><div>My personal experience is, always create the distribution on old Linux with older compiler to keep the maximal compatibility.<br><br>Since usually the GCC will pick libstdc++ from system, so if user runs the distribution on even older Linux, 100% sure the error raises. On CentOS/Redhat we do have the devtool-set, but still, the older Linux + GCC are the safest solution.<br><br>Or you can use the static link of libstdc++, but the size of binary will be larger, and sometimes the problem still exists, and causes more problems.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 27, 2017 at 9:34 AM, Florent Castelli <span dir="ltr"><<a href="mailto:florent.castelli@gmail.com" target="_blank">florent.castelli@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've had to deal with this in the past.<br>
<br>
For glibc, it's more tricky since when you compile on a newer distribution, it will automatically use the newer version of some symbols. Some functions have had breaking changes and to keep compatibility, they kept all the different version in the binary.<br>
But you can force the compiler to use a specific version of head but putting that information in a header that contains the definition for all those functions.<br>
There is a script describe in this blog post ( <a href="https://blogs.gnome.org/tvb/2013/12/14/application-bundles-revisited/" rel="noreferrer" target="_blank">https://blogs.gnome.org/tvb/20<wbr>13/12/14/application-bundles-<wbr>revisited/</a> ) you could use to generate a compatibility header for any target version of glibc.<br>
Then, you can use a force include (-include) in your favorite build system (CMake) to have those used everywhere automatically.<br>
If your application doesn't use any external libraries linked statically and built against your current glibc, it should work. Otherwise, you will probably have to rebuild them.<br>
<br>
For libstdc++, you could potentially statically link it, it's usually fine.<br>
But after what I said about glibc, it means you may have to rebuild it using the compatibility header described before. That may be tricky too...<span class="HOEnZb"><font color="#888888"><br>
<br>
/Florent</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 26/01/2017 23:34, Michael Ellery wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Jan 26, 2017, at 1:45 PM, Gonzalo Garramuño <<a href="mailto:ggarra13@gmail.com" target="_blank">ggarra13@gmail.com</a>> wrote:<br>
<br>
<br>
<br>
El 26/01/2017 a las 18:35, Michael Ellery escribió:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In what way is the stdlib incompatible? Does it have bugs, or is this more a matter of cpp standard support?<br>
</blockquote>
I should have been more clear. Sorry. The incompatabilities happen at linker time, with complaints such as:<br>
<br>
exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by exrstdattr )<br>
exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /usr/local/mrViewer/lib/libIlm<wbr>Imf-2_2.so.22 )<br>
<br>
If I copy the latest libstdc++.so.6 I have on Ubuntu, I get:<br>
<br>
exrstdattr: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /usr/local/mrViewer/lib/libstd<wbr>c++.so.6 )<br>
<br>
-- <br>
Gonzalo Garramuño<br>
<br>
</blockquote>
oh, yeah - I wasn’t paying close attention to the fact that you are distributing *binaries* — to a different distro no less. This is why projects often either tell users to build from source or they create packages (rpms, dpkgs, etc.) on the specific distros and versions.<br>
<br>
That said, if you want to distribute binaries to a different distro, I guess you can try static linking OR what you suggested, shipping the stdlib — see:<br>
<br>
<a href="http://stackoverflow.com/questions/13636513/linking-libstdc-statically-any-gotchas#14082540" rel="noreferrer" target="_blank">http://stackoverflow.com/quest<wbr>ions/13636513/linking-libstdc-<wbr>statically-any-gotchas#<wbr>14082540</a><br>
<br>
I personally would not want to ship a stdlib myself, but using CMake’s RPATH support, you can probably make it work.<br>
<br>
-Mike<br>
<br>
</blockquote>
<br>
-- <br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMak<wbr>e_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/su<wbr>pport.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/co<wbr>nsulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/tr<wbr>aining.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensou<wbr>rce/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/cmake" rel="noreferrer" target="_blank">http://public.kitware.com/mail<wbr>man/listinfo/cmake</a></div></div></blockquote></div><br></div>