Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Build issues with mbed-os5.x over mbed-cli tool chain #1177

Closed
surajdagar opened this issue Sep 13, 2019 · 19 comments
Closed

Build issues with mbed-os5.x over mbed-cli tool chain #1177

surajdagar opened this issue Sep 13, 2019 · 19 comments
Assignees
@danewalton

Comments

@surajdagar
Copy link

Hey,
I am trying to build it with mbed-os 5, I am using mbed-cli to build this. I am getting below errors.

Compile [ 66.1%]: agenttime_mbed.c
[Error] strings.h@21,1: unknown type name 'MU_IF'
[Error] strings.h@22,1: unknown type name 'MU_IF'
[Error] strings.h@23,1: unknown type name 'MU_IF'
[Error] strings.h@24,1: unknown type name 'MU_IF'
[Error] strings.h@25,1: unknown type name 'MU_IF'
[Error] strings.h@26,1: unknown type name 'MU_IF'
[Error] strings.h@27,1: unknown type name 'MU_IF'
[Error] strings.h@28,1: unknown type name 'MU_IF'
[Error] strings.h@29,1: unknown type name 'MU_IF'
[Error] strings.h@30,1: unknown type name 'MU_IF'
[Error] strings.h@31,1: unknown type name 'MU_IF'
[Error] strings.h@32,1: unknown type name 'MU_IF'
[Error] strings.h@33,1: unknown type name 'MU_IF'
[Error] strings.h@34,1: unknown type name 'MU_IF'
[Error] strings.h@35,1: unknown type name 'MU_IF'
[Error] strings.h@36,1: unknown type name 'MU_IF'
[Error] strings.h@37,1: unknown type name 'MU_IF'
[Error] strings.h@38,1: unknown type name 'MU_IF'
[Error] strings.h@39,1: unknown type name 'MU_IF'
[ERROR] In file included from ./c-utility/inc/azure_c_shared_utility/strings.h:13:0,
from /usr/arm-none-eabi/include/string.h:24,
from ./deps/azure-macro-utils-c/inc/azure_macro_utils/macro_utils.h:17,
from ./deps/umock-c/inc/umock_c/umock_c_prod.h:4,
from ./c-utility/inc/azure_c_shared_utility/agenttime.h:16,
from ./c-utility/adapters/agenttime_mbed.c:4:
./c-utility/inc/azure_c_shared_utility/strings.h:21:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, STRING_HANDLE, STRING_new);
^
./c-utility/inc/azure_c_shared_utility/strings.h:22:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, STRING_HANDLE, STRING_clone, STRING_HANDLE, handle);
^
./c-utility/inc/azure_c_shared_utility/strings.h:23:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, STRING_HANDLE, STRING_construct, const char*, psz);
^
./c-utility/inc/azure_c_shared_utility/strings.h:24:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, STRING_HANDLE, STRING_construct_n, const char*, psz, size_t, n);
^
./c-utility/inc/azure_c_shared_utility/strings.h:25:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, STRING_HANDLE, STRING_new_with_memory, const char*, memory);
^
./c-utility/inc/azure_c_shared_utility/strings.h:26:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, STRING_HANDLE, STRING_new_quoted, const char*, source);
^
./c-utility/inc/azure_c_shared_utility/strings.h:27:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, STRING_HANDLE, STRING_new_JSON, const char*, source);
^
./c-utility/inc/azure_c_shared_utility/strings.h:28:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, STRING_HANDLE, STRING_from_byte_array, const unsigned char*, source, size_t, size);
^
./c-utility/inc/azure_c_shared_utility/strings.h:29:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, void, STRING_delete, STRING_HANDLE, handle);
^
./c-utility/inc/azure_c_shared_utility/strings.h:30:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, int, STRING_concat, STRING_HANDLE, handle, const char*, s2);
^
./c-utility/inc/azure_c_shared_utility/strings.h:31:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, int, STRING_concat_with_STRING, STRING_HANDLE, s1, STRING_HANDLE, s2);
^
./c-utility/inc/azure_c_shared_utility/strings.h:32:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, int, STRING_quote, STRING_HANDLE, handle);
^
./c-utility/inc/azure_c_shared_utility/strings.h:33:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, int, STRING_copy, STRING_HANDLE, s1, const char*, s2);
^
./c-utility/inc/azure_c_shared_utility/strings.h:34:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, int, STRING_copy_n, STRING_HANDLE, s1, const char*, s2, size_t, n);
^
./c-utility/inc/azure_c_shared_utility/strings.h:35:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, const char*, STRING_c_str, STRING_HANDLE, handle);
^
./c-utility/inc/azure_c_shared_utility/strings.h:36:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, int, STRING_empty, STRING_HANDLE, handle);
^
./c-utility/inc/azure_c_shared_utility/strings.h:37:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, size_t, STRING_length, STRING_HANDLE, handle);
^
./c-utility/inc/azure_c_shared_utility/strings.h:38:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, int, STRING_compare, STRING_HANDLE, s1, STRING_HANDLE, s2);
^
./c-utility/inc/azure_c_shared_utility/strings.h:39:1: error: unknown type name 'MU_IF'
MOCKABLE_FUNCTION(, int, STRING_replace, STRING_HANDLE, handle, char, target, char, replace);
@danewalton
Copy link
Member

