-
Notifications
You must be signed in to change notification settings - Fork 375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Supported compilers, architectures, language versions #494
Comments
My primary use is on a non-Linux system using the IAR compiler. It isn't practical to add my environment as supported, but I would not like to see any gcc/clang extensions used or Linux assumed outside of the examples. I would like for this to continue to be usable on constrained devices where running Linux isn't possible or practical. |
My primary use is also on a non Linux system. On the embedded devices i think we run it with free rtos or bara bone on the mcu and then we also run it as a server as a library on iOS. I think there is also some (non linux) desktop use for testing as well. |
Which architecture? ARM? Something with less than 32 bits?
Regarding the extensions: How about adding a build configuration to CI which builds the "library" parts using -Wpedantic and "-Werror"? |
I'm currently using an Arm Cortex-M3 based system, so 32-bit. A CI build of the library parts with -Wpedantic and -Werror would probably be helpful. I'm currently using an RTOS, but would like to see it continue to be possible to use it without an OS. As an example, adding mutexes (provided by the implementer) for thread safety would be OK, but requiring multiple threads would not. The mutex functions could then do nothing in a no-OS environment. |
PR #575 will ensure Wakaama can be built with C99 (and C11) as well as keeping GNU specific compiler extensions out of the code base. |
Signed-off-by: Reto Schneider <[email protected]>
Ubuntu 20.04 supports neither mipsel and armel, therefore trying to use images based on Debian, which does. Signed-off-by: Reto Schneider <[email protected]>
…l architecture
Signed-off-by: Reto Schneider <[email protected]>
Most of this is a workaround for the fact that... - Ubuntu 20.04 does not support ARMv6 - CMake versions before 3.19 are affected by https://gitlab.kitware.com/cmake/cmake/-/issues/20568 Support for more architectures can be added once this is resolved: balena-io-library/resin-rpi-raspbian#104 Signed-off-by: Reto Schneider <[email protected]>
Most of this is a workaround for the fact that... - Ubuntu 20.04 does not support ARMv6 - CMake versions before 3.19 are affected by https://gitlab.kitware.com/cmake/cmake/-/issues/20568 Support for more architectures can be added once this is resolved: balena-io-library/resin-rpi-raspbian#104 Signed-off-by: Reto Schneider <[email protected]>
Most of this is a workaround for the fact that... - Ubuntu 20.04 does not support ARMv6 - CMake versions before 3.19 are affected by https://gitlab.kitware.com/cmake/cmake/-/issues/20568 Support for more architectures can be added once this is resolved: balena-io-library/resin-rpi-raspbian#104 Signed-off-by: Reto Schneider <[email protected]>
…t on ARMv6 architecture
…and test on ARMv6 architecture
… Build and test on ARMv6 architecture
…] ci: Build and test on ARMv6 architecture
Most of this is a workaround for the fact that... - Ubuntu 20.04 does not support many architectures - CMake versions before 3.19 are affected by https://gitlab.kitware.com/cmake/cmake/-/issues/20568 Signed-off-by: Reto Schneider <[email protected]>
Most of this is a workaround for the fact that... - Ubuntu 20.04 does not support many architectures - CMake versions before 3.19 are affected by https://gitlab.kitware.com/cmake/cmake/-/issues/20568 Signed-off-by: Reto Schneider <[email protected]>
This is more complex than it should be because... - Ubuntu 20.04 does not support many architectures, Debian does (e.g. ARMv5, MIPSel) - CMake versions before 3.19 are affected by https://gitlab.kitware.com/cmake/cmake/-/issues/20568 Signed-off-by: Reto Schneider <[email protected]>
This also fixes the CMake build on big endian architectures. This is more complex than it should be because... - Ubuntu 20.04 does not support many architectures, Debian does (e.g. ARMv5, MIPSel) - CMake versions before 3.19 are affected by https://gitlab.kitware.com/cmake/cmake/-/issues/20568 Signed-off-by: Reto Schneider <[email protected]>
This also fixes the CMake build on big endian architectures. This is more complex than it should be because... - Ubuntu 20.04 does not support many architectures, Debian does (e.g. ARMv5, MIPSel) - CMake versions before 3.19 are affected by https://gitlab.kitware.com/cmake/cmake/-/issues/20568 Signed-off-by: Reto Schneider <[email protected]>
This also fixes the CMake build on big endian architectures. This is more complex than it should be because... - Ubuntu 20.04 does not support many architectures, Debian does (e.g. ARMv5, MIPSel) - CMake versions before 3.19 are affected by https://gitlab.kitware.com/cmake/cmake/-/issues/20568 Signed-off-by: Reto Schneider <[email protected]>
This also fixes the CMake build on big endian architectures. This is more complex than it should be because... - Ubuntu 20.04 does not support many architectures, Debian does (e.g. ARMv5, MIPSel) - CMake versions before 3.19 are affected by https://gitlab.kitware.com/cmake/cmake/-/issues/20568 Signed-off-by: Reto Schneider <[email protected]>
This also fixes the CMake build on big endian architectures and the unit tests on aarch64, s390x, ppc64le. This is more complex than it should be because... - Ubuntu 20.04 does not support many architectures, Debian does (e.g. ARMv5, MIPSel) - CMake versions before 3.19 are affected by https://gitlab.kitware.com/cmake/cmake/-/issues/20568 Signed-off-by: Reto Schneider <[email protected]>
…ltiple architectures
…t on multiple architectures
This also fixes the CMake build on big endian architectures and the unit tests on aarch64, s390x, ppc64le. This is more complex than it should be because... - Ubuntu 20.04 does not support many architectures, Debian does (e.g. ARMv5, MIPSel) - CMake versions before 3.19 are affected by https://gitlab.kitware.com/cmake/cmake/-/issues/20568 Signed-off-by: Reto Schneider <[email protected]>
A buffer filled with a float string followed by non-numeric data is a valid input. Signed-off-by: Reto Schneider <[email protected]>
Leveraging the C99 implementation strtod() simplifies and corrects the code, at the cost of one additional memory allocation. Some additional tests have been added to cover the corner cases. However, as we can not (yet) instrument lwm2m_malloc(), memory exhaustion is not tested. Signed-off-by: Reto Schneider <[email protected]>
Leveraging the C99 implementation strtod() simplifies and corrects the code, at the cost of one additional memory allocation. Some additional tests have been added to cover the corner cases. However, as we can not (yet) instrument lwm2m_malloc(), memory exhaustion is not tested. Signed-off-by: Reto Schneider <[email protected]>
Leveraging the C99 implementation strtod() simplifies and corrects the code, at the cost of one additional memory allocation. Some additional tests have been added to cover the corner cases. However, as we can not (yet) instrument lwm2m_malloc(), memory exhaustion is not tested. Signed-off-by: Reto Schneider <[email protected]>
Leveraging the C99 implementation strtod() simplifies and corrects the code, at the cost of one additional memory allocation. Some additional tests have been added to cover the corner cases. However, as we can not (yet) instrument lwm2m_malloc(), memory exhaustion is not tested. Signed-off-by: Reto Schneider <[email protected]>
@rettichschnidi @sbernard31 can we close this? |
From the points I wanted to address, just "C99/C11: Fully supported" and "x86_64 on Linux" have been fully implemented. Everything else is still open and/or implemented partially. Also, I'd like to have some kind of documentation about the decisions taken - having #586 would help with this. |
What should be the baseline platform we can safely rely on in Wakaama? I would assume we can use standard C functions (C99), but malloc and free are already wrapped in I understand that we don't want to rely on Unix-like operating systems, but what about POSIX? In #709 I want to use functions from Finally, if we want to support RTOS/freestanding C implementations we should include a representative example in the build pipeline to guarantee support. |
I could not find any documentation regarding targeted (supported) compilers/architectures/languages/etc. Did I miss something?
If not, my needs/proposal would be:
The text was updated successfully, but these errors were encountered: