We have been compiling with gcc successfully on Solaris 10. Now we are porting to 64-bit on Solaris 11 (sol11_64). We use a library developed in house called MSP and use -wl,rpath (equivalent to -R... also tried with -R) during compile to specify the run-time library locations. On sol10, the output of LDD shows 2 of 2 MSP libraries found. On sol11_64, there's now 3 libraries shown in the LDD output, with the new one not being able to be found, even though it is in the same location as one of the others. If I add that location to my LD_LIBRARY_PATH, then LDD picks it up. We do NOT wish to use LD_LIBRARY_PATH as a permanent solution.

sol10 LDD output:

    libmsp.so =>     /opt/msp/lib/fiorano/libmsp.so
    libfmq-crtl.so =>        /opt/msp/lib/fiorano/vendor-files/lib/libfmq-crtl.so

sol11_64 LDD output:

    libmsp.so =>     /opt/msp/lib/fiorano/libmsp.so
    libfmq-crtl.so =>        /opt/msp/lib/fiorano/vendor-files/lib/libfmq-crtl.so
    libfmq-crtl-ssl.so =>    (file not found)

sol11_64 LDD output with path in LD_LIBRARY_PATH:

    libmsp.so =>     /opt/msp/lib/fiorano/libmsp.so
    libfmq-crtl.so =>        /opt/msp/lib/fiorano/vendor-files/lib/libfmq-crtl.so
    libfmq-crtl-ssl.so =>    /opt/msp/lib/fiorano/vendor-files/lib/libfmq-crtl-ssl.so

I did check permissions:

-rwxr-xr-x   1 root     root        2.0M Dec 18 17:49 libfmq-crtl-ssl.so*
-rwxr-xr-x   1 root     root        2.0M Dec 18 17:49 libfmq-crtl.so*
  • You're aware you have answered your own question? Just add the new dynamic library folder path to LD_LIBRARY_PATH during initialization of the server. – Marcel Feb 4 '19 at 18:08
  • 1
    ok, it seems it's not the solaris way, here: "If you need to bake a specific runpath into your library or executable, then you should use the -R flag to the linker. If building with gcc, then use -Wl,Rpath (I think)." (from: stackoverflow.com/a/21542094/2172543) – Marcel Feb 4 '19 at 18:10
  • I've edited the question to include that we have also tried -wl,rpath and also do not wish to use LD_LIBRARY_PATH as a permanent workaround. We would prefer to know why this is occurring and how to fix it. – codenaugh Feb 4 '19 at 18:35
  • Have you not added your library path with crle? – Michael Hampton Feb 4 '19 at 20:45

Since this library was a new dependency on sol11_64 all of a sudden, I needed to add it elsewhere in our makefile, specifically our LIBS variable, which is passed in during linking along with the runtime library paths. I think this part tells it what libraries to actually look for.


LIBS := -lpthread -lmsp -lfmq-crtl -lxml2


LIBS := -lpthread -lmsp -lfmq-crtl -lfmq-crtl-ssl -lxml2

makefile target:

$(EXE): $(MACHOBJ) $(MACH)/main.o
    cd $(MACH); $(CC) -o ../$@ $(OBJ) main.o \
    ../../lib/$(MACH)/libmain.a \
    -L/opt/msp/lib/fiorano \
    -L/opt/msp/lib/fiorano/vendor-files/lib \
    -R/opt/msp/lib/fiorano \
    -R/opt/msp/lib/fiorano/vendor-files/lib \

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.