compilation error in utils

[bishibashiB]

Required information

Operating system: Ubuntu 16.04.6 LTS (as per ubiquity robotics image compiled on raspberryPi 3b)

Compiler version: GCC 7.4.0 (for arm ->raspi)

Observed result or behaviour: allocator.cpp:44:75: error: no matching function for call to ‘align(uintptr_t&, const uint64_t&)’ uintptr_t l_alignedPosition = cxx::align(l_currentAddress, f_alignment); --> template class has only a shared parameter type for both parameters of cxx::align. Add a second template type or make second parameter (alignment) a static type e.g. uint64_t.

Expected result or behaviour: Does compile.

Conditions where it occurred / Performed steps: Using ubiquity robotics image compiled on raspberryPi 3b additional to install instruction added GCC v7 as default. (Compilation did finish after changing cxx::align 2nd parameter type (in helplets.hpp) to static type uint64_t.)

[budrus]

Thanks @Jekyll555 . Funny that this is no problem with gcc 7.4 on Intel. We also have ARM targets in our build pipeline but maybe not the combination ARM and gcc 7.4

[dkroenke]

Hi @Jekyll555 i can confirm this issue when i try to compile iceoryx on Raspbian with a Raspberry Pi 3B. The reason for that is that Raspbian is based on 32-Bit but the hardware processor has 64-bit. The 32-bit GCC compiler can then not handle the alignment for the different datatypes.

I guess that the ubiquity robotics image is also based on 32-Bit. You can check that with uname -a on which platform the operating system is based. If it is "armv7" then it is 32 Bit.

I created already an internal proposal how to fix that issue. I need to review it with my colleague and would then create a Pull-Request with you as reviewer.

[bishibashiB]

HI @dkroenke Confirming the raspbian being 32bit image: Linux ubiquityrobot 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l armv7l armv7l GNU/Linux Go ahead, I will be available for e.g. retesting...

[praveenjosephg]

I also faced this issue with Ubuntu mate 18.04 on raspberry pi 3 b+

[budrus]

Hi @praveenjosephg.

There is a 32-bit armhf and a 64-bit arm64 image. I guess you are using the armhf image. The arm64 image worked for me after reducing the memory pool and some other configuration to reasonable sizes on this machine.

I changed in https://github.com/eclipse/iceoryx/blob/cf746a71fb5339d23c3427360da321be380da8e2/iceoryx_posh/include/iceoryx_posh/iceoryx_posh_types.hpp#L41

MAX_PORT_NUMBER: 256 MAX_INTERFACE_NUMBER: 2 MAX_RECEIVERS_PER_SENDER: 32 MAX_SAMPLE_ALLOCATE_PER_SENDER: 1
MAX_SENDER_SAMPLE_HISTORY_CAPACITY: 1 MAX_RECEIVER_QUEUE_CAPACITY: 16 MAX_PROCESS_NUMBER: 16 MAX_RUNNABLE_NUMBER: 64

and you should adapt https://github.com/eclipse/iceoryx/blob/cf746a71fb5339d23c3427360da321be380da8e2/iceoryx_posh/source/mepoo/mepoo_config.cpp#L44

e.g. to this or whatever your needs are (Will be more convenient soon with #13 m_mempoolConfig.push_back({32, 10000}); m_mempoolConfig.push_back({128, 10000}); m_mempoolConfig.push_back({1024, 2000}); m_mempoolConfig.push_back({1024 16, 500}); m_mempoolConfig.push_back({1024 128, 200}); m_mempoolConfig.push_back({1024 1024, 20}); return this;

Btw. there are rumors saying that @elfenpiff is working on the 32-bit support.

[elfenpiff]

@michael-poehnl you are right 32-bit support is on its way and hopefully available at the end of this week!

[elBoberido]

@elfenpiff, can this issue be closed?

[dkroenke]

Hi, please wait until @Jekyll555 can confirm that he can compile it for his setup before you close this issue.

[elfenpiff]

@elBoberido from my perspective we could close this issue

[bishibashiB]

@dkroenke @elfenpiff Don't bother me. But: confirm 844b316aa55b57ab92c8e1fd4b7c4a9423014850 solved it on my 32bit-ish raspbian image. Nice work, Thanks! (I take the freedom to close the issue now. ;-)