<div dir="ltr">I have noticed that neon support for the converter is not enabling. The CMakeError.log has this output. I am not certain as I am not really familiar with ARM and NEON, but I checked my CPU and it does support it. Also, the error message below is saying it is just a matter of passing certain flags.<div><br></div><div><div><font face="monospace, monospace">/mnt/extra/usr/lib/gcc/arm-linux-gnueabihf/4.8/include/arm_neon.h:32:2: error: #error You must enable NEON instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h</font></div><div><font face="monospace, monospace"> #error You must enable NEON instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h</font></div></div><div><font face="monospace, monospace"><br></font></div><div><font face="arial, helvetica, sans-serif">Normally, I would just fix it myself and move forward, but me and CMake mix like oil and water. It is kind of embarrassing but I swear it never does what I want it do - such as adding a darn flag. I even tried to force the options, lol, and all be danged if CMake finds some way to error. </font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Will work on this tomorrow, but if anyone has a solution I am all ears. If not then no problem and I will reply when I figure it out.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">This came about when I noticed what really seemed like abnormally high CPU usage on my ARM code for a simple shuffling of data out of the network packets. I traced what I felt like was the biggest possible hot spot to the converter routine. Anyway, that is my plan right now, to see if NEON might help if the converter is having to swap byte order.</font></div></div>