Linux needs to find libgtmshr.so for the process to link to it dynamically. You should be able use the LD_LIBRARY_PATH environment variable. Alternatively, you can make libgtmshr.so a "standard" library with ldconfig.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<y goal is to make this program deployable with minimal configuration, the use of ldconfig is probably as troublesome as running make in each new environment, so that option probably doesn't get me any further.
I'll investigate using LD_LIBRARY_PATH, but I'm not sure how to tell the compiler what to do with it. Do I use LD_LIBRARY_PATH in place of $gtm_dist? How does that stop the path from being hard coded?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a Linux issue not a GT.M issue. In order to call-in to GT.M, Linux needs to find the GT.M shard library libgtmshr.so. You don't need $LD_LIBRARY_PATH at compile time - it is used at run time to find shared libraries, just like $PATH is used to find executable binaries. And yes, you will also need $gtm_dist, because GT.M needs it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
I'm using the C callin interface to run some GT.M stuff. However, the compiled executable has a hard coded path in it's reference to libgtmshr.so
What's the recommended best practice for compiling things so that I can move the executables from one place to another without too much pain?
This is the procedure I'm using the compile:
gcc -c myProgram.c -I$gtm_dist
gcc myProgram.o -o ymProgram -L$gtm_dist -Wlgtmshr -Wlc -WR $gtm_dist/libgtmshr.so
George
Linux needs to find libgtmshr.so for the process to link to it dynamically. You should be able use the LD_LIBRARY_PATH environment variable. Alternatively, you can make libgtmshr.so a "standard" library with ldconfig.
<y goal is to make this program deployable with minimal configuration, the use of ldconfig is probably as troublesome as running make in each new environment, so that option probably doesn't get me any further.
I'll investigate using LD_LIBRARY_PATH, but I'm not sure how to tell the compiler what to do with it. Do I use LD_LIBRARY_PATH in place of $gtm_dist? How does that stop the path from being hard coded?
This is a Linux issue not a GT.M issue. In order to call-in to GT.M, Linux needs to find the GT.M shard library libgtmshr.so. You don't need $LD_LIBRARY_PATH at compile time - it is used at run time to find shared libraries, just like $PATH is used to find executable binaries. And yes, you will also need $gtm_dist, because GT.M needs it.