Hide all symbols by default

[jorisv]

Fixe #2462

TODO:

• Set all symbol hidden by default
  • Libraries
  • Bindings
• Ensure bindings don't define same symbol many time
  • include/pinocchio/bindings/python/parsers/python.hpp
    • pinocchio::python::buildModel is exported by all bindings
  • Add development/misc/common_symbols.py scripts to detect common symbols in many libraries
• Wait merge of Add pinocchio_python_parser target #2475
• Remove PYWRAP symbol export code
• Test and fix
  • default
  • collision
  • autodiff
  • codegen
  • extra
  • casadi
  • openmp
  • mpfr
  • clang
  • all

[github-actions]

👋 Hi,
This is a reminder message to assign an extra build label to this Pull Request if needed.
By default, this PR will be build with minimal build options (URDF support and Python bindings)
The possible extra labels are:

• build_collision (build Pinocchio with coal support)
• build_casadi (build Pinocchio with CasADi support)
• build_autodiff (build Pinocchio with CppAD support)
• build_codegen (build Pinocchio with CppADCodeGen support)
• build_extra (build Pinocchio with extra algorithms)
• build_mpfr (build Pinocchio with Boost.Multiprecision support)
• build_sdf (build Pinocchio with SDF parser)
• build_accelerate (build Pinocchio with APPLE Accelerate framework support)
• build_all (build Pinocchio with ALL the options stated above)

Thanks.
The Pinocchio development team.

[jorisv]

When working on this PR, I found the following issue with GCC, explicit template instantiation and symbol visibility.

template <typename T>
struct MyClass
{
  void bar(MyClass<int>);

  int getContacts() const
  {
    return m_value;
  }
  int m_value;
};

#ifndef BUG
extern template struct __attribute__((visibility("default"))) MyClass<int>;
#endif

template <typename T>
void MyClass<T>::bar(MyClass<int>) {}

#ifdef BUG
extern template struct __attribute__((visibility("default"))) MyClass<int>;
#endif

template struct MyClass<int>;

When builded with the following command line:

CC=g++
FLAGS=-DBUG
$CC -fPIC -Wall -Wextra -pedantic -fvisibility=hidden -fvisibility-inlines-hidden $FLAGS -c test.cpp -o test.o
$CC -fPIC -Wall -Wextra -pedantic -fvisibility=hidden -fvisibility-inlines-hidden -shared -Wl,-soname,libtest.so test.o -o libtest.so
nm -C libtest.so | grep MyClass

We have the following output:

test.cpp:21:63: warning: type attributes ignored after type is already defined [-Wattributes]
   21 | extern template struct __attribute__((visibility("default"))) MyClass<int>;
      |                                                               ^~~~~~~~~~~~
00000000000010d8 t MyClass<int>::bar(MyClass<int>)
00000000000010e6 t MyClass<int>::getContacts() const

The visibility attribute is ignored.

When build with FLAGS=

00000000000010d8 W MyClass<int>::bar(MyClass<int>)
00000000000010e6 W MyClass<int>::getContacts() const

The symbols are well exported.
So we need to declare the explicit template instantiation before defining any function that use MyClass.

There is no issue with clang++.

[jorisv]

Another interesting case. I think there is an issue with clang on osx and thread-local symbol visibility.

We can reproduce the issue by compiling this code (test.cpp):

struct Toto {Toto(int* ptr) {}};
template<class Base>
struct CGOStreamFunc {
  static thread_local Toto FUNC;
};
template<class Base>
thread_local Toto CGOStreamFunc<Base>::FUNC(nullptr);

template struct CGOStreamFunc<double>;

Then building it with:

clang++ -fPIC -c test.cpp -o no_hidden.o
clang++ -fvisibility=hidden -fPIC -c test.cpp -o hidden.o

If we run nm -C no_hidden.o we will have the following output:

0000000000000070 s thread-local initialization routine for CGOStreamFunc<double>::FUNC
000000000000004c T thread-local wrapper routine for CGOStreamFunc<double>::FUNC

If we run nm -C hidden.o we will have the following output:

...
0000000000000070 S thread-local initialization routine for CGOStreamFunc::FUNC
000000000000004c T thread-local wrapper routine for CGOStreamFunc::FUNC
...

The CGOStreamFunc<double>::FUNC symbol visibility change. It's exported when building with -fvisibility=hidden and private
when build without -fvisiblitiy.

This create a linking error when building Pinocchio in Debug mode with codegen activated.
cppaddcg define a static thread local variable in cg/cg.hpp that create the following error:

duplicate symbol 'thread-local initialization routine for CppAD::cg::CGOStreamFunc<double>::FUNC' in:
    bindings/python/CMakeFiles/pinocchio_pywrap_cppadcg.dir/spatial/expose-symmetric3.cpp.o
    bindings/python/CMakeFiles/pinocchio_pywrap_cppadcg.dir/spatial/expose-force.cpp.o
duplicate symbol 'thread-local initialization routine for CppAD::cg::CGOStreamFunc<double>::FUNC' in:
    bindings/python/CMakeFiles/pinocchio_pywrap_cppadcg.dir/spatial/expose-symmetric3.cpp.o
    bindings/python/CMakeFiles/pinocchio_pywrap_cppadcg.dir/spatial/expose-inertia.cpp.o
duplicate symbol 'thread-local initialization routine for CppAD::cg::CGOStreamFunc<double>::FUNC' in:
    bindings/python/CMakeFiles/pinocchio_pywrap_cppadcg.dir/spatial/expose-symmetric3.cpp.o
    bindings/python/CMakeFiles/pinocchio_pywrap_cppadcg.dir/spatial/expose-SE3.cpp.o
duplicate symbol 'thread-local initialization routine for CppAD::cg::CGOStreamFunc<double>::FUNC' in:
    bindings/python/CMakeFiles/pinocchio_pywrap_cppadcg.dir/spatial/expose-symmetric3.cpp.o
    bindings/python/CMakeFiles/pinocchio_pywrap_cppadcg.dir/spatial/expose-motion.cpp.o
duplicate symbol 'thread-local initialization routine for CppAD::cg::CGOStreamFunc<double>::FUNC' in:
    bindings/python/CMakeFiles/pinocchio_pywrap_cppadcg.dir/spatial/expose-symmetric3.cpp.o
    bindings/python/CMakeFiles/pinocchio_pywrap_cppadcg.dir/algorithm/expose-constrained-dynamics.cpp.o
duplicate symbol 'thread-local initialization routine for CppAD::cg::CGOStreamFunc<double>::FUNC' in:
    bindings/python/CMakeFiles/pinocchio_pywrap_cppadcg.dir/spatial/expose-symmetric3.cpp.o
    bindings/python/CMakeFiles/pinocchio_pywrap_cppadcg.dir/multibody/expose-frame.cpp.o

I don't really know how to manage this issue…

[jorisv]

pinocchio::python::buildModel should never be build in bindings as show in #2474

We must wait #2475 to be merged to merge this one.