CycloneDDS on Vxworks

[lanner17]

I build Cyclonedds on Windows and experimented with it somewhat, but would really like to experiment on Vxworks. It seems cyclonedds is known to work on VxWorks (cyclonedds on vxworks). Since I am not a CMake expert yet, I was wondering if there is some notes on how to cross compile for Vxworks ? Do I need a CMake tool chain file, etc ?

[eboasson]

Welcome to the club of the non-CMake-experts. I know it usually involves toolchain files, but I can't tell you what to put in them. There are some people watching this repo that do know so hopefully one of them will chime in.

I expect that apart from the cross-compiling in general, you'll encounter some issues: that always happens when something doesn't get tested regularly. Also, it used to be that VxWorks had two modes, application code running in kernel mode, and a more normal mode where there are application processes running at a lower privilege level — "RTP"s IIRC. It should work in this "RTP" mode, the other mode (if it still exists) will probably give you some additional headaches.

Anyway, if you're happy to experiment a bit and try things out, I'm more than happy to help sort out any issues you may encounter.

[lanner17]

Ok, thanks for the offer. We run VxWorks in kernel mode - it still exists in Vxworks6.8. Vxworks7 may have removed it in favor of RTP's.

[eboasson]

We run VxWorks in kernel mode

IIRC from a long time ago, in kernel mode you need to use a very different set of functions to get things done. That means it is probably necessary to port the ddsrt layer. A port to FreeRTOS is available, and that's definitely a much more limited platform than VxWorks, and even that wasn't too difficult. I think it can be done without a significant effort, so I'd say it is worth a look.

[thijsmie]

While I have zero experience with VxWorks or other embedded development I can comment on the cmake cross-compiling part. For Cyclone DDS this is a two step process: you need the ddsconf executable for bootstrapping and while crosscompiling you can't run the executable from the non-native platform. Therefore you start by building Cyclone DDS as normal with the same option set as your target platform (e.g. ENABLE_SECURITY, ENABLE_TOPIC_DISCOVERY, etc). Make sure ddsconf is on your PATH and you can then continue with the cross-compiling build.

For me it was helpful to look at the cmake toolchain file purely as avoiding having to pass tons of options on the command line to cmake. This is because you will need to hardcode which compiler you want to use, what linker, where to find libraries to link against etc. If you think about it that makes sense: cmake's normal job is to look around your system to find the things it needs to compile and run the code, but when cross-compiling you want the final product to be independent of the system you ran the build on. It can purely depend on what you explicitly told cmake will be available on the target platform.

A quick google gave this example for a vxworks toolchain file. I don't know how good it is but it might be a good start to show what is actually needed.

[lanner17]

I am still trying to get familiar with the functionality of ddsconf. The link and pointers are helpful. Thanks.

[k0ekk0ek]

Hi @lanner17! At some point in time Cyclone's predecessor was known to work on VxWorks. Both KMS and RTP. I believe KMS is still offered in VxWorks 7 btw. And from what I can recall, VxWorks 7 and higher provide a CMake toolchain file. I left most VxWorks code in while writing the abstraction layer in Cyclone for future use, but a lot happened since then, so YMMV. Making it work shouldn't be that much work though since VxWorks provides the POSIX api for the most part.

Both @eboasson and @thijsmie are right. You need to provide a toolchain file for cross compilation. Basically what you put in that file are three things, the location of the headers, the location of the libraries and the location of the tools. The cmake-toolchains document provides a great resource. Some care should be taken when specifying CMAKE_FIND_ROOT_PATH_MODE_PROGRAM, because as @thijsmie correctly stated, you need ddsconf. So, before you try to cross compile, do a host build so you have a native version of ddsconf and make sure it's location is in your PATH environment variable. Then make sure your PATH is searched by specifying either BOTH or NEVER.

I'm very interested in whether or not you get it work. If you run into problems, please let us know. Happy to help you out.

[lanner17]

Hi @k0ekk0ek, on my first reading of the code I noticed that the VxWorks port makes use of POSIX instead of the "native" vxWorks API. So I assumed there was a previous effort to make it run on VxWorks. That is good, it confirms my assumption about the POSIX. Thanks for the pointers on cross compilation - really helpful. I will let you know how it turns out, but do not expect action soon as this is a side project for now.

[lanner17]

I work on this project when time is available, but have not been successful to cross compile yet. Just this week I had time to work on this again. However I noticed that ddsconf has since been removed (about 4 weeks ago). Did _confgen replace ddsconf and is it still needed for cross compilation as suggested in the previous discussion ? _confgen also does not seem to build by default - is there a way to enable the native build ?

[thijsmie]

Hi @lanner17,

ddsconf has been a little bit of a thorn in our sides, as it complicates the build process while really it just generates a file with default config values. The file with default config values is now checked into the repository and only regenerated when its dependencies change, powered by a little cmake dance.

So if you do not need the IDL compiler during the CycloneDDS target build (e.g. you do not build the examples or ddsperf) you will not need a native CycloneDDS build at all!

Hope this helps!

[lanner17]

Hi @thijsmie This helps, thanks for the clarification

[TDylse]

I'm also trying build cycloneDDS for Vxworks (specifically with LLVM for arm64). I'm currently stuck at the linking phase. My current error is:

relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `__argv' which may bind externally can not be used when making a shared object; recompile with -fPIC; dangerous relocation: unsupported relocation

relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `environ' which may bind externally can not be used when making a shared object; recompile with -fPIC; dangerous relocation: unsupported relocation

I'm building this as CMake RTP project, and had to add "-Bsymbolic" to get pass other PIC related errors. I have double checked that flags such -shared, -fPIC, -Bsymbolic are being past in.

I have been able to link against the VxWorks Sim BSP (which uses the host environment), so it appears to be specific to AARCH64.

Are there any suggestions?