I am trying to dynamically load a library and call a function from USER_HEADER.hpp
in windows version I just include windows.h and call LoadLibrary function
for linux version, I want to use the analog functions: dlopen, therefore I added CXXFLAGS += -ldl to my make/local file. The executable builds successfully, but whenever I execute it, I get this error message
./my_model: /usr/lib64/libstdc++.so.6: version GLIBCXX_3.4.20' not found (required by ./my_model) ./my_model: /usr/lib64/libstdc++.so.6: versionCXXABI_1.3.9’ not found (required by ./my_model)
./my_model: /usr/lib64/libstdc++.so.6: version GLIBCXX_3.4.15' not found (required by ./my_model) ./my_model: /usr/lib64/libstdc++.so.6: versionGLIBCXX_3.4.21’ not found (required by ./my_model)
I tried googling possible solutions without any success, I even tried to link ld statically, apparently that is not working either. I am kind of unexperienced in linux environment, can anybody please point me to some solution? Did anyone tried this?
I think what is happening is that the flags used to compile the dynamic shared library imply that it is not ABI compatible with the flags used to compile R. This wouldn’t happen on Windows because the only viable compiler is Rtools. If that is due to changing the flags in order to fit Stan models on Linux, we can try to help you. Also, I think -ldl should be part of LDFLAGS rather than CXXFLAGS.
Hi, thank you for your fast response. I was referring to cmdstan-guide2.17.1 there was no LDFLAGS, but there was LDLIBS, so I tried that first, didn’t work, and I switched to CXXFLAGS. After you mentioned I tried with LDFLAGS now. Again, it compiles and I see the same error when running the model.
Most probably you are right about flags not being compatible, I just need to fit the same model and compile the executable in linux. The shared libraries are in our enterprise application and are not managed by me - so I have no easy way of modifying their build flags. Am I missing some information you might need to know if you can help me?
Thank you again
Yes, although I am not sure what. Let me see if I understand:
You were using CmdStan under Windows
You utilized the mechanism where you could utilize external C++ code to define a function that you declared in the functions section of a Stan program
That worked on Windows
You switched over to CmdStan on some version of Linux
You got the Bernoulli example that comes with CmdStan to run
You tried to utilize the mechanism where you could utilize external C++ code to define a function that you declared in the functions section of a Stan program and it did not work on Linux, apparently due to a ABI incompatibility
Answer to all of those questions above is YES. Im am only hesitant about the last point, that it is due to ABI incompatibility, but because I have no better explanations, I trust your judgement.
OK. I am guessing that your external C++ code calls some library that was compiled with a different compiler or with different flags. Are you allowed to say what that library is?
Now when I think of it: At the very beginning I tried to link to Qt library itself, in order to use QLibrary class for dynamically loading shared libraries. I did not manage to do that, so I decided to write platform specific code with #ifdeflinux… and LoadLiabrary for Windows. My problem would have been solved by QLibrary class alone, if I would have managed to link to it on both platforms
For internal corporate stuff, there is not a whole lot I or anyone on a mailing list can do to actually solve your problem. But it sounds as if it should be workable in principle if you can compile your Stan program in the same way that the external library was compiled, which should be known by whoever compiled / installed the external library.
I have got so excited yesterday I forgot to thank you. Your advice actually helped. We looked into build flags and that was due to incompatibilities of libraries. You saved so much time for me, man, thank you :)