NI Linux Real-Time Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

cmake can't find sizes of integer types on ARM cRIO

Not sure how far this will fly, but I might as well try. I'm trying to rebuild an open-source project that I successfully built on my cRIO-9064 a few months ago. (Unfortunately I'm a moron and neglected to document the build procedure or keep an offsite copy of the .so file.) The project uses cmake, which is failing inexplicably while trying to configure. The output is attached; you'll see that it fails to find the size of several integer types, i.e.:

-- Check size of __int64

-- Check size of __int64 - failed

Does this mean I'm missing some dependency external to the repo? I can't for the life of me figure out why it wouldn't just work.

Here's the CMakeLists.txt section for int64 and int32 types. Nothing abnormal that I can see:

check_type_size (__int64 __INT64)

check_type_size (int64_t INT64_T)

check_type_size ("long long" LONG_LONG_INT)

# Check our 32 bit integer sizes

check_type_size (int32_t INT32_T)

check_type_size (__int32 __INT32)

check_type_size ("long" LONG_INT)

check_type_size ("int" INT)

if (HAVE_INT32_T)

   set (JSON_INT32 int32_t)

elseif (HAVE___INT32)

   set (JSON_INT32 __int32)

elseif (HAVE_LONG_INT AND (${LONG_INT} EQUAL 4))

   set (JSON_INT32 long)

elseif (HAVE_INT AND (${INT} EQUAL 4))

   set (JSON_INT32 int)

else ()

   message (FATAL_ERROR "Could not detect a valid 32-bit integer type")

endif ()

Anybody see this before on their cRIO? I sure hope I've just failed to install a package with some dependencies or something...

0 Kudos
Message 1 of 8
(5,048 Views)

Update: I tried building a different project and found the same problem, so it seems likely to be a problem with my cRIO environment and not the projects I'm building. The second project is https://github.com/featherweight/featherweight/tree/master/kernel which has explicit directions that I followed to the letter. (Anyone interested in my thread here can do the same if they like!)

0 Kudos
Message 2 of 8
(4,641 Views)

A couple of things that would be useful to know would be the version of the OS running on the cRIO as well as the steps that you took to setup the controller to build projects

0 Kudos
Message 3 of 8
(4,641 Views)

The controller is running the 3.5.0f0 "firmware" according to MAX.

I formatted it, enabled SSHD, and then followed the instructions on the featherweight README linked above. That used to be enough, as recently as April.

Edit: I also installed "NI CompactRIO 15.5 - February 2016" using MAX.

0 Kudos
Message 4 of 8
(4,641 Views)

Found it. CMakeLists.txt is correct and cmake works fine. The author of an upstream repository had accidentally checked some configure output files into his source tree, and I had accidentally referenced them in my own header files. When I relinked to the correctly generated outputs (for my platform), the errors disappeared.

Lesson: do out-of-source builds only and tell git to ignore those files.

0 Kudos
Message 5 of 8
(4,641 Views)

Staab_Engineering wrote:

Found it. CMakeLists.txt is correct and cmake works fine. The author of an upstream repository had accidentally checked some configure output files into his source tree, and I had accidentally referenced them in my own header files. When I relinked to the correctly generated outputs (for my platform), the errors disappeared.

Lesson: do out-of-source builds only and tell git to ignore those files.

Is that just for the wirebird labs featherweight stuff, or for the other (ominously) unnamed project?

0 Kudos
Message 6 of 8
(4,641 Views)

Both. The other is jansson, which featherweight pulls in as an upstream dependency. Sorry for the ambiguity.

0 Kudos
Message 7 of 8
(4,641 Views)

Solid. I'm glad that my lack of any useful assistance happened in close proximity to the problem being solved

Message 8 of 8
(4,641 Views)