Build Error when using createLwsIotCredentialProvider for IoT Certs usage

[getash]

I am trying to utilize the IoT Certificate & followed the instruction to change the Common.c file as per the recommendation, using createLwsIotCredentialProvider & freeIotCredentialProvider(&pSampleConfiguration->pCredentialProvider).

When I try to build, I get the following errors. Are there any other changes that requires in addition to Common.c? I built from scratch, meaning did downloaded the repo fresh, copied the Common.c file, made build directory followed with successful sudo cmake .. with a failed sudo make that gave the following errors.

[ 80%] Linking C executable kvsWebrtcClientMaster /usr/bin/ld: libkvsWebrtcSignalingClient.so: undefined reference to symbol 'lwsl_hexdump_level' /usr/bin/ld: /home/amazon-kinesis-video-streams-webrtc-sdk-c/open-source/lib/libwebsockets.so: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status

Please let me know if I am missing something. Thanks!

[MushMal]

Not immediately clear what's going on. Seems like an issue with the libWebSockets. What platform are you using? Can you get the stock repository compiled with the dependencies?

[getash]

This is for Ubuntu platform. I could get the stock repo build with specific encoder changes successfully (I use the GStreamee Sample). When I add the credentials related function as per mentioned, I get the errors. Please let me know if you need anything else. Thanks!

[MushMal]

It’s hard to tell but something is wrong with the build. Perhaps try to clear and rebuild with

git clean —ddfx Then build with the dependencies on.

[getash]

@MushMal I did the following,

sudo git clean -dfx - Since --ddfx did not work. I provided this to remove the necessary files. sudo cmake .. -DBUILD_DEPENDENCIES=TRUE - This was successful with no errors sudo make - Same error as I posted originally

Please let me know if you need any other information or have questions to resolve this. Thanks!

[MushMal]

Could you please include the version of the Ubuntu you are using and the version of the commit. Also, please include the changes you've done

[getash]

@MushMal Ubuntu 19.10. The changes I did are the ones recommended on under Setup IoT section. After allowing the policies for Kinesis streaming for the certs, I did the following changes with our appropriate credentials as below in Common.c.

We replaced the static credentials provider createStaticCredentialProvider() and freeStaticCredentialProvider() with IoT credentials provider like below, the credentials provider for samples is in createSampleConfiguration():

