lib/wolfssl_particle/src/asn.c
lib/wolfssl_particle/src/asn.c:220:18: error: conflicting types for 'time_t'
220 | typedef long time_t;
| ^~~~~~
In file included from /usr/local/gcc-arm-embedded/arm-none-eabi/include/sys/select.h:15,
from /usr/local/gcc-arm-embedded/arm-none-eabi/include/sys/types.h:68,
from /usr/local/gcc-arm-embedded/arm-none-eabi/include/stdio.h:61,
from lib/wolfssl_particle/src/wolfssl/wolfcrypt/wc_port.h:255,
from lib/wolfssl_particle/src/wolfssl/wolfcrypt/types.h:28,
from lib/wolfssl_particle/src/wolfssl/wolfcrypt/asn.h:26,
from lib/wolfssl_particle/src/asn.c:46:
/usr/local/gcc-arm-embedded/arm-none-eabi/include/sys/_timeval.h:40:18: note: previous declaration of 'time_t' was here
40 | typedef _TIME_T_ time_t;
| ^~~~~~
As it seems that library created its own type time_t but this now conflicts with a pre-existing declaration that comes with the GCC toolchain.
Unfortunately the original contributor of that library didn’t provide a link to the GitHub repo for that library in order to file an update request (to remove that type definition).
However, you can download the library and modify it as you see fit.
Thankyou for speedy reply ScruffR.
Unusual that wolfSSL didn’t provide a compatibility layer for particle since conflicts between gcc toolchain and wolfSSL are unlikely to be limited to
type definition time_t
I’ll do some digging, maybe contact wolfSSL, and post any helpful finding.
The point is that it may have built back then when the library was contributed (possibly not even by wolfSSL themselves) but since then the base library may have evolved with the toolchains but these upstream changes have not made it down into the Particle library repository. There is no auto-update feature for libraries that would pull in upstream changes.
Even if there was, since no GitHub repo is linked to that library how would the system know about any updates?
I felt the need to attend this webinar today … “wolfSSL webinar will provide attendees with the basics and best practices needed to get started using the wolfSSL TLS library in products and projects into 2021! Topics will include a brief overview of TLS 1.3, wolfSSL package structure, how to build wolfSSL, running the wolfCrypt cryptography test and benchmark applications, wolfSSL basic API usage, tips on debugging, and more! Bring your questions for the Q&A session to follow!”
I didn’t expect that I’d need to get into toolchains and Particle library that weren’t backwards compatible.
I don’t understand what you mean but maybe you aren’t experiencing wolfssl_particle 0.0.3…
let me say again and rephrasing with more detail…
include these two settings headers before the other wolfSSL includes
#include <options.h>
#include <settings.h>
moves compile errors from
lib/wolfssl_particle/src/asn.c
to
wolfssl_particle/src/internal.c
which is quite a way into the alphabetically listed and compiled wolfssl_particle 0.0.3 library.
Try to reread your own post without the context you personally have about your trials and errors
It shouldn't be required to recreate a mock-up project to replicate what you are seeing in order to understand what's said.
The fact that the error gets reported at different places is not surprising.
Since you change the order in which the compiler will build the individual modules it may catch the same error in different places, depending which file it looks at first - the compiler doesn't care about alphabetical order but rather hierarchical dependency.
The error doesn't move it's just seen in whichever place first and causes the build to terminate preventing the compiler from finding the other locations where that same error may still be hiding.
If you have a local copy of that library you can add this to ./lib/wolfssl_particle/src/wolfssl/wolfcrypt/settings.h
#define HAVE_TIME_T_TYPE
After that the project should build.
One confusing part of that library is that it uses HAVE_TIME_T_TYPE in some places but in others USE_WOLF_TIME_T and depending on either may redefine time_t.
Earlier version of Workbench on Linux was made unusable by me 4 months ago, web IDE is great for tiny projects, so rolling the dice with Workbench on Windows seemed like a good idea.
what I initially missed in setting up Application was “One confusing part of that library is that it uses HAVE_TIME_T_TYPE in some places but in others USE_WOLF_TIME_T and depending on either may redefine time_t.”
Expectation libraries in particle are akin to a contract - that’s a stretch and that’s okay - I surfed for decades and getting caught by a wave and thrashed is an expectation otherwise don’t go in the ocean.
No, Workbench on a powerful windows 10 box is accelerant – watching order of auto-pre-scan for compile errors. Long weekend here, in cruise mode away from possible covid-19 visitors.
Paraphrasing; “A man alone is easy prey. Only by standing together are you going to be able to beat the Lahood-sized complexities of this world."
So again, thankyou for super support - particle library isn’t moderated github library, yet.
