search

tocinc / rmw_coredx

CoreDX DDS integration layer for ROS2
Apache License 2.0
0 stars 6 forks source link

Windows support #4

Closed SecretaryBirds closed 7 years ago

SecretaryBirds commented 7 years ago

There are some Linux-specific time function calls that prohibit operability on Windows and potentially OSX. (I'm not sure on OSX since I didn't test it.)

struct timespec now;
clock_gettime(CLOCK_REALTIME, &now);

stl has a good time library which should provide a bit more os-independence. It's the std::chrono library.

SecretaryBirds commented 7 years ago

so the clock_gettime is peppered throughout the functions.hpp, but they are all captured in #ifdef DEBUG statements. There is one instance of clock_gettime in the functions.cpp, but it doesn't seem to have any purpose.

ClarkTucker commented 7 years ago

Yep, it looks like the clock_gettime() call in functions.cpp was dangling debug code... safe to remove. I've pushed a fix for that.

We still haven't set up a Windows build env for ROS2 yet, so we're happy to hear about any Windows build issues you find [or any others, for that matter].

SecretaryBirds commented 7 years ago

Currently getting a new error on linking.

"C:\Asi\master\ros2\build\rmw_coredx_cpp\rmw_coredx_cpp.sln" (default target) (1) -> "C:\Asi\master\ros2\build\rmw_coredx_cpp\rmw_coredx_cpp.vcxproj.metaproj" (default target) (3) -> "C:\Asi\master\ros2\build\rmw_coredx_cpp\rmw_coredx_cpp.vcxproj" (default target) (5) -> (Link target) -> functions.obj : error LNK2019: unresolved external symbol "class DDS::DomainParticipantQos const DDS::PARTICIPANT_QOS_DEFAULT" (?PARTICIPANT_QOS_DEFAULT@DDS@@3VDomainParticipantQos@1@B) referenced in function "struct rmw_node_t

SecretaryBirds commented 7 years ago

I am using a new build of 4.0.13 built for VS 2015, but it still isn't linking properly. I'm not sure what's going on.

Are those things defined in either of these libraries?

C:\Asi\coredx-4.0.13\scripts\..\target\Windows_x86_64_vs2015\lib\dds_cpp_cf.lib
C:\Asi\coredx-4.0.13\scripts\..\target\Windows_x86_64_vs2015\lib\dds_cf.lib

Those are the only CoreDX libs I can see being added to the VS project when compiling rmw_coredx_cpp.

ClarkTucker commented 7 years ago

Are you able to share the full link command? Are you linking with CoreDX DDS libraries statically or dynamically? To support dynamic linking (eg, against a DLL), you'll need to, at least, add /DCOREDX_DLL to the compile lines. And, that may not be sufficient: for example, if the generated typesupport code is linked into a DLL, then it will need some special compile flags as well.

I'm not sure this is the source of your errors, but it could be. I'll be able to verify once we have a Windows build env set up for ROS.

SecretaryBirds commented 7 years ago

Yes, I believe ROS2 tries to dynamically link everything by default.

SecretaryBirds commented 7 years ago

Manually adding /DCOREDX to the compile line in the .sln file made it compile successfully. So adding it to the Cmake file for windows VS solution files might be the way to go? Thoughts?

add_definitions(/DCOREDX_DLL)
SecretaryBirds commented 7 years ago

Run into another issue on the 'builtin_interfaces' package. When attempting to perform the idl generation, it was throwing an error

coredx_cpp is an unrecognized command

So I added COREDX_TOP\host\COREDX_HOST\bin to PATH and I got past that issue.

But now it is failing to link when compiling the 'example_interfaces' package. It's another linking issue, which I'm not sure how to address.

