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/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
