2

My software compiles on a variety of OSes, including RHEL7. I have a request to build it to run on RHEL6. My problem is that my C++ code relies a lot on C++11 features that are not present in gcc-4.4, the one coming with RHEL6. nullptr, auto, lambdas are not supported, and there are a lot in the code.

I've seen there are ways to have more recent gcc versions to run on RHEL6, such as the Developer ToolSet for instance. I've no doubt I'll be able to build my software for RHEL6.

However, once compiled with, say, gcc-6, what will I have to provide with the binaries of my software? The C library of gcc-6? The C++ library of gcc-6? Should I instead link them statically to my binary?

On top of that, my software is packaged into .rpm files, and installs at standard locations: /usr/bin, /usr/lib ... Where would I install these new C and C++ library files on the target system? (Obviously not in /usr/lib where they may interfere with the default ones!)

Edit: My software is a shared object, I guess I can statically link the C++ library? But what about the program (I've no control on it) that will use my shared object. Can it use another version of the C++ library? Won't the linker find lots of duplicates? Looks like I'd open a can of worms...

Edit: Would it be possible to use the more recent gcc compiler with the standard C++ library of the RHEL6 stock one?

Edit: Note that the shared object has a pure "C" interface (Standardized).

2
  • What exact dependencies do you have? You should edit your question to list them entirely. Commented Aug 17, 2017 at 12:00
  • @BasileStarynkevitch Added info about what is used from C++11. Also, my shared object has a standardized "C" interface. It uses C++ internally only. Commented Aug 17, 2017 at 15:07

1 Answer 1

2

Where would I install these new C and C++ library files on the target system? (Obviously not in /usr/lib where they may interfere with the default ones!)

On the contrary, you would install these new libraries in /usr/lib/ (or whatever is the default on the target system; on my Debian they would go into /usr/lib/x86_64-linux-gnu/ and /lib/x86_64-linux-gnu/). You need to care about rpath-s.

My software is a shared object, I guess I can statically link the C++ library?

That probably won't work for a shared object (but could work for an executable; you would then link statically the libstdc++ and dynamically the libc.so). However, a shared object can be linked with other shared libraries. Notice that if you are providing a C++11 library, your users need a C++11 compiler (unless you design very carefully your library to only have a C-compatible API).

You probably would ship some header files and should take advantage of pkg-config so ship the appropriate .pc file.

Consider reading Program Library HowTo, C++ dlopen mini HowTo & Drepper's How To Write a Shared Library paper.

Would it be possible to use the more recent gcc compiler with the standard C++ library of the RHEL6 stock one?

No; the standard C++ library is intimately tied to the C++ compiler (and could have a different ABI).

BTW, I strongly recommend shipping the source code of your library and perhaps making it some free software. You could then ask assistance to package your library properly from the community working on that ancient Redhat distribution.

Notice that your library might have many other dependencies. For example, if it is a GUI library it probably uses other resources (like fonts or images).

1
  • Now I can compile on a 64 bits system with Developer Toolset and gcc-6 a binary that can be executed on a 32 bits RHEL. I understand that I cannot create a Shared Object that could be used later on from another program. But can I create a static library with functions for 32 bits system that could be linked to another program using Developer Toolset on a 64 bits system, but targeting a 32 bits system? Commented Aug 31, 2017 at 10:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .