build and link shared lib

[sunaj]

Hi,

This is a beginner question, but I'm stuck so please help me if you can :)
I'm trying to compile a simple c++ program with g++ on 64bit ubuntu - and I just cannot get it working. I've tried every example that I could find on the web and could get none of them working.

mydll.cpp

#include "mydll.h"
int hello()
{
  printf ("Hello World!\n");
}

mydll.h

#include <stdio.h>
int hello();

myprog.cpp

#include "mydll.h"
int main ()
{
  hello ();
}

This is what comes closest to working:

g++ -fPIC -c mydll.cpp
g++ -fPIC -shared -rdynamic -o libfoo.so mydll.o
g++ -fPIC -rdynamic -o foo myprog.cpp -L. -lfoo -ldl

(from http://gcc.gnu.org/onlinedocs/libstdc++/faq.html), but when I run the executable I get: "error while loading shared libraries: libfoo.so: cannot open shared object file: No such file or directory" (the file is in the folder ok).

Can somebody please provide g++ 'code' that will make the above code build, link and execute?

thx in advance
sunaj

[kbw]

Have you added the path to your LD_LIBRARY_PATH?
http://www.eyrie.org/~eagle/notes/rpath.html

[sunaj]

Now I've tried

1) to add the path of the above files to /etc/ld.so.conf/libc.conf, /etc/ld.so.conf/libR.conf and /etc/ld.so.conf/x86_64-linux-gnu.conf files and rebuild using

g++ -fpic -c mydll.cpp
g++ -shared -o libmydll.so mydll.o
g++ myprog.cpp -o myprog -L. -lmydll

-> same error when I run ./myprog

2) added the path to my default search path:
export PATH=$PATH:~/code/cpp/test/testdll
and rebuild using the above g++ 'code'
-> same error when I run ./myprog

3) adding a new environment variables called LD_LIBRARY_PATH with the path as value
and rebuild using the above g++ 'code'
-> same error when I run ./myprog

any suggestions?

[sunaj]

Success! thx for your help.
I created a new libJ.conf files with the path of my code in the /etc/ld.so.conf directory, ran ldconfig and now it works. Why does none of the many tutorials on building and linking with g++ mentions this rather crucial step? (you don't have to answer that).

[kbw]

It's OS specific, rather than a language thing.

[kev82]

Adding an entry in the dynamic loader configuration file is far from ideal, if you move your application development tree it will no longer work. Also, it is potentially, a rather large security hole on a multi-user system.

I think there is quite a lot of disagreement on how to deal with this problem, and there is no perfect solution. A lot of people use LD_LIBRARY_PATH wrapper scripts, which should work - if it doesn't work you're not setting the path correctly, or not passing the variable to the executable.

However, I prefer the rpath solution, at least for my development trees. Assuming the libraries are in the same directory as the executable, add the following to the executable compilation command:

-Wl,--rpath,'$ORIGIN'

However, don't use this blindly, it is not a particularly good solution for deployment.

You may want to investigate the ldd command to get a bit more understanding about what's going on.