Hard coded path to libgtmshr.so

Help
2011-10-15
2012-12-29
  • George James

    George James - 2011-10-15

    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

     
  • K.S. Bhaskar

    K.S. Bhaskar - 2011-10-21

    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.

     
  • George James

    George James - 2011-10-21

    <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?

     
  • K.S. Bhaskar

    K.S. Bhaskar - 2011-10-25

    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.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks