2010/4/27 Srećko Jurić-Kavelj <srecko.juric-kavelj@fer.hr>:
> What's the status on compiling ROS statically? Here
> (http://www.ros.org/wiki/gumros#Installing_the_ROS-libraries_on_the_Gumstix)
> it says it's not quite possible. It could be very practical for things
> like this http://amor-ros-pkg.googlecode.com/files/readRosBagScan.cpp.

hi Srećko,

I had a look at it this morning, and fixed a couple of problems.  But
we still have the issue described in
https://code.ros.org/trac/ros/ticket/912 : we rely on the dependencies
that the linker writes into shared libs.

E.g., if you look at the roslib package, it builds libroslib.  In the
CMakeLists.txt, we tell the linker that libroslib uses librt:
  target_link_libraries(roslib rt)
If we're building libroslib.so, then the linker adds a dependency
libroslib.so -> librt.so (which you can see by running ldd on
libroslib.so).  Linking an executable against libroslib.so works fine,
because it implicitly pulls in librt.so.

But if we're building libroslib.a, then there's nowhere for the linker
to write down the connection to librt.a.  Instead, we have to remember
that any time we link against libroslib.a, we also must link against
librt.a.  Otherwise, the link will fail because of unresolved symbols
in libroslib.a.

We can solve this for roslib by having it export "-lroslib -lrt"
instead of just "-lroslib".  Unfortunately, in general, this means
duplicating the link information in the CMakeListst.txt and
manifest.xml.  Furthermore, in the CMakeLists.txt, there may be logic
deciding what to link against (this is actually the case for roslib,
which only links against librt if not on OS X); there's not a good way
to offer the same programmatic control over linking in the
manifest.xml.

I don't have a good solution to this problem.  Any suggestions?

	brian.