[CMake] what is best for library dependencies?

Cristobal Navarro axischire at gmail.com
Tue Oct 4 10:39:10 EDT 2011


great explanation,
i did:
readelf -d /usr/local/lib/mylib.so

Dynamic section at offset 0x7ad28 contains 27 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libcudart.so.4]
 0x0000000000000001 (NEEDED)             Shared library: [libcuda.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libGLEW.so.1.5]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

is there a difference between DT_NEEDED and NEEDED?

--Cristobal


On Tue, Oct 4, 2011 at 4:37 AM, Michael Hertling <mhertling at online.de>wrote:

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


More information about the CMake mailing list