Link: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\link.exe /ERRORREPORT:QUEUE /OUT:"C:\Asi\master\ros2\build\example_interfaces\Release\example_interfaces__rosidl_typesupport_coredx_cpp.dll" /INCREMENTAL:NO /NOLO GO /LIBPATH:"C:/Asi/coredx-4.0.13/scripts/../target/Windows_x86_64_vs2015/lib" /LIBPATH:"C:/Asi/coredx-4.0.13/scripts/../target/Windows_x86_64_vs2015/lib/Release" kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32 .lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib "C:\Asi\coredx-4.0.13\scripts\..\target\Windows_x86_64_vs2015\lib\dds_cpp_cf.lib" "C:\Asi\coredx-4.0.13\scripts\..\target\Windows_x86_64_vs2015\lib\dds_cf.lib" C:\Asi\master\ ros2\install\Lib\rmw.lib C:\Asi\master\ros2\install\Lib\rosidl_generator_c.lib C:\Asi\master\ros2\install\Lib\rosidl_typesupport_coredx_cpp.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /PDB:"C :/Asi/master/ros2/build/example_interfaces/Release/example_interfaces__rosidl_typesupport_coredx_cpp.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:/Asi/master/ros2/build/example_interfaces/Release/example_i nterfaces__rosidl_typesupport_coredx_cpp.lib" /MACHINE:X64 /machine:x64 /DLL example_interfaces__rosidl_typesupport_coredx_cpp.dir\Release\add_two_ints__type_support.obj example_interfaces__rosidl_typesupport_coredx_cpp.dir\Release\add_two_ints__request__type_support.obj example_interfaces__rosidl_typesupport_coredx_cpp.dir\Release\add_two_ints__response__type_support.obj example_interfaces__rosidl_typesupport_coredx_cpp.dir\Release\AddTwoInts_Request_.obj example_interfaces__rosidl_typesupport_coredx_cpp.dir\Release\AddTwoInts_Request_DataReader.obj example_interfaces__rosidl_typesupport_coredx_cpp.dir\Release\AddTwoInts_Request_DataWriter.obj example_interfaces__rosidl_typesupport_coredx_cpp.dir\Release\AddTwoInts_Request_TypeSupport.obj example_interfaces__rosidl_typesupport_coredx_cpp.dir\Release\AddTwoInts_Response_.obj example_interfaces__rosidl_typesupport_coredx_cpp.dir\Release\AddTwoInts_Response_DataReader.obj example_interfaces__rosidl_typesupport_coredx_cpp.dir\Release\AddTwoInts_Response_DataWriter.obj example_interfaces__rosidl_typesupport_coredx_cpp.dir\Release\AddTwoInts_Response_TypeSupport.obj Creating library C:/Asi/master/ros2/build/example_interfaces/Release/example_interfaces__rosidl_typesupport_coredx_cpp.lib and object C:/Asi/master/ros2/build/example_interfaces/Release/example_interfaces__rosidl_typesupport _coredx_cpp.exp

add_two_ints__type_support.obj : error LNK2019: unresolved external symbol "public: __cdecl coredx::rpc::Requester::Requester(class DDS::rpc::RequesterParams const &,char const *,long (__cdecl*)(class DDS::DomainParticipant *,cha r const *),char const *,long (__cdecl*)(class DDS::DomainParticipant *,char const *),class DDS::rpc::ServiceProxy *)" (??0Requester@rpc@coredx@@QEAA@AEBVRequesterParams@1DDS@@PEBDP6AJPEAVDomainParticipant@4@1@Z13PEAVServiceProxy@ 14@@Z) referenced in function "public: __cdecl DDS::rpc::Requester<struct example_interfaces::srv::dds_::AddTwoInts_Request_,struct example_interfaces::srv::dds_::AddTwoInts_Response_>::Requester<struct example_interfaces::srv::d ds_::AddTwoInts_Request_,struct example_interfaces::srv::dds_::AddTwoInts_Response_>(class DDS::rpc::RequesterParams const &)" (??0?$Requester@UAddTwoInts_Request_@dds_@srv@example_interfaces@@UAddTwoInts_Response_@234@@rpc@DDS@@ QEAA@AEBVRequesterParams@12@@Z) [C:\Asi\master\ros2\build\example_interfaces\example_interfaces__rosidl_typesupport_coredx_cpp.vcxproj]

ClarkTucker commented 7 years ago

Yes, we're working on updating the cmake files to include the proper flags for Windows DLL creation and utilization. Also, we're looking into the failure to find coredx_cpp, it is probably something we can fix without requiring a manual modification to the env PATH, but that seems like a good workaround in the meantime. And finally, we've run into the same linking issue you just reported. Hope to have the repository fixed up for all those items in a day or two.

ClarkTucker commented 7 years ago

Sorry for the delay...

I've gotten a Windows build to run through to completion. The repository has been updated.... It also did require changes to the CoreDX DDS header files for RPC-over-DDS, so a new version of CoreDX DDS is required (v4.0.14, it is available on the TwinOaksComputing.com website).

SecretaryBirds commented 7 years ago

Awesome. Tried it today and it worked.

I still had to do this:

So I added COREDX_TOP\host\COREDX_HOST\bin to PATH and I got past that issue

but otherwise it went smoothly.

Have the changesets to the package.xml files for the rmw_* repos been submitted as pull requests?

nate-jackson commented 7 years ago

We built on windows yesterday and still have to set that PATH env var that SecretaryBirds referred to. Any chance this can be fixed?