great explanation,<div>i did:</div><div><div>readelf -d /usr/local/lib/mylib.so</div><div><br></div><div>Dynamic section at offset 0x7ad28 contains 27 entries:</div><div> Tag Type Name/Value</div>
<div> 0x0000000000000001 (NEEDED) Shared library: [libcudart.so.4]</div><div> 0x0000000000000001 (NEEDED) Shared library: [libcuda.so.1]</div><div> 0x0000000000000001 (NEEDED) Shared library: [libGLEW.so.1.5]</div>
<div> 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]</div><div> 0x0000000000000001 (NEEDED) Shared library: [libm.so.6]</div><div> 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]</div>
<div> 0x0000000000000001 (NEEDED) Shared library: [libc.so.6]</div><div><br></div><div>is there a difference between DT_NEEDED and NEEDED?</div><div><br></div><div>--Cristobal<br><div><br><br><div class="gmail_quote">
On Tue, Oct 4, 2011 at 4:37 AM, Michael Hertling <span dir="ltr"><<a href="mailto:mhertling@online.de">mhertling@online.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 10/03/2011 11:32 AM, Rolf Eike Beer wrote:<br>
> Am Sonntag, 2. Oktober 2011, 12:21:01 schrieb Cristobal Navarro:<br>
>> hello,<br>
>><br>
>> as many of us, i am making a library and this is my first time. I have some<br>
>> concept questions.<br>
>><br>
>> for example, my library depends on "GLEW" library. Therefore applications<br>
>> that use my library must compile with "-lmylib" and "-lGLEW"<br>
><br>
> Nope. Your library has to link against those libraries. The applications only<br>
> have to if they use this interface directly.<br>
<br>
</div>This might be insufficient; look at the following counterexample:<br>
<br>
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)<br>
PROJECT(INSUFFICIENT C)<br>
SET(CMAKE_VERBOSE_MAKEFILE ON)<br>
SET(CMAKE_SKIP_BUILD_RPATH TRUE)<br>
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "void f(void){}\n")<br>
ADD_LIBRARY(f SHARED f.c)<br>
FILE(WRITE ${CMAKE_BINARY_DIR}/g.c "void g(void){f();}\n")<br>
ADD_LIBRARY(g SHARED g.c)<br>
TARGET_LINK_LIBRARIES(g f)<br>
GET_TARGET_PROPERTY(G_LIBRARY g LOCATION)<br>
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c<br>
"int main(void){g(); return 0;}\n")<br>
ADD_EXECUTABLE(main main.c)<br>
TARGET_LINK_LIBRARIES(main ${G_LIBRARY})<br>
<br>
This exemplary project has two shared library targets f and g and an<br>
executable target main; g uses and is linked against f, and main uses<br>
and is linked against g. The latter is done with g's full path so that<br>
TARGET_LINK_LIBRARIES() doesn't track the transient dependencies main-<br>
on-g-on-f. That's the situation you aim at, if I understand correctly.<br>
A "readelf -d libg.so" reveals that libg.so actually has a DT_NEEDED<br>
tag of "libf.so", and main's link command line essentially reads<br>
<br>
gcc .../main.c.o -o main ... -L${CMAKE_BINARY_DIR} -lg<br>
<br>
i.e. main is about to be linked against libg.so only. Nevertheless, the<br>
linking operation fails since libf.so is not found although it resides<br>
next to libg.so in the build directory. The reason is that ld in fact<br>
uses libg.so's DT_NEEDED tags to learn about the prerequisite libf.so,<br>
but has no hint where to find it; see ld's manpage - particularly the<br>
-rpath-link section with its 8-item list - for more information. The<br>
reason why it usually works even without TARGET_LINK_LIBRARIES()'s<br>
ado is item 6 in connection with CMake's elaborate RPATH handling.<br>
In short: DT_NEEDED tells which library, but not where it is.<br>
<br>
Furthermore, it's not necessary that g is linked against f as long as<br>
both are mentioned on the linker command line in the correct order or<br>
recognized by other means. It's also not necessary for executables to<br>
be linked against libraries they're immediately referring to; e.g. if<br>
main calls f() and libg.so has a hint to libf.so, it's sufficient for<br>
main to link against libg.so, provided that libf.so can be found. The<br>
essence is that for an executable's creation, all symbols need to be<br>
resolved, i.e. each necessary library must be found - may it via an<br>
explicit specification on the command line, may it by following DT<br>
_NEEDED via DT_RPATH or whichever methods the linker offers to<br>
locate libraries. However, if "mylib" depends on "GLEW", it's<br>
usually perfect to link the former against the latter.<br>
<br>
Regards,<br>
<font color="#888888"><br>
Michael<br>
</font><div class="im"><br>
>> is it possible, to make the "-lGLEW" implicit inside my library?? or making<br>
>> the user put it manually is the way to go?<br>
><br>
> You do TARGET_LINK_LIBRARIES(mylib /path/to/glew/libglew.so). That's all. To<br>
> get the path to GLEW in a system independent way please have a look on<br>
> FIND_LIBRARY.<br>
><br>
> The only exception is if your library is a static one and the target<br>
> application is not built with CMake. The problem is that you can't put this<br>
> information in static libraries. Writing a pkgconfig or CMake export file is the<br>
> way to go then.<br>
><br>
> Eike<br>
</div><div><div></div><div class="h5">--<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br></div></div></div>