Failed to resolve component 'esp_ipc' - cmake

I am configuring a project on an ESP32doitdev board. I am using the native esp32-framework as well as arduino. I am working with the platformio core in order to compile. I am getting an error which resolves to a inter-processor call module in the esp32-idf framework. In trying to fix the issue on my own I went into idf.py menuconfig and tried to configure anything that would logically relate to an inter-processor call module. However, I was unsuccessful. I was wondering if someone could give me some insight into why this error might be happening? I am relatively new to cmake and I'm a bit lost.
CMakeLists.txt
cmake_minimum_required(VERSION 3.16.0)
include($ENV{IDF_PATH}/tools/cmake/project.cmake)
project(Peripherals)
ESP-IDF Inter Processor Call Configuration
![enter image description here][1]
Build Error Message pio run
francis#eniac:~/Documents/Peripheral$ /home/francis/.platformio/penv/bin/pio run
Processing esp32doit-devkit-v1 (platform: espressif32; board: esp32doit-devkit-v1; framework: espidf, arduino)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32doit-devkit-v1.html
PLATFORM: Espressif 32 (3.3.2) > DOIT ESP32 DEVKIT V1
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (esp-prog) External (esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES:
- framework-arduinoespressif32 0.0.0+sha.a418058
- framework-espidf 3.40001.200521 (4.0.1)
- tool-cmake 3.16.4
- tool-esptoolpy 1.30100.210531 (3.1.0)
- tool-ninja 1.7.1
- toolchain-esp32ulp 1.22851.191205 (2.28.51)
- toolchain-xtensa32 2.80400.210211 (8.4.0)
Installing ESP-IDF's Python dependencies
Collecting cryptography>=2.1.4
Using cached cryptography-35.0.0-cp36-abi3-manylinux_2_24_x86_64.whl (3.5 MB)
Collecting future>=0.15.2
Using cached future-0.18.2-py3-none-any.whl
Collecting pyparsing<2.4.0,>=2.0.3
Using cached pyparsing-2.3.1-py2.py3-none-any.whl (61 kB)
Collecting kconfiglib==13.7.1
Using cached kconfiglib-13.7.1-py2.py3-none-any.whl (145 kB)
Collecting cffi>=1.12
Using cached cffi-1.15.0-cp38-cp38-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (446 kB)
Collecting pycparser
Using cached pycparser-2.20-py2.py3-none-any.whl (112 kB)
Installing collected packages: pycparser, cffi, pyparsing, kconfiglib, future, cryptography
Successfully installed cffi-1.15.0 cryptography-35.0.0 future-0.18.2 kconfiglib-13.7.1 pycparser-2.20 pyparsing-2.3.1
Warning! Arduino framework as an ESP-IDF component doesn't handle the `variant` field! The default `esp32` variant will be used.
Reading CMake configuration...
-- Found Git: /usr/bin/git (found version "2.25.1")
-- The C compiler identification is GNU 8.4.0
-- The CXX compiler identification is GNU 8.4.0
-- The ASM compiler identification is GNU
-- Found assembler: /home/francis/.platformio/packages/toolchain-xtensa32/bin/xtensa-esp32-elf-gcc
-- Check for working C compiler: /home/francis/.platformio/packages/toolchain-xtensa32/bin/xtensa-esp32-elf-gcc
-- Check for working C compiler: /home/francis/.platformio/packages/toolchain-xtensa32/bin/xtensa-esp32-elf-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /home/francis/.platformio/packages/toolchain-xtensa32/bin/xtensa-esp32-elf-g++
-- Check for working CXX compiler: /home/francis/.platformio/packages/toolchain-xtensa32/bin/xtensa-esp32-elf-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Project version: 7bca477-dirty
-- Building ESP-IDF components for target esp32
-- Configuring incomplete, errors occurred!
See also "/home/francis/Documents/Peripheral/.pio/build/esp32doit-devkit-v1/CMakeFiles/CMakeOutput.log".
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
CMake Error at /home/francis/.platformio/packages/framework-espidf/tools/cmake/build.cmake:185 (message):
Failed to resolve component 'esp_ipc'.
Call Stack (most recent call first):
/home/francis/.platformio/packages/framework-espidf/tools/cmake/build.cmake:216 (__build_resolve_and_add_req)
/home/francis/.platformio/packages/framework-espidf/tools/cmake/build.cmake:425 (__build_expand_requirements)
/home/francis/.platformio/packages/framework-espidf/tools/cmake/project.cmake:348 (idf_build_process)
CMakeLists.txt:3 (project)
platform.ini
[env:esp32doit-devkit-v1]
platform = espressif32
board = esp32doit-devkit-v1
framework = espidf, arduino
platform_packages = framework-arduinoespressif32 # https://github.com/espressif/arduino-esp32.git
monitor_speed = 115200
build_flags =
-D ARDUINO=100
-D ESP32=100
-I src/lib/*/src/*

Related

I'm Trying to use VTK with Qt using CMake and Visual Studio, and get this Error while building fatal error -> Byte order of target CPU unknown

My os is windows running on parallels Desktop app on Mac M2
When I Try to build the libraries I get this error
fatal error C1189: #error: "Byte order of target CPU unknown."
This is what I got in the console of VS when I finished installing
274>------ Build started: Project: ALL_BUILD, Configuration: Release ARM64 ------ 274>Building Custom Rule C:/VTK-9.2.2/src/CMakeLists.txt ========== Build: 157 succeeded, 117 failed, 0 up-to-date, 0 skipped ========== ========== Elapsed 11:48.565 ==========
If you are using an old (<2.8 cmake, this can be the issue): https://cmake.org/Bug/view.php?id=13808
In any case, you might try to set the byte-order manually in your cmake file:
set( CMAKE_CXX_BYTE_ORDER BIG_ENDIAN)
You could also check that CMAKE_OSX_ARCHITECTURES only specify one architecture or all architectures shares the same byte-order.

MariaDB connector OBC Build- Driver manager was not found

I am trying to build the RPM from the source https://downloads.mariadb.org/connector-odbc/3.0.8/ on SUSE Linux
following mariadb homepage
https://mariadb.com/kb/en/building-mariadb-connectorodbc-from-source/#building-mariadb-connectorodbc
However, it results in the following error "Driver Manager was not found"
.
+ cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCONC_WITH_UNIT_TESTS=Off '-
DCMAKE_C_FLAGS_RELWITHDEBINFO=-I/usr/local/incude/mariadb -L/usr/local/lib'
-- The C compiler identification is GNU 7.3.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- There is no Connector/C sub-project folder, linking against libmariadb installed on the system
-- Looking for floor
-- Looking for floor - not found
-- Looking for floor in m
-- Looking for floor in m - found
CMake Error at CMakeLists.txt:180 (MESSAGE):
Driver Manager was not found
Any help will be appreciated
Are you trying to build the connector on platforms other than i686/x86_64?
I encountered the same issue when I am building it on AWS t4g (ARM architecture). I have succeeded to get rid of this error by providing the correct location of headers:
DM_DIR=/usr/lib/aarch64-linux-gnu cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCONC_WITH_UNIT_TESTS=Off -DCONC_WITH_MSI=OFF -DCMAKE_INSTALL_PREFIX=/usr/local .
The correct location of DM_DIR may vary depends on your architecture. (In my case: /usr/lib/aarch64-linux-gnu for AWS EC2 t4g instance with Debian 10)
Reference: https://jira.mariadb.org/browse/ODBC-268

linuxbrew installed cmake on a cluster cannot find lib in /usr/lib64

I'm trying to build caffe on a GGPU cluster. I've installed a lot of dependencies in a subfolder of my home using linuxbrew. One of those dependencies is an updated version of cmake(needed).
When i launch the command
cmake ..
i get this output
-- Boost version: 1.59.0
-- Found the following Boost libraries:
-- system
-- thread
-- filesystem
-- Found gflags (include: /home/cgvg/.linuxbrew/include, library: /home/cgvg/.linuxbrew/lib/libgflags.so)
-- Found glog (include: /home/cgvg/.linuxbrew/include, library: /home/cgvg/.linuxbrew/lib/libglog.so)
-- Found PROTOBUF Compiler: /home/cgvg/.linuxbrew/bin/protoc
-- Found lmdb (include: /home/cgvg/.linuxbrew/include, library: /home/cgvg/.linuxbrew/lib/liblmdb.a)
-- Found LevelDB (include: /home/cgvg/.linuxbrew/include, library: /home/cgvg/.linuxbrew/lib/libleveldb.so)
-- Found Snappy (include: /home/cgvg/.linuxbrew/include, library: /home/cgvg/.linuxbrew/lib/libsnappy.so)
-- CUDA detected: 7.5
-- Automatic GPU detection failed. Building for all known architectures.
-- Added CUDA NVCC flags for: sm_20 sm_21 sm_30 sm_35 sm_50
-- OpenCV found (/home/cgvg/sottile/opencv/share/OpenCV)
CMake Error at /home/cgvg/.linuxbrew/Cellar/cmake/3.4.1/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
Could NOT find Atlas (missing: Atlas_LAPACK_LIBRARY)
Call Stack (most recent call first):
/home/cgvg/.linuxbrew/Cellar/cmake/3.4.1/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)
cmake/Modules/FindAtlas.cmake:42 (find_package_handle_standard_args)
cmake/Dependencies.cmake:88 (find_package)
CMakeLists.txt:38 (include)
-- Configuring incomplete, errors occurred!
See also "/home/cgvg/sottile/caffe/build/CMakeFiles/CMakeOutput.log".
See also "/home/cgvg/sottile/caffe/build/CMakeFiles/CMakeError.log".
and it seems there is nothing i can do to link the ATLAS libs correctly.
The missing libs are under
/usr/lib64/atlas-sse3
Is it possible that there exists a limitation such that my linuxbrewed cmake cannot link to upper folders?
In the error message it says that:
cmake/Modules/FindAtlas.cmake:42
I tried to modify that file adding the correct paths:
set(Atlas_INCLUDE_SEARCH_PATHS
/usr/include
$ENV{Atlas_ROOT_DIR}
$ENV{Atlas_ROOT_DIR}/include
)
set(Atlas_LIB_SEARCH_PATHS
/usr/lib64/atlas
/usr/lib64/atlas-sse3
$ENV{Atlas_ROOT_DIR}
$ENV{Atlas_ROOT_DIR}/lib
)
and nothing happened.
i tried to change the PATH and LD_LIBRARY_PATH:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib64/atlas-sse3
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/include/atlas-x86_64-base-sse3/
and nothing happened.
I'm not a linux veteran so i apologize if i missed some important information. Any suggestion is appreciated.
EDIT:
this is the content of /usr/lib64/atlas3-sse3:
libatlas.a libcblas.so.3.0 libf77blas.so.3.0 libptcblas.so.3
libatlas.so libclapack.so liblapack.a libptcblas.so.3.0
libatlas.so.3 libclapack.so.3 liblapack.so libptf77blas.a
libatlas.so.3.0 libclapack.so.3.0 liblapack.so.3 libptf77blas.so
libcblas.a libf77blas.a liblapack.so.3.0 libptf77blas.so.3
libcblas.so libf77blas.so libptcblas.a libptf77blas.so.3.0
libcblas.so.3 libf77blas.so.3 libptcblas.so
libatlas.a libcblas.so.3.0 libf77blas.so.3.0 libptcblas.so.3
libatlas.so libclapack.so liblapack.a libptcblas.so.3.0
libatlas.so.3 libclapack.so.3 liblapack.so libptf77blas.a
libatlas.so.3.0 libclapack.so.3.0 liblapack.so.3 libptf77blas.so
libcblas.a libf77blas.a liblapack.so.3.0 libptf77blas.so.3
libcblas.so libf77blas.so libptcblas.a libptf77blas.so.3.0
libcblas.so.3 libf77blas.so.3 libptcblas.so
It seems that lapack is bundled in atlas, for this reason FindAtlas.cmake is not able to find alapack_r, alapck or lapack_atlas.
It is enough to edit caffe_folder/cmake/Module/FindAtlas.cmake, look for Atlas_LAPACK_LIBRARY NAMES and add clapack to the list of libs.
It completely solve the problem.

SIGABRT while building mono on Solaris

I've been trying to build Mono 3.2.3 on Solaris 11 with no luck. I've made a few minor code changes and turned off configuration features to get to this point but now I'm stuck with mono crashing while trying to build System.dll. Any ideas?
MONO_PATH="./../../class/lib/basic:$MONO_PATH" /home/axsadm/mono-3.2.3/runtime/mono-wrapper ./../../class/lib/basic/basic.exe /codepage:65001 -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -nowarn:1699 -nostdlib -lib:./../../class/lib/build -r:mscorlib.dll -optimize /noconfig -nowarn:618 -d:CONFIGURATION_2_0 -unsafe -resource:resources/Asterisk.wav -resource:resources/Beep.wav -resource:resources/Exclamation.wav -resource:resources/Hand.wav -resource:resources/Question.wav -target:library -out:../../class/lib/build/tmp/System.dll #System.dll.sources
+ r=/home/axsadm/mono-3.2.3
+ MONO_CFG_DIR=/home/axsadm/mono-3.2.3/runtime/etc
+ PATH=/home/axsadm/mono-3.2.3/runtime/_tmpinst/bin:/usr/bin:/usr/sbin
+ MONO_SHARED_DIR=/home/axsadm/mono-3.2.3/runtime
+ export MONO_CFG_DIR MONO_SHARED_DIR PATH
+ [ -n '' ]
+ exec /home/axsadm/mono-3.2.3/libtool '--mode=execute' /home/axsadm/mono-3.2.3/mono/mini/mono --config /home/axsadm/mono-3.2.3/runtime/etc/mono/config ./../../class/lib/basic/basic.exe /codepage:65001 -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -nowarn:1699 -nostdlib -lib:./../../class/lib/build -r:mscorlib.dll -optimize /noconfig -nowarn:618 -d:CONFIGURATION_2_0 -unsafe -resource:resources/Asterisk.wav -resource:resources/Beep.wav -resource:resources/Exclamation.wav -resource:resources/Hand.wav -resource:resources/Question.wav -target:library -out:../../class/lib/build/tmp/System.dll #System.dll.sources
* Assertion at threads.c:1001, condition `info' not met
Native stacktrace:
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_handle_native_sigsegv+0x1b8 [0x187c58]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'sigabrt_signal_handler+0xa0 [0x1ed97c]
/lib/libc.so.1'__sighndlr+0xc [0xff0254f0]
/lib/libc.so.1'call_user_handler+0x370 [0xff018e50]
/lib/libc.so.1'sigacthandler+0x58 [0xff019040]
/lib/libc.so.1'_lwp_kill+0x8 [0xff029fa0]
/lib/libc.so.1'abort+0xc8 [0xfefaac2c]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'monoeg_g_logv+0x174 [0x3d5454]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'monoeg_assertion_message+0x38 [0x3d54e8]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_thread_attach_full+0x2bc [0x2dc650]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_thread_attach+0x10 [0x2dc37c]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_runtime_init+0x23c [0x314034]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mini_init+0x1a60 [0x77158]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_main+0x232c [0x1457a4]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_main_with_options+0x48c [0x5fa30]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'main+0x2c [0x5fa74]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'_start+0x5c [0x5f3e4]
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
gmake[8]: *** [../../class/lib/build/tmp/System.dll] Abort (core dumped)
Configuration:
Engine:
GC: included Boehm
TLS: pthread
SIGALTSTACK: no
Engine: Building and using the JIT
oprofile: no
BigArrays: no
DTrace: no
LLVM Back End: no (dynamically loaded: no)
Libraries:
.NET 2.0/3.5: yes
.NET 4.0: yes
.NET 4.5: yes
MonoDroid: no
MonoTouch: no
JNI support: IKVM Native
libgdiplus: assumed to be installed
zlib: system zlib
This might be a bit late, but for me I had more luck using the external Boehm GC as opposed to the bundled/included one.
./autogen.sh --prefix=/usr --disable-dtrace --with-sgen=no --with-gc=boehm
This seemed to work OK for Solaris 10 and 11 on Intel. I'm still working on SPARC!
Good luck,
Steve

Cross compiling Mono framework 3.0.6+ for MIPS

I am trying to cross-compile Mono framework (3.0.6) for MIPS platform. There are few issues I have found so I would like to ask the community whether there are known or not.
My environment: Linux 3.2.0-39-generic #62-Ubuntu SMP Thu Feb 28 00:28:53 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Toolchain: Sourcery G++ Lite 4.3-51
command-line:
./configure --prefix=/home/dev/mono-3.0.6-mips --host=mips-linux-gnu --enable-minimal=profiler,debug,logging,soft_debug --without-mcs-docs --target=mips-linux-gnu --with-moonlight=no --with-tls=pthread --with-sigaltstack=no --with-profile4_5=yes CXXFLAGS="-mips32r2 -march=24kf -mtune=24kf -EL" CFLAGS="-mips32r2 -march=24kf -mtune=24kf -EL" && make
Issue #1:
When I managed it to configure, compilation stopped with the following error:
mini-gc.c:2551: error: redefinition of 'mini_gc_enable_gc_maps_for_aot'
mini-gc.c:2518: error: previous definition of 'mini_gc_enable_gc_maps_for_aot' was here
Issue #2:
After I commented out the second declaration of mini_gc_enable_gc_maps_for_aot it compiled but looks like Sourcery G++ linker crashed:
/home/dev/mips-4.3/bin/../lib/gcc/mips-linux-gnu/4.3.2/../../../../mips-linux-gnu/bin/ld: BFD (Sourcery G++ Lite 4.3-51) 2.18.50.20080215 assertion fail /scratch/clm/2008q3-lite/obj/binutils-src-4.3-51-mips-linux-gnu-i686-pc-linux-gnu/bfd/elfxx-mips.c:2651
Could anyone led some light to this problem? I failed to find any articles/info describing building Mono for MIPS architecture (at least some recent information). According to this link, support for MIPS was added about a year ago. Mono itself should fully support MIPS since 3.0.4 version.
I am posting this info for everyone else who will struggle with the same problem (building Mono for MIPS platform):
At last I was able to build mono runtime for MIPS platform using the following command line:
./configure --prefix=/home/dev/mono-3.0.6-mips --host=mips-linux-gnu --enable-minimal=profiler,debug,logging,soft_debug --without-mcs-docs --target=mips-linux-gnu --with-moonlight=no --with-tls=pthread --with-sigaltstack=no --with-profile4_5=yes CXXFLAGS="-mips32r2 -EL" CFLAGS="-mips32r2 -EL" LDFLAGS=-EL CPPFLAGS="-mips32r2 -EL" ASFLAGS=-EL CC="mips-linux-gnu-gcc -EL"
Specifying -EL flag for all the tools fixed issue with mono linking using ld (see Issue #2 in my initial post).
The last issue left is to make the mono build system to build mscorlib.dll. Invoking different make commands inside mcs/class folder doesn`t do anything.