building a 3rd party library

[mzimmers]

So, I went ahead and created a components directory:

Code: Select all

 Directory of C:\esp32-projects\wifi_libsrtp

06/19/2020  11:40 AM    <DIR>          .
06/19/2020  11:40 AM    <DIR>          ..
06/19/2020  11:51 AM    <DIR>          build
06/19/2020  10:45 AM               247 CMakeLists.txt
06/19/2020  10:33 AM    <DIR>          components
06/19/2020  11:13 AM    <DIR>          main
06/04/2020  04:00 PM               193 Makefile
06/04/2020  04:00 PM             4,728 README.md
06/19/2020  10:01 AM            26,488 sdkconfig
06/19/2020  10:00 AM            20,828 sdkconfig.old
               5 File(s)         52,484 bytes
               5 Dir(s)  917,281,918,976 bytes free

C:\esp32-projects\wifi_libsrtp>

when I run idf.py build, I first get this error:

Code: Select all

Syntax error in cmake code at
      C:/esp32-projects/wifi_libsrtp/build/build_properties.temp.cmake:2
    when parsing string
      C:\esp32-toolchain\.espressif\python_env\idf4.0_py3.7_env\Scripts\python.exe
    Invalid escape sequence \e

I realize this is just a warning, but I get other errors later which could be related.

Most of the other errors are of the "not scriptable" variety:

Code: Select all

project command is not scriptable

I do notice that my component seems to be based on a 2.n version of CMake. Is this going to present a problem for me?

Thanks....

[nvannote]

I do notice that my component seems to be based on a 2.n version of CMake. Is this going to present a problem for me?

I took a quick look at the library. CMake aside, that is going to need some work to get setup for the esp-idf toolchain correctly.

A configure for the xtensa-esp32-elf toolchain went fine. But get a "Platform not recognized" (Not surprised) first thing on a build. That's as far as I went (for now).

Best Regards

[nvannote]

If I understand correctly, the term "library" as used in the ESP world doesn't refer to a pre-built .a file, but rather a collection of sources and build instructions.

The term "library" or "component" does indeed refer to a pre-built .a (static library) file; pre-built in the context of building your main component (which is also compiled as a static library .a). You will find them in the projects build/esp-idf directory.

Best Regards

[nvannote]

I do notice that my component seems to be based on a 2.n version of CMake. Is this going to present a problem for me?

I took a quick look at the library. CMake aside, that is going to need some work to get setup for the esp-idf toolchain correctly.

A configure for the xtensa-esp32-elf toolchain went fine. But get a "Platform not recognized" (Not surprised) first thing on a build. That's as far as I went (for now).

Best Regards

Well, during some downtime, I took another look. Using a modified CMakeLists.txt tailored for the esp-idf toolchain expectations; deferring some items with "NOT CMAKE_BUILD_EARLY_EXPANSION" and whatnot; I got a build without any code changes.

Need to go back and review that configuration; and adapt the test cases that actually use it.

Best Regards

[mzimmers]

Thank you for all you're doing on this. At some time, I'd appreciate seeing your work in more detail. I'm still quite new to CMake and its nuances.

[nvannote]

Thank you for all you're doing on this. At some time, I'd appreciate seeing your work in more detail. I'm still quite new to CMake and its nuances.

No worries, I decided to take it on as a pet "filler" project. I certainly don't need this library at the moment, but you never know when the need may arise.

Once I am satisfied that the ESP-IDF build is clean, correct and functional; I will certainly share it. Ideally, without touching anything in the existing CISCO repository.

Regards

[nvannote]

Thank you for all you're doing on this. At some time, I'd appreciate seeing your work in more detail. I'm still quite new to CMake and its nuances.

First Cut.

I ended up taking a little more “brute force” approach using a “known good” config.h I had generated against the IDF toolchain separately. Generating it directly from CMake during a IDF build was consistently getting it wrong for reasons not clear to me at the moment.

Fortunately the configure requirements for libsrtp are straight forward enough; and there are other IDF components that take a similar approach, so I am not going to loose any sleep over that.

I put together a small AES-256 test that was derived from code in the Cisco unit tests. All seems to be working so far with very very light test coverage. I have NOT tested anything that involves any network access as of yet (soon).

Built and Tested with: ESP-IDF v4.0.1; Cisco SRTP v2.3.0; on a ESP32 (ESP32-D0WDQ6) Rev 1.

And of course, let me know if it makes your dev module burst into a ball of flames.

https://github.com/nvannote/esp_ports/t ... r/esp_srtp

Best Regards

[mzimmers]

Hi nvannote -

I tried building your repo, and got this error:

CMake Error at C:/esp-idf/tools/cmake/component.cmake:283 (message):
Include directory
'C:/esp32-projects/esp_ports/esp_srtp/components/srtp/libsrtp/include' is
not a directory.

Was I supposed to copy the Cisco library into my local copy of your repo?

[nvannote]

Was I supposed to copy the Cisco library into my local copy of your repo?

I am guessing you didn't read any of the two (2) README files.

My "repo" is an example project getting libsrtp built and used as a component. Yes, that example currently expects the libsrtp directory (or a symbolic link to it) to exist in its "components/srtp" directory. Technically, the srtp "component" directory could sit anywhere independently, it would just need to be referred to via the EXTRA_COMPONENT_DIRS variable; Technically, (with minor adjustment) the libsrtp "library" directory could sit anywhere independently, just so long as the srtp "component" can refer to it.

Best Regards

[mzimmers]

I am guessing you didn't read any of the two (2) README files.

Not carefully enough...mea culpa. I went ahead and copied the library under your project structure (I'm running on Windows and links/shortcuts don't always do what I want them to). It now builds and runs. Very nice work on your part.

A couple of minor details:

1. at startup, I'm getting this error:

W (302) spi_flash: Detected size(8192k) larger than the size in the binary image header(4096k). Using the size in the binary image header.

Do you get this as well?

2. I do my code browsing and editing in an IDE (one that currently can't cross-compile for the ESP32, but it's still a great tool). The IDE isn't finding any of the ESP_LOGX macros in your main. More accurately, it's not finding CONFIG_LOG_DEFAULT_LEVEL. The program builds and runs using the idf.py tool, so this is nothing more than an inconvenience, but my incipient curiosity has me wondering why. I compared your sdkconfig file with one from another project (that does find that macro), and didn't see any differences that looked relevant. Did you have to do anything to get the linker to "find" this?

I'm going to dig into it more later, but this is very encouraging work. Thanks SO much for your efforts.