Build error for NEON

[bchoineubility]

Hi,

I have a build error for NEON on aarch64, exact platform name is Jetson xavier.
I am using ogre-next-2.3.3 now for cross compiling on Yocto.

Error message is

OgreMain/include/Math/Array/NEON/Single/OgreMathlibNEON.h:604:67: error: cannot convert 'Ogre::ArrayReal' {aka 'float32x4_t'} to 'uint32x4_t'
|   604 |             fStep0 = vreinterpretq_f32_u32( vandq_u32( vtstq_u32( f, f ),
|       |                                                                   ^
|       |                                                                   |
|       |                                                                   Ogre::ArrayReal {aka float32x4_t}

BR,
Mark

[bchoineubility]

I pased this error by type casting but, another error is occurred.

OgreMain/include/Math/Array/NEON/Single/OgreBooleanMask.inl:61:16: error: 'vmovemaskq_u32' was not declared in this scope
|    61 |         return vmovemaskq_u32( mask );
|       |                ^~~~~~~~~~~~~~

vmovemaskq_u32 is defined OgreMain/include/Math/Array/NEON/Single/OgreMathlibNEON.h.

BR,
Mark

[darksylinc]

Hi!

There's little we can do on unsupported platforms (PRs are accepted if you wish to fix it).

vmovemaskq_u32 is defined OgreMain/include/Math/Array/NEON/Single/OgreMathlibNEON.h.

Indeed it is. Given that it says it cannot be found, either OgreMathlibNEON.h was not included, or (most likely) __OGRE_HAVE_NEON is not defined.

It is defined in OgrePlatform.h.
You should probably start there. You can purposely introduce a syntax error to debug why that macro is not being defined.

Apologies for the late reply.

[bchoineubility]

Hi,

I have patched this issue and build is fine for me now. I can not push for this change because I would have no access right for this repo.

So, I created a patch file and share it in here,

BR,
Mark

0001-Fixed-compile-error.patch

[robwoolley]

Hi @bchoineubility ,

I started trying to get gazebo and rviz2 to build in meta-ros and stumbled across your patch.

May I get your sign off to include the patch in meta-ros?

Thanks,
Rob

[robwoolley]

Hi @bchoineubility,

I was successful in getting both Ogre 1.12.12, Ogre-Next 2.2.0, and Ogre-Next 2.3.3 to build in my feature branch: ros/meta-ros#1140

It still needs some work and runtime testing before I can merge it. Any feedback you can provide is great.

For the benefit of the ogre-next folks and anyone stumbling across this issue:

• I had to stick to the older 2.2.0 for compatibility with rviz and gazebo.
• I had to set OGRE_SIMD_NEON to false, used a version of the patch Mark shared above, and backport commit 16e2bd3 to resolve a problem with sys/sysctl.h not being present.
• I did try backporting the defined(__aarch64__) changes to set __OGRE_HAVE_NEON for ARM 64. However, that didn't seem to make ogre-next 2.2.0 happy. So instead I opt'd to just disable OGRE_SIMD_NEON and re-enable for 2.3.3+.

Regards,
Rob

[bchoineubility]

Hi @bchoineubility ,

I started trying to get gazebo and rviz2 to build in meta-ros and stumbled across your patch.

May I get your sign off to include the patch in meta-ros?

Thanks, Rob

No problem thanks.

[darksylinc]

I'm looking into this issue and unfortunately the patch cannot be merged as is.

I suspect the reason behind these issues boil down to Clang vs GCC. Our main source of testing for ARM64 so far have been Android & iOS; and both use Clang for building for ARM.

Are there any guides on how to cross compile to the platforms you are targeting?

[robwoolley]

@darksylinc Thanks for picking this up. I think that sounds like a great idea. At the moment, the instructions I could give are automated, but would require building a lot of other source packages before it got to OGRE. I was planning on producing an SDK that would provide the libraries and the toolchain ready to go. I am hoping to have that done by May 23rd at the latest. I think that might be the easiest way to proceed.

I could potentially provide you with an SDK as a tarball to extract or a Docker container that you just needed to download and run. The binaries inside would likely be for Linux running on x86-64. Would that work for you?

[azeey]

@robwoolley , FYI Ogre 2.3.3 is now in Ubuntu Noble. The solution to the arm64 issue has been to disable OGRE_SIMD_NEON and OGRE_SIMD_SEE2 (see https://git.launchpad.net/ubuntu/+source/ogre-next/tree/debian/rules?h=ubuntu/noble-proposed#n8).

Gazebo Harmonic is going to be available from the packages.ros.org when Jazzy comes out. But arm64 is currently not supported due to this issue. I'm now working on applying this patch to https://github.com/gazebo-release/gz_ogre_next_vendor so it builds on arm64 on the ROS buildfarm.

[darksylinc]

Hi!

It doesn't need to be a full environment.

Usually it boils down to installing the right GCC and *.cmake toolchain file to indicate CMake how to use it.

Since the problem is at compiling time, it doesn't even need to link properly.

This is an example of a file I use to compile via mingw from Ubuntu when I want to test Windows:

# Sample toolchain file for building for Windows from an Ubuntu Linux system.
#
# Typical usage:
#    *) install cross compiler: `sudo apt-get install mingw-w64`
#    *) cd build
#    *) cmake -DCMAKE_TOOLCHAIN_FILE=~/mingw-w64-x86_64.cmake ..

set(CMAKE_SYSTEM_NAME Windows)
set(TOOLCHAIN_PREFIX x86_64-w64-mingw32)

# cross compilers to use for C, C++ and Fortran
set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}-gcc)
set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PREFIX}-g++)
set(CMAKE_Fortran_COMPILER ${TOOLCHAIN_PREFIX}-gfortran)
set(CMAKE_RC_COMPILER ${TOOLCHAIN_PREFIX}-windres)

# target environment on the build host system
set(CMAKE_FIND_ROOT_PATH /usr/${TOOLCHAIN_PREFIX})

# modify default behavior of FIND_XXX() commands
#set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
#set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
#set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)