Shared Library and rpath

User forums > Using Code::Blocks

<< < (3/4) > >>

edwin:

Hi jens,

Thanks also for your post + help.

Yes - I also tried using just the name of the shared lib in the “Link libraries” project setting (TestDll.so) AND setting the relative path to the shared lib in the ‘Search directories” linker tab.

I was hoping that once I built, I would see the following line using the readelf utility:

0x00000001 (NEEDED) Shared library: [TestDll.so]

I though this would have accomplished what I wanted but it did not. For some reason the linker did not use the lib search path and the build failed because the link phase could not find the shared lib – even though the linker search path appeared on the link command line (g++ -L option). Hmm…..

edwin

edwin:
Hello,

I performed a few other tests and finally got the results I needed.

I added the rpath statement to my build:

--- Code: ----Wl,-rpath=.

--- End code ---

Then I rebuilt the Debug image of my shared lib and the EXE (they are in the same C::B workspace). I linked to the shared lib as normal and not to a copy of the shared lib as I mention in a previous post. I linked to the shared lib using a relative path.

Using the command “readelf -d PortingLayerTest” at a shell, I received:

Dynamic section at offset 0x4dee0 contains 29 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [librt.so.1]
0x00000001 (NEEDED) Shared library: [libdl.so.2]
0x00000001 (NEEDED) Shared library: [bin/DebugLinux32/TestDll.so]
0x00000001 (NEEDED) Shared library: [libstdc++.so.6]
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000f (RPATH) Library rpath: [.]
0x0000000c (INIT) 0x804ab1c
0x0000000d (FINI) 0x807df9c
0x00000004 (HASH) 0x80481ac
0x6ffffef5 (GNU_HASH) 0x804880c
0x00000005 (STRTAB) 0x80495fc
0x00000006 (SYMTAB) 0x80488ec
0x0000000a (STRSZ) 3051 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000015 (DEBUG) 0x0
0x00000003 (PLTGOT) 0x8095ff4
0x00000002 (PLTRELSZ) 1472 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x804a55c
0x00000011 (REL) 0x804a52c
0x00000012 (RELSZ) 48 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffe (VERNEED) 0x804a38c
0x6fffffff (VERNEEDNUM) 7
0x6ffffff0 (VERSYM) 0x804a1e8
0x00000000 (NULL) 0x0

Where the path of the TestDll.so is not what I want.

I then took a hex editor and changed the executable file so the path to the shared lib is gone:

Dynamic section at offset 0x4dee0 contains 29 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [librt.so.1]
0x00000001 (NEEDED) Shared library: [libdl.so.2]
0x00000001 (NEEDED) Shared library: [TestDll.so]
0x00000001 (NEEDED) Shared library: [libstdc++.so.6]
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000f (RPATH) Library rpath: [.]
0x0000000c (INIT) 0x804ab1c
0x0000000d (FINI) 0x807df9c
0x00000004 (HASH) 0x80481ac
0x6ffffef5 (GNU_HASH) 0x804880c
0x00000005 (STRTAB) 0x80495fc
0x00000006 (SYMTAB) 0x80488ec
0x0000000a (STRSZ) 3051 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000015 (DEBUG) 0x0
0x00000003 (PLTGOT) 0x8095ff4
0x00000002 (PLTRELSZ) 1472 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x804a55c
0x00000011 (REL) 0x804a52c
0x00000012 (RELSZ) 48 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffe (VERNEED) 0x804a38c
0x6fffffff (VERNEEDNUM) 7
0x6ffffff0 (VERSYM) 0x804a1e8
0x00000000 (NULL) 0x0

Executing this from the shell, running it from the IDE and debugging it from the IDE all work.

Now the question is:
How can I get the C::B build process to only put the name of the shared lib in the “Dynamic section” of the EXE without using a relative path?

Thank you,

edwin

Jenna:
1. name the output-filename of your lib libTestDll.so,
2. copy it to the executables output directory (either in the libs post-build or in the exe's pre-build step, I would prefer the second),
3. add the output directory of the exe to the exe's linker search path,
4. add TestDll (without the lib and the .so) to the exe's link-libraries,
5. add -Wl,-rpath=. to the exe's linker settings

Now it should work from console, if you are in the folder where the files are, and with doubleclick from filemanager (if your exe is a gui-project).

edwin:
Hi jens,

Thank you for your information.

I know exactly what you are saying. I completely agree with everything you said in your last post.

Here is what I have:

1)
I changed the shared lib project to generate libTestDll.so

2)
I do not have to copy the libTestDll.so image to the EXEs output dir because the output dir the shared lib uses is the EXE’s output dir. When I build the shared lib, it gets built to the EXE’s output dir.

3)
Yes, I already had added the EXE output dir to the EXE’s linker search path.

4)
OK, this I changed. I had previously specified “TestDll.so”.

5)
Yes, this was previously configured.

Result:

Dynamic section at offset 0x3bee0 contains 29 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [librt.so.1]
0x00000001 (NEEDED) Shared library: [libdl.so.2]
0x00000001 (NEEDED) Shared library: [libTestDll.so]
0x00000001 (NEEDED) Shared library: [libstdc++.so.6]
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000f (RPATH) Library rpath: [.]
0x0000000c (INIT) 0x804a9ac
0x0000000d (FINI) 0x807366c
0x00000004 (HASH) 0x80481ac
0x6ffffef5 (GNU_HASH) 0x80487e0
0x00000005 (STRTAB) 0x8049520
0x00000006 (SYMTAB) 0x80488c0
0x0000000a (STRSZ) 3013 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000015 (DEBUG) 0x0
0x00000003 (PLTGOT) 0x8084ff4
0x00000002 (PLTRELSZ) 1384 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x804a444
0x00000011 (REL) 0x804a414
0x00000012 (RELSZ) 48 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffe (VERNEED) 0x804a274
0x6fffffff (VERNEEDNUM) 7
0x6ffffff0 (VERSYM) 0x804a0e6
0x00000000 (NULL) 0x0

.. which looks good.

The EXE and shared lib runs as expected in the shell, from within the IDE and while debugging in the IDE.

Thank you very much!

Question 1:
How come the compiler/linker tool chain require a shared lib to be prefixed with “lib”?

I tried for a long time to use a linker search path and the name of the shared lib (like TestDll.so) and for everything I tried, the link phase would always fail because ld could not find the shared lib. I know this is a Linux naming convention but would it not make sence to be able to specify a literal shared lib name and still have the build succeed? I knew it had to be something simple.

Question 2:
I have to test this build on Mac Snow leopard 10.6.4. Do you think the same changes to the project file will have to be made? I would think yes.

I have beating my head - you made my day. :)

Now I can finally get back to work…

Thank you,

edwin

edwin:
Forum Moderator:

I was testing my sig. Delete this if you want.

edwin

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version