Raspbian GNU/Linux support (armv7l/armhf 32-bit)

[SofoklisKat]

Raspbian GNU/Linux support (armv7l/armhf 32-bit)

[dsommers]

@M00N-MAN, thanks a lot for digging into this and testing it. Yes, it sounds plausible this can work - at least on 32-bit platforms. At the same time, the whole int/long complexity is a bit convoluted, so we need to test this thoroughly on all platforms.

[schwabe]

We do not build packages for it but self building it on Raspian should work. Note that we will provide images for Ubuntu on ARM64, which also runs on Raspian

[SofoklisKat]

Thanks for the quick response,

I tried to build it in the Rpi (armv7l architecture) with the following 2 methods but both failed.

When I build it in raspberry pi with the default Rasbian OS I receive the following error.

In file included from src/configmgr/configmgr.hpp:36,
from src/configmgr/openvpn3-service-configmgr.cpp:23:
./src/dbus/object-property.hpp:127:67: error: call of overloaded ‘GetVariantValue(GVariant*&)’ is ambiguous

When I build it in raspberry pi through an Ubuntu Armv7 Docker Image I receive the following error.

In file included from src/configmgr/configmgr.hpp:36:0,
from src/configmgr/openvpn3-service-configmgr.cpp:23:

./src/dbus/object-property.hpp:115:48: error: call of overloaded 'GetDBusDataType()' is ambiguous
? GLibUtils::GetDBusDataType()

Any thoughts ?

[dsommers]

Which compiler and which version of it do you use?

[schwabe]

@dsommers did we ever fix the compile on certain 32 bit architectures bug?

[dsommers]

@schwabe I believe we did, but from a quick glance this looks like a different issue, as it is triggered by a template in dbus/object-property.hpp this time. Last time it was related to different int size interpretations in glibutils.hpp

[dsommers]

With the v14_beta release, which is going out today, we do support arm64 platforms. The 32-bit platforms in general are currently not supported, and the armv7l architecture is a 32-bit platform.

[bibiefrat]

We do not build packages for it but self building it on Raspian should work. Note that we will provide images for Ubuntu on ARM64, which also runs on Raspian

could you please provide instruction to compile on odroid xu4 (arm 32 bit)?
thanks

[dsommers]

@bibiefart It's not that easy. We need a proper solution for handling integer data types in src/dbus/glibutils.hpp on 32 bit systems, which currently conflicts with 64 bit systems. First functions to get fixed is GLibUtils::GetDBusDataType() and GLibUtils::GetVariantValu(), but I suspect it is also needed to fix GlibUtils::ExtractValue().

[M00N-MAN]

Hi @schwabe and @dsommers,

why just not use

template<> inline const char* GetDBusDataType<int>()             {return "i";}
template<> inline const char* GetDBusDataType<long>()            {return "i";}
template<> inline int         GetVariantValue<int>(GVariant *v)  {return g_variant_get_int32(v);}
template<> inline long        GetVariantValue<long>(GVariant *v) {return g_variant_get_int32(v);}

???
with lines above the compilation on buster/rpi4 is ok:)
i just dunno which test covers this portion, please let me know (too new to openvpn3'rd version)

otherwise with these templates in glibutils.hpp gcc and clang are saying that GetDBusDataType(); and GetDBusDataType() are ambiguos... because it is obvious that GetDBusDataType<T/int or long/>() wont't be used as definition of this declaration template inline const char* GetDBusDataType(); because there should be template<> specialiation, but not another function.

same with GetVariantValue()

don't you think so?

please share the contr-cases to take attention to.

[TheReelDill]

Any plans to move this forward or is 32 bit dead for OpenVPN3?

[dsommers]

To be honest, in general 32 bit OSes is not high up on the priority list at all. In Linux 64-bit has had a huge focus the last 15+ years, and even embedded devices are now commonly on 64 bit architectures as well.

In addition, we are exploring an alternative D-Bus implementation to glib2 -which riddles us with various issues and challenges. The new alternative implementation will be a pure C++ implementation and not a C library wrapped into C++ classes. I suspect many of these issues might be better solved with the new implementation. However, we don't have any ETA for that yet. But it will get a lot more focus after the first stable version has been released (which is planned to be either v20 or v21, depending on issues found in the just released v19_beta).