Hi @surajdagar are you using the latest version of the sdk? If so can you make sure the submodules are updated using the following command from the top level of the sdk.
git submodule update --init --recursive

@danewalton danewalton self-assigned this Sep 13, 2019
@surajdagar
Copy link
Author

Hi @danewalton Yes, I am using the latest version of the SDK. Looks like my submodules are up to date too.

@danewalton
Copy link
Member

are you building from the command line? are you able to post the full command?

@surajdagar
Copy link
Author

Yes, I am building with command line - mbed compile -t GCC_ARM -m nRF52840_DK

@danewalton
Copy link
Member

The error leads me to believe that an include path isn't being passed to the build command? If you are on the latest sdk and submodules are updated that define should be here. The path from a cloned repo would be deps/azure-macro-utils-c/inc. Could you double check that?
You can also try using our mbed5 build scripts to try and mimic them? Let me know if any of that helps.

@surajdagar
Copy link
Author

Hi @danewalton yes, I have "macro_utils.h" available on this path. You can reproduce it by downloading blinky from https://github.com/ARMmbed/mbed-os-example-blinky. Add azure c sdk into it. And compile it through mbed cli.

@danewalton
Copy link
Member

Are you trying to include the azure c sdk directly via a the github url or via the mbed repositories here. I don't believe the sdk will compile correctly if you include the whole repo from github as the includes won't be resolved. It doesn't look like mbed cli allows you to specify an include directory option.

@surajdagar
Copy link
Author

I tried both ways to add from the mbed page using command mbed add. I use git clone to clone the whole SDK and in my project and add the required header files.
Is there any another way to add c-sdk in the project and compile over mbed-cli?

@danewalton
Copy link
Member

Currently the only way we support is to include the repo's from the the arm website repos. Otherwise you will have to extract the pieces that you need from the github repo and put them in a flat directory structure in your mbed project. You will have to make the includes flat as well which means if a file is included in a .c or .h with a subdirectory prefix, those directories will have to be copied as well. Example being #include "azure_macro_utils/macro_utils.h". In this case, macro_utils.h will have to be within a azure_macro_utils/ directory in the top level of your project.

@surajdagar
Copy link
Author

Hey, I downloaded the arm website repos and try to build it. I am getting below errors- which looks related to the mbed-cli path. mbed-cli don't have any options to set path order.
Building project MicroSoft_Test_Code (NRF52840_DK, GCC_ARM)
Scan: MicroSoft_Test_Code
Compile [ 0.1%]: azure_sha1.c
[Error] strings.h@18,1: unknown type name 'IF'
[Error] strings.h@19,1: unknown type name 'IF'
[Error] strings.h@20,1: unknown type name 'IF'
[Error] strings.h@21,1: unknown type name 'IF'
[Error] strings.h@22,1: unknown type name 'IF'
[Error] strings.h@23,1: unknown type name 'IF'
[Error] strings.h@24,1: unknown type name 'IF'
[Error] strings.h@25,1: unknown type name 'IF'
[Error] strings.h@26,1: unknown type name 'IF'
[Error] strings.h@27,1: unknown type name 'IF'
[Error] strings.h@28,1: unknown type name 'IF'
[Error] strings.h@29,1: unknown type name 'IF'
[Error] strings.h@30,1: unknown type name 'IF'
[Error] strings.h@31,1: unknown type name 'IF'
[Error] strings.h@32,1: unknown type name 'IF'
[Error] strings.h@33,1: unknown type name 'IF'
[Error] strings.h@34,1: unknown type name 'IF'
[Error] strings.h@35,1: unknown type name 'IF'
[Error] strings.h@36,1: unknown type name 'IF'
[ERROR] In file included from ./azure_c_utility/azure_c_shared_utility/strings.h:7:0,
from /usr/arm-none-eabi/include/string.h:24,
from ./azure_c_utility/azure_c_shared_utility/macro_utils.h:17,
from ./azure_c_utility/azure_c_shared_utility/umock_c_prod.h:23,
from ./azure_c_utility/azure_c_shared_utility/gballoc.h:7,
from ./azure_c_utility/azure_sha1.c:42:
./azure_c_utility/azure_c_shared_utility/strings.h:18:1: error: unknown type name 'IF'
MOCKABLE_FUNCTION(, STRING_HANDLE, STRING_new);

Can you please give it a try for nRF52840_DK target or share any link if it's being done before?

@danewalton
Copy link
Member

