My personal experience is, always create the distribution on old Linux with older compiler to keep the maximal compatibility.
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. 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. On Fri, Jan 27, 2017 at 9:34 AM, Florent Castelli < florent.caste...@gmail.com> wrote: > I've had to deal with this in the past. > > 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. > 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. > There is a script describe in this blog post ( > https://blogs.gnome.org/tvb/2013/12/14/application-bundles-revisited/ ) > you could use to generate a compatibility header for any target version of > glibc. > Then, you can use a force include (-include) in your favorite build system > (CMake) to have those used everywhere automatically. > 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. > > For libstdc++, you could potentially statically link it, it's usually fine. > 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... > > /Florent > > > On 26/01/2017 23:34, Michael Ellery wrote: > >> On Jan 26, 2017, at 1:45 PM, Gonzalo Garramuño <ggarr...@gmail.com> >>> wrote: >>> >>> >>> >>> El 26/01/2017 a las 18:35, Michael Ellery escribió: >>> >>>> In what way is the stdlib incompatible? Does it have bugs, or is this >>>> more a matter of cpp standard support? >>>> >>> I should have been more clear. Sorry. The incompatabilities happen at >>> linker time, with complaints such as: >>> >>> exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found >>> (required by exrstdattr ) >>> exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found >>> (required by /usr/local/mrViewer/lib/libIlmImf-2_2.so.22 ) >>> >>> If I copy the latest libstdc++.so.6 I have on Ubuntu, I get: >>> >>> exrstdattr: /lib64/libc.so.6: version `GLIBC_2.18' not found (required >>> by /usr/local/mrViewer/lib/libstdc++.so.6 ) >>> >>> -- >>> Gonzalo Garramuño >>> >>> 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. >> >> 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: >> >> http://stackoverflow.com/questions/13636513/linking-libstdc- >> statically-any-gotchas#14082540 >> >> I personally would not want to ship a stdlib myself, but using CMake’s >> RPATH support, you can probably make it work. >> >> -Mike >> >> > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake >
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
