[scl.org] Fwd: devtoolset-6 and libstdc++ revisited

Matthew Wheaton mwheat5487 at gmail.com
Tue May 25 02:22:51 UTC 2021


---------- Forwarded message ---------
From: Matthew Wheaton <mwheat5487 at gmail.com>
Date: Mon, May 24, 2021 at 10:04 PM
Subject: devtoolset-6 and libstdc++ revisited
To: <sclorg at redhat.net>


New to this list thing, giving a simple email a try.

Stephan was nice enough to answer my question prior to my joining the list
and he was a big help.  My original question was why the version of
libstdc++ that goes with gcc-6.3 is not included in devtoolset-6.  Answer:
you don't need it.

I have to admit, I can use the devtoolset-6 version of g++ and compile with
the system libraries just fine.  That's a revelation in itself.  All
compiles and all tests pass.  This is great, I can use libstdc++.so.6.13
(rhel-6 native) and not worry about the missing symbol required by the
gcc-6.3 libstdc++.so.22 (packaged with gcc-6.3).  Note: this is just by
setting the compile to point to the devtoolset-6 version of g++, I'm not
even doing an 'scl enable'.  COMPILER=<devtoolset-6_path>

But if I can get success by simply using a different compiler, why
shouldn't I be able to do the same thing with the gcc-6.3 compiler I
already have?  How can I use the 6.3 compiler and point to the standard
system libs in /usr/lib64?   What do I have to do to separate this duo?
Attempts at setting LIBRARY_PATH or LD_LIBRARY_PATH don't seem to work.

To make matters more interesting, the build environment has the makefiles
locked down pretty well.  They are not intended to be edited in any way.
There are a limited number of environment variables that the make sources,
and that's about it.  The build log shows that the '-L' flag is not used to
determine the location of libstdc++ and the GNU documentation does not
reveal how it picks up default libs.  Can anyone point me in the right
direction?

Thanks,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/sclorg/attachments/20210524/5ac6ca4b/attachment.htm>


More information about the SCLorg mailing list