So your program is failing when the constructor of your base class, quad_controller_base::QuadController gets called on instantiation of the derived class that you've dynamically loaded. It sounds like it's failing because this constructor is defined in the .so instead of the executable, and linking across that boundary is causing a problem.
Regardless of the above issue, I don't think this is what you want to be doing. Assuming you're trying to make it so that you can dynamically load different quadcopter controllers via pluginlib, a good pattern is to make this interface (base class) defined in a header file so that dependencies can use it. Then they dynamically load derived classes via pluginlib.
This way, someone else can implement their own controller from quad_controller_base and define it in their own plugin, and dynamically load that as well. If you defined the base class constructor in this library, then the user-defined controllers wouldn't really be "peers" with the default controllers that you provide in your package.
Consider the following scenario:
- Someone builds a controller manager for quadcopters
- This depends only on quad_controller_base.h
- One person's application wants to use the controller manager with your default controllers
- This depends on: libquad_controller_manager.so,
- This loads libquad_controllers.so at runtime via pluginlib
- Another person's application wants to use the controller manager with additional controllers
- This depends on: libquad_controller_manager.so,
- This loads libquad_controllers.so at runtime via pluginlib
- This loads libmy_sweet_controller.so at runtime via pluginlib
This way, none of these different programs need to know anything except the interface at compile time, and then they can load whatever collection of controllers that are defined at runtime. This is compared to achieving the same behavior only with static linking, whereby the controller manager would need to be dependent on the packages that contain your default controllers AND my sweet controller. @tfoote likes to refer to it as "flipping the dependency tree."
Hope this helps.
What does your CMakeLists.txt look like?
The only line relevant to the plug-in would be
rosbuild_add_library(quad_controllers src/quad_controllers_plugins.cpp)
Note that my base class function definitions were in src/quad_controllers_base.cpp but are now in include/quad_control/src/quad_controllers_base.h per the above.