Link with relative paths in gcc

I use a simplified example to explain my case.

I have two libme.so files that have different implementations, and I have already verified that they can work in the same project at the same time. One is located at. / root / v 1 /, and the other is located at. / root / v 2 /

My "main" .so file is associated with these two libme.so files and is located in. /root/libtest.so

Now I have a requirement to make things moveable. That is, if I copy the entire "root" directory to another location or even to another machine (assuming compatibility with binary), everything should work fine.

My question is to do the job, which gcc line should I use to build libtest.so?

I tried the following two:

(1) (if I enter the root directory)

>gcc -shared -o libtest.so ./v1/libme.so ./v2/libme.so 

This will cause libtest.so to have these 2 link dependencies as with absolute paths. This can be checked with ldd:

 >ldd libtest.so /home/design/root/v1/libme.so /home/design/root/v2/libme.so 

Obviously, the paths are fixed. Therefore, as soon as I moved the "root" directory, it could not find libme.so at runtime. Setting the LD_LIBRARY_PATH note does not work in this case, since the path from ldd is an absolute path. The runtimer loader will not look for LD_LIBRARY_PATH to find libme.so.

(2)

 >gcc -shared -o libtest.so -lme -L./v1 -L./v2 

This will only work if we have one version of libme.so. In this case, version c. / v 2 will not be connected. The same problem exists for -rpath.

Given that I have other options?

Note that there are some limitations: (1) cannot rename libme.so to other names, such as libme_v1.so (2) libtest.so must be referenced in both versions of libme.so

+4
source share
1 answer

Teppik is right. This turned out to be a problem on only one of my cars. Switching to another RHEL5.8 machine, and I'm all set up. It looks like the linker configured by someone is installed on the original machine.

0
source

All Articles