Are you able to post the exact steps you followed to arrive at that result. So which mbed add .... commands you input etc so that I can try and repro?

@surajdagar
Copy link
Author

Please find the steps below:

  1. Download the blinky program - mbed import http://os.mbed.com/teams/mbed-os-examples/code/mbed-os-example-blinky/
  2. Add azure_c_shared_utility - mbed add http://os.mbed.com/users/AzureIoTClient/code/azure_c_shared_utility/
  3. Add azure_umqtt_c - mbed add http://os.mbed.com/users/AzureIoTClient/code/azure_umqtt_c/
  4. Add iothub_client - mbed add http://os.mbed.com/users/AzureIoTClient/code/iothub_client/
  5. Add iothub_mqtt_transport - mbed add http://os.mbed.com/users/AzureIoTClient/code/iothub_mqtt_transport/
  6. Add serializer - add http://os.mbed.com/users/AzureIoTClient/code/serializer/
  7. Add iothub_ll_telemetry_sample - mbed add http://os.mbed.com/users/AzureIoTClient/code/iothub_ll_telemetry_sample/
  8. Run "mbed deploy" to take tatest from all repos
  9. Replace your blinky main.cpp with iothub_ll_telemetry_sample.c

Use mbed CLI to build the same.

@danewalton
Copy link
Member

So I believe I know what the problem is here. There is a TLDR at the bottom for a possible solution.

It seems that the mbed cli does not allow for an include path to be passed and instead it does something that might seem at first useful to an end user but difficult if you wish to modify. It adds all directories in your current project to the include path.

In our code, we have a file called strings.h which usually would conflict with the std version of it (included via #include <strings.h>), but we put it in a subdirectory of azure_c_shared_utility/ and include it everywhere with #include "azure_c_shared_utility/strings.h". Our include path then only has the parent of azure_c_shared_utility and therefore our version is only included with the azure_c_shared_utility prefix. When the std version is included, it gets the right one because azure_c_shared_utility/ is not in the include path.

In this case, whats happening is the standard string.h from ARM is including strings.h. Instead of getting the standard one, it's pulling ours since azure_c_shared_utility/ is automatically getting included by mbed-cli (which ideally it shouldn't). Once ours gets included, it then tries to include headers it has already included of ours, which have include guards on them, and therefore don't get included a second time. Therefore, the unknown type name 'IF' doesn't get resolved because the file in which it was defined has already been included.

TLDR: Pushing an update to the mbed would take some time so I'm hoping I can help unblock you. If you do a find and replace in the entire project looking for "azure_c_shared_utility/strings.h" and replace with "azure_c_shared_utility/az_strings.h" then go into azure_c_shared_utility/azure_c_shared_utility/ find the strings.h file and rename it to az_strings.h you should be able to avoid that naming conflict.

@surajdagar
Copy link
Author

Thanks @danewalton , It works.

@az-iot-builder-01
Copy link
Collaborator

@danewalton, @surajdagar, thank you for your contribution to our open-sourced project! Please help us improve by filling out this 2-minute customer satisfaction survey

@surajdagar
Copy link
Author

@danewalton Since we are working here Azure SDK compiled successfully but won't do anything after that. I have raised an issue for that Please have a look. @ #1222

@surajdagar surajdagar reopened this Oct 1, 2019
@surajdagar
Copy link
Author

@ #1222 closed and linked to this issue

@danewalton
Copy link
Member

closing this one and looking into #1222

@ericmitt ericmitt mentioned this issue Jun 16, 2020
Closed
@IanMercer
Copy link

For anyone else needing to rename strings.h to handle the conflict, here's a Linux command to do that:

grep -rlZ 'azure_c_shared_utility/strings.h' . | xargs -0 sed -i 's|"azure_c_shared_utility/strings.h"|"azure_c_shared_utility/azstrings.h"|'

culyun added a commit to culyun/W601_IoT_Board that referenced this issue Aug 2, 2024
@culyun
Fix build for most examples.
9f753a6 
All the examples build except for:

  24_iot_websocket
  34_iot_cloud_ms_azure
  35_iot_cloud_tencent

24 and 35 have the same problem,
namely include conflicts between the eabi toolchain implementation of pthreads and rt's implementation.

34 has a problem with include paths.
The azure source code contains a file called 'strings.h'
This conflicts with the standard C library, which has a header of the same name.

Generally things are ok, because the azure strings.h is included by the azure source via a path, namely
#include "azure_c_shared_utility/strings.h"

But the macro_utils.h header happens to include <string.h>,
which then includes <strings.h> but instead of the standard library version it resolves to the azure version.

A hack-around was proposed here:

Azure/azure-iot-sdk-c#1177 (comment)

Basically do an exhaustive name change for azure's strings.h to az_strings.h
This touches a lot of files in the azure source tree.
I might try this in a subsequent commit...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@danewalton danewalton

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@IanMercer @az-iot-builder-01 @surajdagar @danewalton