This website uses browsing/session and functional cookies to ensure you get the best experience. Learn More

Debianizing YARP

From Wiki for iCub and Friends
Jump to: navigation, search

Issues thrown up during preparation for Debian packaging will be listed here. See launchpad for the current /debian/* directory. Commonly a project provides a yarp-x.x.x.tar.gz file and a debian.tar.gz file in parallel, that is, if upstream decides to do packaging herself.

Contents

Copyright/license

  • All files should have copyrights defined. Also scripts, examples, pictures.
  • Check e.g.: head example/cuda/progs/*.cu
    • Author of cuda stuff is on vacation in Croatia, promises to fix soon.
      • Seems to be FIXED.
    • email out to yayarpview author.
      • FIXED.
    • gtkdemo? still no decision.
      • FIXED.
  • A script to check which files need to be done still is placed here because it cannot be uploaded.

Lintian

The current lintian output can be obtained here: http://pastebin.com/XDq0dmLh It is important that the source is "Lintian clean" to be accepted by the Debian community. Feel free to update this link if you remove errors, but make sure you actually build in a Debian sid environment, and do not use lintian from your own OS.

Creating proper SO files

This one is important, please apply the following patch. Because of changes to CMakeLists.txt files I had to recreate this patch (sure, I should actually not create patches against the SVN repos, only against tarball releases). It adds set_target_properties with SOVERSION and VERSION to the CMakeLists.txt files of the libraries:

add_library(YARP_dev ${folder_source} ${folder_header})
set_target_properties(YARP_dev PROPERTIES SOVERSION 0 VERSION 0.1)
target_link_libraries(YARP_dev YARP_sig YARP_OS)

This needs to be done for all YARP libraries.

  • FIXED

Linking

  • According to dpkg-shlibs there are libs uselessly linked. I gave one example in the form of a patch previously. I removed it, because it is not up to date anymore. Please, consider the linking rules. It is now silently assumed for example when linking with libYARP_init.so, that the other YARP libraries are silently linked too. It is better to specify matters exactly the way they are.

A full report:

dependency on librt.so.1 could be avoided if "debian/libyarp-os0/usr/lib/libYARP_OS.so.0.1" were not uselessly linked against it 
dependency on librt.so.1 could be avoided if "debian/libyarp-sig0/usr/lib/libYARP_sig.so.0.1" were not uselessly linked against it 
dependency on librt.so.1 could be avoided if "debian/libyarp-dev0/usr/lib/libYARP_dev.so.0.1" were not uselessly linked against it 
dependency on libACE-5.7.7.so could be avoided if "debian/libyarp-init0/usr/lib/libYARP_init.so.0.1" were not uselessly linked against it 
dependency on librt.so.1 could be avoided if "debian/libyarp-init0/usr/lib/libYARP_init.so.0.1" were not uselessly linked against it 
dependency on libpthread.so.0 could be avoided if "debian/libyarp-init0/usr/lib/libYARP_init.so.0.1" were not uselessly linked against it 
dependency on libYARP_sig.so.0 could be avoided if "debian/yarp-bin/usr/bin/yarpdev" were not uselessly linked against it 
dependency on libACE-5.7.7.so could be avoided if "debian/yarp-bin/usr/bin/yarpdev debian/yarp-bin/usr/bin/yarp" were not uselessly linked against it 
dependency on librt.so.1 could be avoided if "debian/yarp-bin/usr/bin/yarpdev debian/yarp-bin/usr/bin/yarp" were not uselessly linked against it 
dependency on libpthread.so.0 could be avoided if "debian/yarp-bin/usr/bin/yarpdev debian/yarp-bin/usr/bin/yarp" were not uselessly linked against it
dependency on libfontconfig.so.1 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it 
dependency on libatk-1.0.so.0 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it 
dependency on librt.so.1 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it 
dependency on libgio-2.0.so.0 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it 
dependency on libcairo.so.2 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it 
dependency on libpango-1.0.so.0 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it 
dependency on libgmodule-2.0.so.0 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it 
dependency on libpangocairo-1.0.so.0 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it 
dependency on libfreetype.so.6 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it 
dependency on libpangoft2-1.0.so.0 could be avoided if "debian/yarp-view/usr/bin/yarpview" were not uselessly linked against it
    • Compiler flag added to help with this.

EXPORT

If I may, I would recommend to use the following EXPORT macro:

 #define EXPORT __attribute__((visibility("default")))

As explained on http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html

You can make explicit which symbols to export by using it like this:

 class EXPORT yarp::os::ConstString {

The g++ compiler will need an additional flag in that case: -fvisibility=hidden

Symbols are generated by:

 dpkg-gensymbols -v0.1 -plibyarpos -e/yourfreshlycompiled/libYARP_OS.so -Olibyarposwithless.symbols

But you won't need to generate those symbols yourself, that would then be my responsibility as maintainer. Just update the SONAME if you change header files with the "EXPORT" keyword defined. And the change needs to be an actual change in function name or the deletion of a function. The mere addition of a function does not mean that the ABI is broken.

From version 1.15.8 upwards, dpkg-gensymbols does have c++ pattern type, see its man page, if you have such a recent version (it's on Debian sid, so if you have build before for unstable, you can use something like sudo DIST=sid cowbuilder --login to find out, most manpages online are older). For example, even if _ZThn8_N3NSB6ClassDD1Ev@Base on 32bit architectures will probably be _ZThn16_N3NSB6ClassDD1Ev@Base on 64bit ones, it can be matched with a single c++ pattern:

      libdummy.so.1 libdummy1 #MINVER#
          [...]
          (c++)"non-virtual thunk to NSB::ClassD::~ClassD()@Base" 1.0
          [...]

The demangled name above can be obtained by executing the following command:

          $ echo '_ZThn8_N3NSB6ClassDD1Ev@Base' | c++filt
    • Preliminary work has been done on this, set YARP_CLEAN_API flag in CMake to see it.

OpenSUSE

In case of a .spec file, it is really recommended to respect a -DLIB_SUFFIX=64 cflag. For that append all install targets in the CMakeLists.txt files with ${LIB_SUFFIX} after DESTINATION lib.

 install(TARGETS YARP_init EXPORT YARP COMPONENT runtime DESTINATION lib${LIB_SUFFIX})

The current yarp.spec file can be found at: https://build.opensuse.org/package/files?package=YARP&project=home%3Aannevanrossum

    • LIB_SUFFIX now respected --paulfitz

Library descriptions

  • Add info about libYARP_math
  • Add info about libYARP_name
  • (What does it use? Why is it added? What are the plans with it? Is it used by YARP itself or by its "users"?)
Personal tools
Namespaces

Variants
Actions
Navigation
Print/export
Toolbox