Devtoolset-4

Home » CentOS » Devtoolset-4
CentOS 7 Comments

Hi,

is there any way to get access to devtoolset-4 ?

I see alot of stuff at http://cbs.CentOS.org/koji/packageinfo?packageID 76 . Is this not yet released?

thanks,

Kay

7 thoughts on - Devtoolset-4

  • Hello, my name is Jarek I am new here. I need some clarifications on how to distribute an app developed with devtoolset-4 enabled.

    I am developing a distributed app in c++ I wanted to upgrade toolchain to use new standard. Is it true that when I compile on CentOS 6.x with devtoolset enabled then I
    will be able to run this app on CentOS 7.x as well?

    Do I have to install devtoolset on all my machines that I want to run this app? Or would it use built-in libstdc++ library, linking statically only the missing parts?

    This confuses me a bit.

    Regards,
    -Jarek

  • Hello, my name is Jarek I am new here. I need some clarifications on how to distribute an app developed with devtoolset-4 enabled.

    I am developing a distributed app in c++ I wanted to upgrade toolchain to use new standard. Is it true that when I compile on CentOS 6.x with devtoolset enabled then I
    will be able to run this app on CentOS 7.x as well?

    Do I have to install devtoolset on all my machines that I want to run this app? Or would it use built-in libstdc++ library, linking statically only the missing parts?

    This confuses me a bit.

    Regards,
    -Jarek

  • Probably, yes. That, or redistribute parts of it with your app, either by cherrypicking files from the devtoolset RPM or statically linking to it.

    Are you asking if the new libstdc++ is statically linked into your app only for the new functions but your app remains dynamically linked to the old one for the parts of C++ that have remained unchanged, the answer is “no”. Your app is linked to the new library, period. You can use ldd(1) to prove this to yourself.

    Yes, this is a pain, which is why most people writing software for older CentOS releases don’t upgrade their development tools. There’s a lot to be said for holding off on using new language features until they’re available in the stock version of the tools for all OSes you need to deploy on.

    I’d like to be using C++11 myself, but a feature-complete version of C++11 didn’t appear in g++ until 4.8, which first shipped in CentOS 7. I just got done backporting a feature to a 32-bit CentOS 5 box, so I’m probably not going to be able to use C++11 for another 3-5 years. Sad, but I still get the work done with C++98.

  • Are you asking if the new libstdc++ is statically linked into your app only for the new functions but your app remains dynamically linked to the old one for the parts of C++ that have remained unchanged, the answer is “no”. Your app is linked to the new library, period. You can use ldd(1) to prove this to yourself. I am not so sure. That is what I thought, but then I compiled something with a compiler from devtoolset (5.2.1) with –std=c++11 flag.

    ldd gives me:
    ldd a.out linux-vdso.so.1 => (0x00007fff6e5ff000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000039d8400000)
    libm.so.6 => /lib64/libm.so.6 (0x00000039ce800000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000039d8000000)
    libc.so.6 => /lib64/libc.so.6 (0x00000039ce000000)
    /lib64/ld-linux-x86-64.so.2 (0x00000039cdc00000)

    Which is stock libstdc++
    Devtoolset version is located at:
    /opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.2.1/libstdc++.so Additionally there is libstdc++_nonshared.a:
    /opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.2.1/libstdc++_nonshared.a

    In the guide there is a matrix of compatibility:
    https://access.redhat.com/documentation/en-US/Red_Hat_Developer_Toolset/4/html/User_Guide/sect-Red_Hat_Developer_Toolset-Compatibility.html it says that If I compile with DTS on 6.6 thet it will run on 6.6 and above, but it doesn’t say if DTS has to be installed on that machine. So this got me to thinking. I definitelly will check that :) and I really believe that it can be this way. Althought it sounds like black magic.

    Regards,
    -Jarek

    2016-05-19 23:02 GMT+02:00 Warren Young :

    CentOS mailing list CentOS@CentOS.org https://lists.CentOS.org/mailman/listinfo/CentOS

  • In that case, I don’t see how you can be making use of any C++11/14 features that aren’t implemented by the compiler itself (e.g. type inference via “auto”) or purely in template form. Any feature that uses the compiled Standard C++ Library can’t be using the new library.

    That may be useful for your purposes.

  • Hello, I just found the discussion on the devtoolset on SO:
    https://stackoverflow.com/questions/15599714/risks-of-different-gcc-versions-at-link-run-time

    confirming my guesses. You can use any new C++11/C++14 feature and your program will link dynamically to stock libstdc++. Any feature that is not present there will be linked statically with nonshared_libstdc++.a. The only cost would be additional binary size. I checked using few features and binary growth was ignorable. But definitelly one have to take it into account. The only problem I have for now is to bring all of machines I maintain to a stable
    6.6 version. Which is >1000 machines :) The cos is well worth it :)

    Regards,
    -Jarek

    2016-05-20 21:16 GMT+02:00 Warren Young :

    CentOS mailing list CentOS@CentOS.org https://lists.CentOS.org/mailman/listinfo/CentOS