[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

---------- Forwarded message ---------
From: Matthew Wheaton <mwheat5487 gmail com>
Date: Mon, May 24, 2021 at 10:04 PM
Subject: devtoolset-6 and libstdc++ revisited
To: <sclorg 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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]