createLwsIotCredentialProvider( "coxxxxxxxx168.credentials.iot.us-west-2.amazonaws.com", // IoT credentials endpoint "/Users/username/Downloads/iot-signaling/certificate.pem", // path to iot certificate "/Users/username/Downloads/iot-signaling/private.pem.key", // path to iot private key "/Users/username/Downloads/iot-signaling/cacert.pem", // path to CA cert "KinesisVideoSignalingCameraIoTRoleAlias", // IoT role alias channelName, // iot thing name, recommended to be same as your channel name &pSampleConfiguration->pCredentialProvider));

freeIotCredentialProvider(&pSampleConfiguration->pCredentialProvider);

[MushMal]

Sounds good. Which commit are you using? As this is build related, it would be hard for us to reproduce without having the details. We will put this in a list of priorities and see if we can repro this. Meanwhile, anyone in the community has a similar issue? Please respond.

[getash]

@MushMal Thank you for quick responses. Below is the output of git log.

commit 35fc3ea5f2132613a8439da41fdfc1b5c052c858 (HEAD -> master, origin/master, origin/HEAD)
Author: Lukas Herman <lherman.cs@gmail.com>
Date:   Thu Oct 1 15:17:49 2020 -0400

    Fix static build contains dynamic links (#837)

    * Fix static build contains dynamic links

    * Add static link check to CI

    * Fix building mbedTLS's test fails on static build

commit 73a6ec9ce5add1aab02bbda4cc31750739cffe7f
Author: Chris Grahn <grahn@posteo.net>
Date:   Thu Oct 1 12:24:11 2020 -0500

    Add internal getErrorCode() and getErrorString() (#834)

    * Add internal getErrorCode() and getErrorString()

    These functions allow the addition of error handling support for
    Windows Sockets Error Codes. On Windows they use WSAGetLastError() and
    FormatMessage(), and on non-Windows platforms they use errno and
    strerror().

    In addition, these functions provide mapping from Windows Sockets
    Error Codes to BSD error codes for the error codes that are explicitly
    checked in code.

    * Use SIZEOF and SNPRINTF

commit 1d5e8b198f463fbdd447fdabc22ecdaf59da81a3
Author: Hassan Sahibzada <hsahibza@amazon.com>
Date:   Thu Oct 1 11:25:21 2020 -0400

[getash]

@MushMal Any updates regarding this? Do you need any further information? Please let me know. Thanks!

[MushMal]

Hi there, sorry, no progress on this. Wonder if anyone else has tried to reproduce this issue.

[getash]

@MushMal Is not there anyway for you folks to reproduce? I did not change much in the base code outside of the mentioned changes. Thanks!

[MushMal]

It's more of the matter of priority. We are trying to triage the incoming issues in a certain priority. I will try to get to this as soon as I can. Meanwhile, have you done any troubleshooting yourself too?

[MushMal]

Forgot to mention that this is one of the scenarios that we are thinking of adding to the Travis CI runs. Perhaps not here but in the demo repository so we can get this executed on a variety of the platforms we are running on.

[getash]

@MushMal Is not it possible to try to replicate this on Ubuntu & see whether the build error occurs or you folks have that already in process before releasing it? It would be helpful to get clarity on what platforms this has been validated, so that if there are any discrepancies between that & what I am trying to do, it would be a path forward in resolving the issue on my end. Thanks again!

[MushMal]

@getash, we have a TravisCI with builds that are running constantly on the master. The IoT scenario is not integrated yet. However, when we cut releases, we do try internally IoT scenarios too. There is a difficulty with integrating IoT certs into Travis CI runs due to security/privacy.

Customers report many build issues on their platforms but we can't replicate every one of those. My question was for you - what steps have you tried debugging this issue? Have you searched the dev forums on what could cause this issue?

We will cover this scenario in a priority order.

[getash]

@MushMal I was trying to get some feedback on the undefined symbols issue & the only possible answer was to change different compilation flags. That gets very specific to the symbols which I am not completely aware of. Since it is Ubuntu platform I presumed it would have been a standard platform but I understand it is not possible to support all kinds of platform. I shall keep hunting for any other troubleshooting I could but any kind of help would be greatly appreciated. Thank you again.

[MushMal]

Confirming that on Mac I can get libWebSockets based IoT integration just fine. Need to have some time to try this on an ubuntu box. Meanwhile, I am wondering if you have the autoconf tools stale. Could you update those?

[MushMal]

@getash could you give this a try?

[getash]

@MushMal I did the changes posted by @bkneff in the CMakeLists.txt & it built successfully. I am still troubleshooting why the credentials based on certs is not working but that is something I need to investigate on my end. As to the build issues, I would say it is resolved unless there is a connection between the credentials based on certs not taking effect.

[MushMal]

Must be something else. Please get more info and cut a new issue. I am going to resolve this one

[atyshka]

I also am experiencing this issue. I originally was just using the static credentials provider, and everything worked fine. But switching to the IoT credentials provider yields the same undefined reference to symbol 'lwsl_hexdump_level'. I am on Ubuntu 18.04. Oddly enough, it looks like changing the link order for the signaling client did not resolve the issue for me.

[atyshka]

To clarify, if I add the IoT credential provider within the project this works. #862 solved that within the project. My use case is I am trying to link against this project externally rather than within the CMakeLists for this project. I have the exact code for the kvsMaster example, and previously I had it working but it's having the same issue with the credentials provider. It seems what I need is to replicate the linking order that CMake is using here. It is still odd that the link order is so important and fragile though. Hopefully I can eventually migrate my project to 20.04 and with newer package versions avoid issues such as this plaguing the open-source builds