Adding libcoap as a dependancy triggers a compile error (IEC-295)

[hani-n]

Answers checklist.

• I have read the component documentation ESP-IDF Components and the issue is not addressed there.
• I am using target and esp-idf version as defined in component's idf_component.yml
• I have searched the issue tracker for a similar issue and not found any related issue.

Which component are you using? If you choose Other, provide details in More Information.

coap

ESP-IDF version.

release/v5.4

Development Kit.

Custom board

Used Component version.

espressif/coap

More Information.

I am using esp-idf release/v5.4 to build an application that requires libcoap, added as a dependancy from idf.py add-dependancy coap
The compile fails with unkown name types for sockaddr_in struct memebers i.e

managed_components/espressif__coap/port/include/coap3/coap.h:29:5: error: unknown type name 'sa_family_t'
   29 |     sa_family_t     sin_family;

The issue seems to be related to the order in which port/include/coap3/coap.h declares variables/header files, more precisely the fact that structs are declared before header file inclusions. Declaring those structs afer header inclusions seems to resolve the issue.

[mahavirj]

CC @mrdeep1

[mrdeep1]

I'm unable to reproduce this issue. Have you enabled the LwIP stack?

It would be good to know what the file was that included coap.h. Was it one of your application files, or an internal libcoap build file?

However, I can see that in port/include/coap3/coap.h it includes coap3/libcoap.h which includes sys/socket.h which then includes lwip/sockets.h which is where sa_family_t is defined.

Please try making this change to see if things then work for you:

diff --git a/coap/port/include/coap3/coap.h b/coap/port/include/coap3/coap.h
index 59bf433..986a375 100644
--- a/coap/port/include/coap3/coap.h
+++ b/coap/port/include/coap3/coap.h
@@ -21,6 +21,8 @@
 extern "C" {
 #endif

+#include "coap3/libcoap.h"
+
 #if LWIP_IPV4
 #define COAP_IPV4_SUPPORT 1
 #else /* ! _LWIP_IPV4 */
@@ -48,8 +50,6 @@ struct sockaddr_in6 {
 #endif /* INET6_ADDRSTRLEN */
 #endif /* ! LWIP_IPV6 */

-#include "coap3/libcoap.h"
-
 #include "coap3/coap_forward_decls.h"
 #include "coap3/coap_address.h"
 #include "coap3/coap_async.h"

and revert back to us.

[hani-n]

@mrdeep1 This change does resolve the issue !

[mrdeep1]

That is great. As there are future plans to use the standard libcoap coap.h rather than the port version, it would be very helpful to know which file that included coap.h compile failed before you made the change - was it a libcoap file, or general esp-idf file or a file within your application code?

[hani-n]

It was a coap_handlers header file in the application code

[mrdeep1]

OK. If you include coap3/libcoap.h in your application code header file before coap3/coap.h, does that work instead of this alternative fix?

[hani-n]

It does not, I would also need to include coap_session_internal since I am using coap_session_t and other structs.
That being said, the initial compile issues remain.

[mrdeep1]

It does not

Interesting. The change you make in coap.h is to move libcoap.h up to the top of the file. So having libcoap.h just in front of coap.h in your application files should work as well.

You should not be needing to access coap_session_t directly. There are a lot of coap_session_get*() functions.

[hani-n]

Reasoning on why we are using it is that when we register handler via coap_register_handler,
the handler must have a function signature of (coap_resource_t *resource, coap_session_t *session, const coap_pdu_t *request, const coap_string_t *query, coap_pdu_t *response), hence the need for coap_session_t.

[mrdeep1]

The coap_session_t *session parameter is a pointer to an opaque structure, and there should be no compilation issues (other than perhaps an unused variable warning) providing you have defined '#include <coap.h>' prior to the function, or to any functions that pass in the function to internal libcoap code.

coap_session(3) provides a set of function definitions that can be used to access variables within the coap_session_t. A common usage here is coap_session_get_contex(3)()

[mahavirj]

Closing - assuming no change required on the managed component side. Please check the API usage as suggested above.