4 Replies Latest reply: Apr 2, 2014 7:05 AM by jthackray RSS

    12.4 beta dynamic library linkage - running 12.4-generated binaries on vanilla Solaris

    jthackray

      Good morning,

       

      A quick questions about the 12.4 beta C++ compiler as regards linkage. If I compile our (fairly complex) code with 12.3, and run "ldd", this is the output:

       

              libdemangle.so.1 =>      /usr/lib/64/libdemangle.so.1

              librt.so.1 =>            /lib/64/librt.so.1

              libsocket.so.1 =>        /lib/64/libsocket.so.1

              libnsl.so.1 =>           /lib/64/libnsl.so.1

              libdl.so.1 =>            /lib/64/libdl.so.1

              libkstat.so.1 =>         /lib/64/libkstat.so.1

              libm.so.2 =>             /lib/64/libm.so.2

              libCstd.so.1 =>          /usr/lib/64/libCstd.so.1

              libCrun.so.1 =>          /usr/lib/64/libCrun.so.1

              libc.so.1 =>             /lib/64/libc.so.1

              libaio.so.1 =>           /lib/64/libaio.so.1

              libmd5.so.1 =>           /lib/64/libmd5.so.1

              libmp.so.2 =>            /lib/64/libmp.so.2

              libscf.so.1 =>           /lib/64/libscf.so.1

              libdoor.so.1 =>          /lib/64/libdoor.so.1

              libuutil.so.1 =>         /lib/64/libuutil.so.1

       

      However, if I copy a binary generated with the same compiler/linker flags, but an additional "-std=c++11" flag to a vanilla Solaris server without the new compiler, it won't execute, as ldd reveals:

       

              libdemangle.so.1 =>      /usr/lib/64/libdemangle.so.1

              librt.so.1 =>            /lib/64/librt.so.1

              libsocket.so.1 =>        /lib/64/libsocket.so.1

              libnsl.so.1 =>           /lib/64/libnsl.so.1

              libdl.so.1 =>            /lib/64/libdl.so.1

              libkstat.so.1 =>         /lib/64/libkstat.so.1

              libm.so.2 =>             /lib/64/libm.so.2

              libstdc++.so.6 =>        (file not found)

              libgcc_s.so.1 =>         (file not found)

              libCrunG3.so.1 =>        (file not found)

              libc.so.1 =>             /lib/64/libc.so.1

              libaio.so.1 =>           /lib/64/libaio.so.1

              libmd5.so.1 =>           /lib/64/libmd5.so.1

              libmp.so.2 =>            /lib/64/libmp.so.2

              libscf.so.1 =>           /lib/64/libscf.so.1

              libdoor.so.1 =>          /lib/64/libdoor.so.1

              libuutil.so.1 =>         /lib/64/libuutil.so.1

       

      Presumably libstdc++.so.6 is a new C++11 run-time library, and we'll have to statically link this into the executable? I'm not sure why the executable is linked against libgcc_s.so.1, as although the code will compile with gcc, we're only using the Oracle compiler under Solaris. And what's libCrunG3.so.1? Can both of these extra libraries be statically linked too?

       

      We were hoping to migrate to C++11 (many developers have been "chomping at the bit" to use new features), and we've been ready on Linux for quite a while, it was just Solaris we were waiting for. But if we can't easily statically link these libraries in, that will prove a problem with migrating to the new standard.

       

      Would be grateful for an explanation of these new dynamic libraries, and how to link them statically.

       

      Many thanks,

      Jonathan.

        • 1. Re: 12.4 beta dynamic library linkage - running 12.4-generated binaries on vanilla Solaris
          Fedor-Oracle

          > If I copy a binary generated with the same compiler/linker flags, but an additional "-std=c++11" flag to a vanilla Solaris server without the new compiler, it won't execute,

           

          Yes, this is expected.

          12.4 Beta brings a set of new runtime libraries to support C++11, and these libraries are not available on Solaris.

          If you want to play with your C++11 binaries you need to bring Beta with you ...

           

          > libstdc++.so.6 is a new C++11 run-time library

           

          This is a G++ STL library, version 4.7. We rely on it to provide C++11 library support.

           

          > why the executable is linked against libgcc_s.so.1

           

          Our C++11 ABI is compatible with G++ ABI, and libgcc_s is a G++ runtime library that supports that ABI

          (stack unwinding in particular).

           

          > what's libCrunG3.so.1?

           

          This is our own part of the C++11 runtime, pretty small but essential (in particular exception handling).

           

          > if we can't easily statically link these libraries in, that will prove a problem with migrating to the new standard.

           

          Unfortunately as of this moment we do not support static linking for -std=c++11.

          In general Solaris tends to promote dynamic linking.

          Say, you will not find a dynamic libc on Solaris.

           

          And linking with G++ code statically for us is nearly impossible, as we have differences on the object level.

          Our code will link with G++ dynamic libraries or with other dynamic libraries compiled with G++, but static linking is a real problem.

           

          regards,

          __Fedor.

          • 2. Re: 12.4 beta dynamic library linkage - running 12.4-generated binaries on vanilla Solaris
            jthackray

            Hi __Fedor,


            > 12.4 Beta brings a set of new runtime libraries to support C++11, and these libraries are not available on Solaris.

            > If you want to play with your C++11 binaries you need to bring Beta with you ...

             

            Okay. So, if we want to ship real code to a customer, we can't compile with -std=c++11, unless we ship libstdc++.so.6 in our tarball? Hmmm. We don't have this issue with regular C++98/03. I'm not sure what the legal position on shipping libstdc++.so.6 would be. On Linux, we don't have this issue, as this is already installed on all distros.

             

            > This is a G++ STL library, version 4.7. We rely on it to provide C++11 library support.

             

            Ah, so you're relying on GNU code? That might explain why I saw _GNU_SOURCE defined, for which I had to change some #ifdefs for in our code.


            > Unfortunately as of this moment we do not support static linking for -std=c++11.


            Hmmm. Sounds like it's either "don't use C++11" or "ship libstdc++.so.6, libgcc_s.so.1 and libCrunG3.so.1 in our tarball".

            Are there any other solutions?

             

            Thanks,

            Jonathan.

            • 3. Re: 12.4 beta dynamic library linkage - running 12.4-generated binaries on vanilla Solaris
              Fedor-Oracle

              > if we want to ship real code to a customer, we can't compile with -std=c++11,

               

              Please, remember that is Beta!

              It is not packaged, it is not patched etc.

              You are not supposed to be shipping the code compiled with Beta , -std=c+11 or not.

               

              > Are there any other solutions?

               

              For the final release we will definitely be solving the problem of missing C++11 runtime.

              Our previous approach of handling C++ runtime (shipping it as part of the OS) is not going to work for all the supported platforms.

              I cant say what the final solution will be, but for sure it will be handled through the packages

              and not through the tarball (though you always have and will have an option of redistributing the runtime - as allowed by the license).

               

              Thanks for the feedback, it is really useful (and exactly the kind of feedback we run our Beta program for).

               

              __Fedor.

              • 4. Re: 12.4 beta dynamic library linkage - running 12.4-generated binaries on vanilla Solaris
                jthackray

                > I cant say what the final solution will be, but for sure it will be handled through the packages

                 

                Thanks. That's good and reassuring to hear there's a plan to handle this.