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 844b316 solved it on my 32bit-ish raspbian image. Nice work, Thanks!
(I take the freedom to close the issue now. ;-)