Closed ibadr closed 7 years ago
+1. urdfdom probably needs the same fix
It looks like this fix could needed throughout all ROS projects that link against console_bridge. So far, I got the following errors while statically linking rosbag_storage, cpp_common, and tf2 in a MEX project:
Error using mex
Creating library rosbag_wrapper.lib and object rosbag_wrapper.exp
tf2.lib(buffer_core.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl
console_bridge::log_deprecated(char const *,int,enum console_bridge::LogLevel,char const *,...)"
(__imp_?log_deprecated@console_bridge@@YAXPEBDHW4LogLevel@1@0ZZ)
rosbag_storage.lib(bag.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl
console_bridge::log_deprecated(char const *,int,enum console_bridge::LogLevel,char const *,...)"
(__imp_?log_deprecated@console_bridge@@YAXPEBDHW4LogLevel@1@0ZZ)
rosbag_storage.lib(bz2_stream.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl
console_bridge::log_deprecated(char const *,int,enum console_bridge::LogLevel,char const *,...)"
(__imp_?log_deprecated@console_bridge@@YAXPEBDHW4LogLevel@1@0ZZ)
rosbag_storage.lib(lz4_stream.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl
console_bridge::log_deprecated(char const *,int,enum console_bridge::LogLevel,char const *,...)"
(__imp_?log_deprecated@console_bridge@@YAXPEBDHW4LogLevel@1@0ZZ)
cpp_common.lib(header.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl
console_bridge::log_deprecated(char const *,int,enum console_bridge::LogLevel,char const *,...)"
(__imp_?log_deprecated@console_bridge@@YAXPEBDHW4LogLevel@1@0ZZ)
rosbag_wrapper.mexw64 : fatal error LNK1120: 1 unresolved externals
I think what is going on here is that, because CONSOLE_BRIDGE_STATIC
is not defined in the CMakeLists.txt
of these projects, the included console_bridge/exportdecl.h
via console_bridge/console.h
defines CONSOLE_BRIDGE_DLLAPI
to be CONSOLE_BRIDGE_DLLIMPORT
, where the latter is defined as __declspec(dllimport)
on Windows.
The fix --at least conceptually-- is still the same. However, it needs to be applied to CMakeLists.txt
in all ROS projects that depend on console_bridge. (Or maybe implement the fix in catkin?)
EDIT:
I can confirm this. I implemented the same fix in CMakeLists.txt
of rosbag_storage, cpp_common, and tf2, and all the linker errors disappeared, and the MATLAB MEX file is compiling fine.
Building with 'Microsoft Visual C++ 2013 Professional'.
MEX completed successfully.
@jacquelinekay who from the ROS team could review this?
I know that this is a old PR, but given that I am fighting quite a bit with this kind of issues while working on vcpkg
ports, I think I can comment on this.
The fix --at least conceptually-- is still the same. However, it needs to be applied to CMakeLists.txt in all ROS projects that depend on console_bridge. (Or maybe implement the fix in catkin?)
This is not scalable, even because it is totally legitimate to link a shared library to a "static" console_bridge
. What is necessary is that console_bridge
in some way exports this option to the consumer projects.
One possible way is to use some CMake
machinary such as exporting a console_bridge_FLAGS
or a defining a PUBLIC
option in target_compile_options
, but I found this quite error prone because it would not work for all users of console_bridge
that do not use CMake.
In my little experience the most robust solution is to generate (at configure time) an header (tipically called <package>-config.h
or a similar name) that defines or not CONSOLE_BRIDGE_STATIC
depending on the BUILD_SHARED_LIBS
option. This can be done by using the GenerateExportHeader
CMake module.
An alternative solution for simple cases such as this one is to keep two headers in the source tree (one defining CONSOLE_BRIDGE_STATIC
and the other not), and include and install one or another depending on BUILD_SHARED_LIBS
. An example of this easier solution can be found in the freeimage
port in vcpkg
: https://github.com/Microsoft/vcpkg/blob/5bd036cf5a70e18c451cc5aa9d041c530bf7adf1/ports/freeimage/CMakeLists.txt#L97 .
In my little experience the most robust solution is to generate (at configure time) an header (tipically called
-config.h or a similar name) that defines or not CONSOLE_BRIDGE_STATIC depending on the BUILD_SHARED_LIBS option. This can be done by using the GenerateExportHeader CMake module.
In #43
Is this needed anymore since #43 was merged?
I'm going to close this since I think it is not needed since #43 was merged. Please re-open if that is not the case.
Currently, compiling as a static library by setting
BUILD_SHARED_LIBS=OFF
fails on Windows, and the reason is thatCONSOLE_BRIDGE_STATIC
is not defined as it's supposed to in that case. A simple fix is included here.The log for the build failure is below