Shared Library and rpath

User forums > Using Code::Blocks

<< < (2/4) > >>

oBFusCATed:
The configuration you've described should work without the rpath settings, remove it and report what have happened.

edwin:

Hi oBFusCATed,

I removed rpath from the build and this is the result I get when I then run readelf:

Executed command:
readelf -d PortingLayerTest

Result:
Dynamic section at offset 0x4dee8 contains 28 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]
0x0000000c (INIT) 0x804ab18
0x0000000d (FINI) 0x807df9c
0x00000004 (HASH) 0x80481ac
0x6ffffef5 (GNU_HASH) 0x804880c
0x00000005 (STRTAB) 0x80495fc
0x00000006 (SYMTAB) 0x80488ec
0x0000000a (STRSZ) 3049 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000015 (DEBUG) 0x0
0x00000003 (PLTGOT) 0x8095ff4
0x00000002 (PLTRELSZ) 1472 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x804a558
0x00000011 (REL) 0x804a528
0x00000012 (RELSZ) 48 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffe (VERNEED) 0x804a388
0x6fffffff (VERNEEDNUM) 7
0x6ffffff0 (VERSYM) 0x804a1e6
0x00000000 (NULL) 0x0

Again, the “PortingLayerTest” executable and the “TestDll.so” shared lib are in the same dir. When I run the PortingLayerTest executable in a command window, I get:

./PortingLayerTest: error while loading shared libraries: bin/DebugLinux32/TestDll.so: cannot open shared object file: No such file or directory.

I would think that if I could rebuild the test app so that:

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

looks like this:

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

…all would be OK.

I can’t believe I am not getting this…. hoping you can help.

edwin

oBFusCATed:

--- Quote from: edwin on August 11, 2010, 08:17:18 pm ---Again, the “PortingLayerTest” executable and the “TestDll.so” shared lib are in the same dir. When I run the PortingLayerTest executable in a command window, I get:

./PortingLayerTest: error while loading shared libraries: bin/DebugLinux32/TestDll.so: cannot open shared object file: No such file or directory.

--- End quote ---
On linux (and other unixes I suppose) the current directory is not added to the search path for executable and libraries. This is done for security reasons.
Try "export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:." && ./yourApp"
Also does your app run from inside C::B. Build -> Run or Debug->Start, both should work, they work for me.

Jenna:
How do you add your library ?
With full path or just as TestDll ?

edwin:
Thanks for your response oBFusCATed.

--- Quote ---On linux (and other unixes I suppose) the current directory is not added to the search path for executable and libraries.

--- End quote ---
This I did not realize! Thanks for telling me this.

I will try your LD_LIBRARY_PATH suggestion and see what occurs. What I was hoping to accomplish was to encode only the name of the shared lib into the exe and hope everything works out – and not have to do anything with environment vars.

I performed another test since my last post. I did the following:

1)
Copied the Debug shared lib image from the common output directory to the main EXE’s project directory.

2)
In the exe’s project settings, I configured the debug build to link to the “./TestDll.so” copy of the shared library.

2)
Rebuilt the Debug exe image.

3)
Checked the “dynamic section” dump info using readelf. This is what I received:

Dynamic section at offset 0x4dee8 contains 28 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]
0x0000000c (INIT) 0x804ab08
0x0000000d (FINI) 0x807df8c
0x00000004 (HASH) 0x80481ac
0x6ffffef5 (GNU_HASH) 0x804880c
0x00000005 (STRTAB) 0x80495fc
0x00000006 (SYMTAB) 0x80488ec
0x0000000a (STRSZ) 3034 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000015 (DEBUG) 0x0
0x00000003 (PLTGOT) 0x8095ff4
0x00000002 (PLTRELSZ) 1472 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x804a548
0x00000011 (REL) 0x804a518
0x00000012 (RELSZ) 48 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffe (VERNEED) 0x804a378
0x6fffffff (VERNEEDNUM) 7
0x6ffffff0 (VERSYM) 0x804a1d6
0x00000000 (NULL) 0x0

Notice now the line:

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

Which does force the loader to look in the same dir as the EXE for the shared lib.

When I execute the main EXE program (I typed ./PortingLayerTest at the shell), it runs as expected and uses the shared lib in the exe’s dir.

Also, the exe built this way can be executed from the IDE and debugged from the IDE.

At this point, I get the behavior I was looking for but I don’t like the fact that I have to link to a copy of the shared lib in the EXE’s project dir.

Question:
Can I get this same effect somehow without having to copy over the shared lib to the EXE’s projectd dir and linking to that temp lib image?

I have been trying to get the same result as above using “link search path” build settings instead of copying the shared lib but I have failed up to this point. For some reason, specifying a shared lib linker search path causes the link phase to fail (not find the shared lib).

Any further thoughts you have are appreciated.

Thank you,

edwin

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version