jaroslaw.bober at gmail.com
Fri May 20 14:17:58 UTC 2016
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:
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)
Which is stock libstdc++
Devtoolset version is located at:
Additionally there is libstdc++_nonshared.a:
In the guide there is a matrix of compatibility:
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.
2016-05-19 23:02 GMT+02:00 Warren Young <wyml at etr-usa.com>:
> On May 19, 2016, at 3:30 AM, Jarosław Bober <jaroslaw.bober at gmail.com>
> > Do I have to install devtoolset on all my machines that I want to run
> > app?
> Probably, yes. That, or redistribute parts of it with your app, either by
> cherrypicking files from the devtoolset RPM or statically linking to it.
> > Or would it use built-in libstdc++ library, linking statically only
> > the missing parts?
> 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.
> CentOS mailing list
> CentOS at centos.org
More information about the CentOS