You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When attempting to build the sample project, basic_pub_sub, using built shared libraries for mipsel_24kc_musl, I am getting undefined references to symbols in libaws-c-io.so.
Initially, I tried to modify the CMakeList.txt for the sample project to include my tool chain. However, it has been a nightmare due to the libraries being built with relative paths to libraries each of them are dependent on, and after running make install to my tool chain staging directory, they don't seem to follow the same relative paths. This has forced me to try create a custom mipsel-openwrt-linux-g++ command to build the program.
I don't have any issues when I build and install the libraries for my host system (WSL in this case), where it builds with no issues; it sounds like I'm missing a cmake flag/variable.
I ran the following to build the shared libraries (with modified CMakeLists.txt to use the tool chain:
Successfully compile basic_pub_sub via cmake with specified cross compiler settings. Also, being able to compile without cmake (my main project doesn't use cmake) and with shared libraries.
Current Behavior
Undefined symbols from libaws-c-io.so when compiling, where it appears linking order and directories are correct.
Shared libraries are built with relative paths to the libraries they depend on, which doesn't match the path structure after installing the libraries.
Reproduction Steps
I have provided code and commands that I have used when trying to build the libraries and sample program.
The CMakeLists.txt files are the only files I have modified, along with the bash script I used to wrapper my compiler command.
The tool chain is for the Teltonika RUT956 that uses OpenWRT for mispel (mipsel_24kc_gcc-8.4.0_musl).
Possible Solution
More information on cmake variables regarding cross compiling.
Not to use relative paths for library dependency.
Additional Information/Context
The main point is that there should not be undefined references after ensuring library order and directories are correct, regardless of it built is via cmake or not. Also, the relative paths to libraries makes it a headache to implement into a custom project.
I really hope to use this in a commercial distribute system for SCADA systems. The AWS IoT framework seems to be perfect for our application.
I would really appreciate any feedback/guidance, from this ticket, to be able to compile and run our project.
We don't presently support Mips as an architecture target. Beyond that, the library ordering does not appear to be correct. aws-c-io is a dependency of a number of libraries that you've placed later in the command line.
This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.
Describe the bug
When attempting to build the sample project, basic_pub_sub, using built shared libraries for mipsel_24kc_musl, I am getting undefined references to symbols in libaws-c-io.so.
Initially, I tried to modify the CMakeList.txt for the sample project to include my tool chain. However, it has been a nightmare due to the libraries being built with relative paths to libraries each of them are dependent on, and after running
make install
to my tool chain staging directory, they don't seem to follow the same relative paths. This has forced me to try create a custommipsel-openwrt-linux-g++
command to build the program.I don't have any issues when I build and install the libraries for my host system (WSL in this case), where it builds with no issues; it sounds like I'm missing a cmake flag/variable.
I ran the following to build the shared libraries (with modified CMakeLists.txt to use the tool chain:
My CMakeLists.txt for basic_pub_sub in
./samples/pub_sub/basic_pub_sub
:Compiler command script for basic_pub_sub in
./samples/pub_sub/basic_pub_sub
:For context, here are the paths to the libraries libaws-crt-cpp.so depends on:
When I run my compiler command script, the undefined symbols appear to be part of libaws-c-io.so:
Expected Behavior
Successfully compile basic_pub_sub via cmake with specified cross compiler settings. Also, being able to compile without cmake (my main project doesn't use cmake) and with shared libraries.
Current Behavior
Undefined symbols from libaws-c-io.so when compiling, where it appears linking order and directories are correct.
Shared libraries are built with relative paths to the libraries they depend on, which doesn't match the path structure after installing the libraries.
Reproduction Steps
I have provided code and commands that I have used when trying to build the libraries and sample program.
The CMakeLists.txt files are the only files I have modified, along with the bash script I used to wrapper my compiler command.
The tool chain is for the Teltonika RUT956 that uses OpenWRT for mispel (mipsel_24kc_gcc-8.4.0_musl).
Possible Solution
More information on cmake variables regarding cross compiling.
Not to use relative paths for library dependency.
Additional Information/Context
The main point is that there should not be undefined references after ensuring library order and directories are correct, regardless of it built is via cmake or not. Also, the relative paths to libraries makes it a headache to implement into a custom project.
I really hope to use this in a commercial distribute system for SCADA systems. The AWS IoT framework seems to be perfect for our application.
I would really appreciate any feedback/guidance, from this ticket, to be able to compile and run our project.
Many thanks.
SDK version used
1.30.3
Environment details (OS name and version, etc.)
host: WSL 2 (Ubuntu 22.04.2 LTS) - target: mipsel_24kc_musl
The text was updated successfully, but these errors were encountered: