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

[Alexander Neundorf]

On 2017 M02 3, Fri 20:32:58 CET you wrote:
> FWIW, we've moved to CentOS 6 for the binaries we package and distribute
> for ParaView.  It's about the oldest widely deployed Linux distro that's
> still actively supported (EL5 is EOL'd and most deployments have long since
> moved to 6 or 7).  

Yes, most, but not all ;-)

Alex

-- 

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

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

[Chuck Atkins]

FWIW, we've moved to CentOS 6 for the binaries we package and distribute
for ParaView.  It's about the oldest widely deployed Linux distro that's
still actively supported (EL5 is EOL'd and most deployments have long since
moved to 6 or 7).  it's binaries are compatible with virtually all current
Linux distros.  It also has newer compilers available (gcc 5.3 through the
devtoolset-4 package) that can build C++11 binaries compatible with the
older systems.

- Chuck

On Fri, Feb 3, 2017 at 3:46 PM, Alexander Neundorf 
wrote:

> On 2017 M02 2, Thu 20:07:29 CET you wrote:
> > Hi Gonzalo,
> >
> > Using the dockcross/manylinux-x64 docker image should allow to build you
> > project out-of-the-box.
> > It is based on Centos5, include recent gcc, CMake, Git, etc ...
> >
> > See https://github.com/dockcross/dockcross
> >
> > In a nutshell,
> >
> > # Pull image
> > docker pull dockcross/manylinux-x64
> >
> > # Generate helper script
> > docker run --rm dockcross/manylinux-x64 > dockcross-manylinux-x64
> > chmod +x ./dockcross-manylinux-x64
> > mv ./dockcross-manylinux-x64 ~/bin/
> >
> > # Build your project
> > cd /path/to/src
> > dockcross cmake -Bbuild -H. -GNinja
> >
> >
> > The directory build will then contain the build tree of your project
> > compiled using gcc provided by the Centos5 image and link against an old
> > glibc.
>
> when docker starts, you are usually root in the container, and if then
> something is built, the files belong to root, and not the user as which
> you are
> logged in.
> How do you handle that ?
> I just found a hackish way (a shell script which sets up a user with the
> same
> numerical ID) to have the same user ID in the container as on the host
> system.
> Is there a better way ?
>
> Alex
>
> --
>
> 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
>
-- 

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

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

[Alexander Neundorf]

On 2017 M02 2, Thu 20:07:29 CET you wrote:
> Hi Gonzalo,
> 
> Using the dockcross/manylinux-x64 docker image should allow to build you
> project out-of-the-box.
> It is based on Centos5, include recent gcc, CMake, Git, etc ...
> 
> See https://github.com/dockcross/dockcross
> 
> In a nutshell,
> 
> # Pull image
> docker pull dockcross/manylinux-x64
> 
> # Generate helper script
> docker run --rm dockcross/manylinux-x64 > dockcross-manylinux-x64
> chmod +x ./dockcross-manylinux-x64
> mv ./dockcross-manylinux-x64 ~/bin/
> 
> # Build your project
> cd /path/to/src
> dockcross cmake -Bbuild -H. -GNinja
> 
> 
> The directory build will then contain the build tree of your project
> compiled using gcc provided by the Centos5 image and link against an old
> glibc.

when docker starts, you are usually root in the container, and if then 
something is built, the files belong to root, and not the user as which you are 
logged in.
How do you handle that ?
I just found a hackish way (a shell script which sets up a user with the same 
numerical ID) to have the same user ID in the container as on the host system. 
Is there a better way ?

Alex

-- 

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

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

[Jean-Christophe Fillion-Robin]

Hi Gonzalo,

Using the dockcross/manylinux-x64 docker image should allow to build you
project out-of-the-box.
It is based on Centos5, include recent gcc, CMake, Git, etc ...

See https://github.com/dockcross/dockcross

In a nutshell,

# Pull image
docker pull dockcross/manylinux-x64

# Generate helper script
docker run --rm dockcross/manylinux-x64 > dockcross-manylinux-x64
chmod +x ./dockcross-manylinux-x64
mv ./dockcross-manylinux-x64 ~/bin/

# Build your project
cd /path/to/src
dockcross cmake -Bbuild -H. -GNinja


