compiling Flatbuffer on VxWorks 6.8

[Abhijit Bhopale]

Hi All,

I am looking for library for binary serialisation on VxWorks(C++). Currently using XML based serialisation and not happy with the performance. 

Trying to compile Flatbuffer on VxWorks 6.8(GNU 4.1.2 without C++11 but boost library can be used with limited features) . Invested whole day but no luck. 

Is there anyone having used this combination? anyone tried? if yes what was the experience? 

Please provide some insight. Any inputs, suggestions are welcome.

Thank You,

Abhijit

[Wouter van Oortmerssen]

I think lowest GCC we've ever tried to compile is 4.3.X, and we're trying to support at the level of 4.6.2.

I am not sure what features 4.1.2 is lacking.

Are you compiling from tip, since we recently made some changes to allow compiling on STLPort, which has no C++11 support. if you #define FLATBUFFERS_CPP98_STL before including anything FlatBuffers, this may help.

What kind of errors are you getting?

--
You received this message because you are subscribed to the Google Groups "FlatBuffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flatbuffers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Abhijit Bhopale]

Hi Wouter,

Thank you for addressing my query. Yes I am compiling it from tip and defined _STLPORT_VERSION. I am missing #include <type_traits> .

    

 error: type_traits: No such file or directory

 error: #error A C++11 compatible compiler with support for the auto typing is required for FlatBuffers.

 error: #error __cplusplus _MSC_VER __GNUC__ __GNUC_MINOR__ __GNUC_PATCHLEVEL__

 using typedef-name 'fpos_t' after 'struct'

Autogenerated Make file by windriver and generated Build log is attached.

 

[Wouter van Oortmerssen]

The #error can be fixed by changing the minimum required GCC in flatbuffers.h

Not sure why it is complaining about fpos_t, we don't use it, this seems to be a problem with the headers on your platform.

__builtin_bswap16 is apparently missing in your version of GCC. Are you on a big-endian platform? Does it have byte-swap intrinsics?

Looks like it might not support "auto" either.

As much as I hate to say it, you may be out of luck unless you can update the compiler on your platform. Fixing these issues may be too much work otherwise.

[mikkelfj]

On Wednesday, August 3, 2016 at 6:48:40 PM UTC+2, Wouter van Oortmerssen wrote:

As much as I hate to say it, you may be out of luck unless you can update the compiler on your platform. Fixing these issues may be too much work otherwise.

If it doesn't work out in C++, you might be able to get it to work with the C interface using the flatcc compiler - wrap headers with extern "C" since the generated headers do not expect to run in C++.

I has only been tested down to gcc 4.4, as you can see in the travis build on the ci-more branch where additional compilers are being tested:

https://github.com/dvidelabs/flatcc/blob/ci-more/.travis.yml

To go below that you probably need to engage the full portability layer with -D FLATCC_PORTABLE and possible manipulate a few flags in the CMake build, but in all likelyhood you should be able to get it to work without too much effort. People are testing flatcc on rather more exotic platforms.

[mikkelfj]

I should add, you only need the runtime library to match said compiler version, and you can include that with own custom makefile where it may be easier to manipulate compile time flags.

https://github.com/dvidelabs/flatcc#cross-compilation