[CMake] Forcing linking compatability to old libc / libstdc++ (Linux)

[Bo Zhou]

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.castelli at 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 <ggarra13 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170127/e242eaa8/attachment-0001.html>