C/C++ shared libraries on Linux.

This is the first time that I created a dynamic library in linux and although the program works, I do not get the correct information about the library when executing ldd.

I explain the details:

1) Source code:

bye_fn.c:

#include <stdio.h>
#include "hello.h"

void bye (const char* name)
{
printf ("\n\n%s, I see you soon !\n\n", name);
}

hello_fn.c:

#include <stdio.h>
#include "hello.h"

void hello (const char* name)
{
printf ("\n\nHello, %s !\n\n", name);
}

hello.c:

#include "hello.h"
#include <stdio.h>

int main (void)
{
hello ("Jos�");
printf ("Please to meet you. You will work with us. You start next week. Congratulations !\n");
bye ("Jos�");

return 0;
}

2) Steps followed to obtain the shared library and the executable program:

gcc -fPIC -Wall -c hello_fn.c

gcc -fPIC -Wall -c bye_fn.c

gcc -shared -Wall -o libhello.so hello_fn.o bye_fn.o

gcc hello.c libhello.so -o hello

3) Steps followed to execute the "hello" program:

export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:./

./hello

It works right.

4) My question:

If I execute the command: ldd hello
the output is:

    linux-vdso.so.1 =>  (0x00007ffc1db7c000)
    libhello.so => not found
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007eff63dd2000)
    /lib64/ld-linux-x86-64.so.2 (0x00007eff6419b000)

I would to get correctly the information about the library "libhello.so" that is being used by "hello".

What should I change or add in the steps described in point 2, to achieve this?

libhello.so has to be in the LD_LIBIRARY_PATH variable for ldd to find it. You should NOT put personal directories in the path.

for testing purposes, why not! Jose only want's to see that it works principally.

Thanks,

I have excuted:

export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:[FULL PATH TO .so FILE]

where:
[FULL_PATH_TO .so FILE] = /home/jose/.../hello_program

But if I execute the command: ldd hello
the output follows being:

linux-vdso.so.1 =>  \(0x00007ffc1db7c000\)
libhello.so => not found
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 \(0x00007eff63dd2000\)
/lib64/ld-linux-x86-64.so.2 \(0x00007eff6419b000\)

I am working on Ubuntu 14.0.4

LD_LIBRARY_PATH needs the path and not the file name.
check out: LD_LIBRARY_PATH=${LD_LIBRARY_PATH}: /home/jose/.../

There are also programs like patchelf that can set the "rpath" after linking.

some simple, nevertheless working code(bin:main.c so:so.c):

1. libtool --mode=compile gcc -c -O3 so.c
2. libtool --mode=link gcc -o libso.la so.lo -rpath /usr/local/lib -version-info 6:0:5
3. gcc -L`pwd`/.libs -Wall -o so main.c -lso
4. export LD_LIBRARY_PATH=.
5. ./<app>

You are not allowed to put relative paths in LD_LIBRARY_PATH. That is a very insecure thing to do.

for further communications please note explicitly that your argument is pure moralistic and not a technical necessity.

It's not moralistic. It breaks assumptions built into the linking system, may pollute caches, and very likely isn't portable. What will happen is implementation-dependent. The behavior you get after cd can be surprising, and some systems may refuse relative paths outright.

Let me put it this way: Putting . and .. in PATH also causes real issues in a shell. These paths are supposed to be absolute. When they're not, the cache the shell uses for tab completion may get confused, as now needs to dump it every time you cd and may not do so. A false positive or negative in tab completion is just annoying, in loading libraries it may actually break something.

Just because you can do something doesn't mean it will work the way you think it will, and just because you can do something doesn't make it a smart idea.