The directory build will then contain the build tree of your project
compiled using gcc provided by the Centos5 image and link against an old
glibc.

To learn more about the glibc version used in the image, see
https://www.python.org/dev/peps/pep-0513/

Hth
Jc






On Sun, Jan 29, 2017 at 4:36 PM, Alexander Neundorf  wrote:

> On 2017 M01 26, Thu 18:23:05 CET Gonzalo Garramuño wrote:
> > I currently own an Ubuntu Xenial 14.04.1 LTS box in which I do all my
> > work.I distribute a binary image viewer.   However, recently one of
> > my users tried to run the viewer on a CentOS 7 distro and found out that
> > that distro libc and libstdc++ are older and incompatible.
> >
> > I would like to compile my program targeting the older libc and
> > libstdc++.  Those files come with symbol version and visibility. Is
> > there an easy way to do that other than copying the old libraries?
>
> you may consider using docker to provide a build environment for an "old"
> distribution (CentOS 7 is actually quite bleeding edge... ;-) )
> There are some CentOS5 images on dockerhub.
>
> Alex
>
> --
>
> 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
>



-- 
+1 919 869 8849
-- 

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

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

[Alexander Neundorf]

On 2017 M01 26, Thu 18:23:05 CET Gonzalo Garramuño wrote:
> I currently own an Ubuntu Xenial 14.04.1 LTS box in which I do all my
> work.I distribute a binary image viewer.   However, recently one of
> my users tried to run the viewer on a CentOS 7 distro and found out that
> that distro libc and libstdc++ are older and incompatible.
> 
> I would like to compile my program targeting the older libc and
> libstdc++.  Those files come with symbol version and visibility. Is
> there an easy way to do that other than copying the old libraries?

you may consider using docker to provide a build environment for an "old" 
distribution (CentOS 7 is actually quite bleeding edge... ;-) )
There are some CentOS5 images on dockerhub.

Alex

-- 

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

Re: [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.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 
>>> 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

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

[Florent Castelli]

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  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

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

[Michael Ellery]

> On Jan 26, 2017, at 1:45 PM, Gonzalo Garramuño  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

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

[Gonzalo Garramuño]

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

--

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

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

[Michael Ellery]

> On Jan 26, 2017, at 1:23 PM, Gonzalo Garramuño  wrote:
> 
> I currently own an Ubuntu Xenial 14.04.1 LTS box in which I do all my work.   
>  I distribute a binary image viewer.   However, recently one of my users 
> tried to run the viewer on a CentOS 7 distro and found out that that distro 
> libc and libstdc++ are older and incompatible.
> 
> I would like to compile my program targeting the older libc and libstdc++.  
> Those files come with symbol version and visibility. Is there an easy way to 
> do that other than copying the old libraries?
> 
> Any help or hint is appreciated.
> 

In what way is the stdlib incompatible? Does it have bugs, or is this more a 
matter of cpp standard support? If you want to enforce/require a certain 
standard of cpp, for instance, have a look at:

https://cmake.org/cmake/help/v3.1/variable/CMAKE_CXX_STANDARD_REQUIRED.html

If you want to enforce certain language features, you can consider specifying 
compile-features:

https://cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html
https://cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html#prop_gbl:CMAKE_CXX_KNOWN_FEATURES

Now, that might still not solve the immediate problem of an old toolchain on 
Centos7, but at least CMake will make clear to the user what’s missing.  For 
Centos/Redhat specifically, I’ve had good luck with devtoolset for 
installing/using an updated toolchain:

https://www.softwarecollections.org/en/scls/rhscl/devtoolset-3

HTH,
Mike Ellery



-- 

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

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

[Gonzalo Garramuño]

I currently own an Ubuntu Xenial 14.04.1 LTS box in which I do all my 
work.I distribute a binary image viewer.   However, recently one of 
my users tried to run the viewer on a CentOS 7 distro and found out that 
that distro libc and libstdc++ are older and incompatible.


I would like to compile my program targeting the older libc and 
libstdc++.  Those files come with symbol version and visibility. Is 
there an easy way to do that other than copying the old libraries?


Any help or hint is appreciated.

--
Gonzalo Garramuño

--

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