Changes between Version 11 and Version 12 of Guidelines/VxWorks

Timestamp:

May 2, 2013, 1:16:51 PM (9 years ago)

Author:

Peter Brockamp

Comment:

--

Guidelines/VxWorks

@@ -61 +61 @@
 * Other real time OSes (e. g. QNX) ''may'' be prone to the problem as well, depending on the defaults used. Consult your OS' documentation to gain clarity about this.
 * Here's another useful piece of information concerning VxWorks' POSIX-functionality in general:[[BR]] At the time a task calls it's first POSIX-function during runtime it is being transformed by VxWorks into a POSIX-thread. This transformation does include a call to {{{malloc()}}} to allocate the memory required for the housekeeping of POSIX-threads. In a high priority RTP this {{{malloc()}}} call may be highly undesirable, as its timing is more or less unpredictable (depending on what your actual heap looks like). You can circumvent this problem by calling the function {{{thread_self()}}} at a well defined point in the code of the task, e.g. shortly after the task spawns up. Thereby you are able to define the time when the task-transformation will take place and you could shift it to an uncritical point where a {{{malloc()}}} call is tolerable. So, if this could pose a problem for your code, remember to call {{{thread_self()}}} from the affected task at an early stage. Calling {{{thread_self()}}} to initiate the transformation is BTW an official recommendation by Wind River.
-* Building Boost for VxWorks is not quite an easy task! At least I couldn't find out how to use bjam to do it. I'll save you the technical details, but it would be neccessary to make bjam call VxWorks' compiler (a patched, renamed GCC or the diab-compiler) inside of the VxWorks Development Shell (a special shell with lot's of environmental variables set). You can circumvent this for the time being by having the workbench build Boost itself.  Below you will find for your convenience the {{{.wrproject}}}-file I use for Boost V1.53.
-  1. Create a Workbench project for your Boost directory and copy this content to a text file called {{{.wrproject}}}, replacing the file automatically generated by the workbench.
+* Building Boost for VxWorks is not quite an easy task! At least I couldn't find out how to use bjam to do it (any skilled volunteers here?). I'll save you the technical details, but it would be neccessary to make bjam call VxWorks' compiler (a patched, renamed GCC or the diab-compiler) inside of the VxWorks Development Shell (a special shell with lot's of environmental variables set). You can circumvent this for the time being by having the Workbench build Boost itself.  Below you will find for your convenience the {{{.wrproject}}}-file I use for Boost V1.53.
+  1. Create a Workbench project for your Boost directory, pulling in everything below and including your Boost root directory, and copy this content to a text file called {{{.wrproject}}}, replacing the file automatically generated by the Workbench.
   2. Adapt to your personal needs.
   3. Static linking Boost to your project will be OK, though I haven't tested dynamic linking.
-  4. I use environment variables to announce the local directories for Boost and other libraries I regularly use. These are called {{{BOOST_ROOT}}}, {{{BZIP2_ROOT}}}, {{{ZLIB_ROOT}}} etc. Create this system variables appropriately or use your own hardcoded paths (Change the include settings of your project).
+  4. I use environment variables to announce the local directories for Boost and other libraries I regularly use. These are called {{{BOOST_ROOT}}}, {{{BZIP2_ROOT}}}, {{{ZLIB_ROOT}}} etc. Create this system variables appropriately or use your own hardcoded paths (Change the include settings of your project). An important hint: The Wind River Workbench requires you to use //forward-slashes// in the environment variables you use for the paths even on Windows. Luckily MS Visual Studio will be fine with forward-slashes, too, so this is not a show stopper when doing a cross compilation for different target platforms.
   5. The file below is for the GCC compiler, as I don't use the diab-compiler, and for x86 as a platform. For other settings you are on your own.
+  6. My {{{.wrproject}}}-file uses the addon zlib- and bzip2-Library (for boost:iostreams). On the contrary, actually I do not use ICU. If your project settings are different you will have to change the settings in the file. This will be solely the addition or removal of some file or directory exclusions, so it shouldn't be too difficult.
+  7. Check your project's compiler flags. I use quite a couple of additional warnings switched on, this tracked me onto a couple of hidden software bugs, unrecognized before. if this is not your style, change these settings according to your needs.
 
   No warranty whatsoever!