Quantcast

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

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Gonzalo Garramuno
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Michael Ellery

> On Jan 26, 2017, at 1:23 PM, Gonzalo Garramuño <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Gonzalo Garramuno


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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Michael Ellery

> On Jan 26, 2017, at 1:45 PM, Gonzalo Garramuño <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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 <[hidden email]> 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 <[hidden email]> 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


--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Alexander Neundorf-3
In reply to this post by Gonzalo Garramuno
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Alexander Neundorf-3
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Alexander Neundorf-3
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
Loading...