I'm trying to cross-compile a programme for a Yocto qemu using Yocto's sdk tools. After setting up the sdk and sourcing it, trying to cross-compile the programme fails thusly:
*** Unable to find the ncurses libraries or the
*** required header files.
*** 'make menuconfig' requires the ncurses libraries.
***
*** Install ncurses (ncurses-devel) and try again.
***
So I added ncurses to the IMAGE_INSTALL listing in the image's recipe, the same way I've installed other packages like dropbear, and confirmed that the meta layer that provides these packages was included in the bblayers.conf file. Then
TOOLCHAIN_HOST_TASK += "nativesdk-ncurses nativesdk-ncurses-dev"
was also added to the image's recipe, to tell bitbake to give the host's sdk access to ncurses. I tried adding several variations on nativesdk-ncurses-devel, to more closely match what the error was asking for, but the image was unable to build with it. After that the image and sdk were re-built and re-sourced, but when attempting to cross compile the programme, it still asked for Install ncurses (ncurses-devel) and try again.
So my question is:
How is ncurses added properly to Yocto's host sdk environment? Is there a step I'm missing? Are the ncurses files needed not the same as those found in the meta layer?
Any help would be deeply appreciated.
-Patches
Please add needed package as RDEPENDS_${PN} in nativesdk-packagegroup-sdk-host.bb
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
Related
I know that someone already asked this question but it isn`t up to date anymore. Most of the links are dead and the commands are not relevant anymore.
I have read these
Compile IOS program from linux commandline
How to cross-compile clang/llvm for iOS?
For example, I have been trying to compile silversearcher-ag for my iPhone 6 (jailbroken). This is the project link https://github.com/ggreer/the_silver_searcher.
I am targeting iOS 12.4.
These are the commands that I`ve tried
./configure CC=/home/growtopiajaw/Desktop/cctools-port-master/usage_examples/ios_toolchain/target/bin/arm-apple-darwin11-clang CXX=/home/growtopiajaw/Desktop/cctools-port-master/usage_examples/ios_toolchain/target/bin/arm-apple-darwin11-clang++ --host=arm-apple-darwin11
make
I am using cctools-port to cross compile the project. My compiled cctools toolchain is located under /home/growtopiajaw/Desktop/cctools-port-master/usage_examples/ios_toolchain/target and below is how the toolchain`s directory structure looks like
This is my configure log: https://del.dog/nugibonury
This is my make log:
CC src/ignore.o
In file included from src/ignore.c:11:
./src/options.h:7:10: fatal error: 'pcre.h' file not found
#include <pcre.h>
^~~~~~~~
1 error generated.
make: *** [Makefile:494: src/ignore.o] Error 1
This is my GitHub repository containing the cross compile toolchain
https://github.com/GrowtopiaJaw/arm-apple-darwin11
Apple does not ship PCRE. You need to get the headers and dylib/tbd files manually.
If you're using checkra1n or unc0ver, then the deb on the APT repo contains headers as well, so you could just use that.
If you plan to package this into an APT/dpkg file, make sure to add pcre as a dependency.
I am trying to build and install Drake from source in order to get support for Mosek. I keep running into trouble, however. For the record, I am running macOS Catalina.
Right now my approach has been this:
Clone drake from github to a location on my computer (from https://github.com/RobotLocomotion/drake.git)
Install prereqs
with ./setup/mac/install_prereqs.sh
Run bazel build //... Make a
directory called build and cd build cmake .. and then make
and make install
And in my C++ project, which I build using cmake, I add this to CMakeLists.txt:
link_directories(drakelocation/build/install/lib)
include_directories(drakelocation/build/install/include)
However, when I try to build my project, I get an error that Drake is unable to locate Eigen: 'Eigen/Core' file not found. I was able to work around this by adding:
target_link_libraries(my_lib Eigen3::Eigen) to my CMakeLists.txt
I found this a bit strange, as I expect that Drake includes Eigen when it is built, but at least this made me able to get a bit further.
After this I get a bunch of messages of the type:
no member named 'signbit' in the global namespace
i.e. it seems like Drake suddenly is missing all the standard C++ libraries. I have not yet been able to fix this issue, so this is where I am currently stuck.
Do you have any suggestions, or have you encountered any similar problems before?
Other information:
Using find_package(drake) does not work with my current approach at all (cmake is not able to locate drake-config.cmake). Am I missing something here that is required to make this work? Where does cmake expect libraries to be installed, and how do I install them in that place?
I have also tried skipping the entire bazel build //... step, going directly to the cmake .. step, which did not seem to make any difference.
In between every different build approach I have run bazel clean --expunge to make sure that nothing sticks around from the previous run.
Thanks!
You need to tell CMake where your Drake installation is located:
list(APPEND CMAKE_PREFIX_PATH /absolute/path/to/drakelocation/build/install)
find_package(drake REQUIRED)
add_library(my_lib ...)
target_link_libraries(my_lib drake::drake)
This ensures you have all the necessary compiler and linker flags. Setting the include directory to simply /absolute/path/to/drakelocation/build/install/include is insufficient since it does not contain the include directories of the various dependencies of Drake.
Note that you do not need to call bazel yourself before calling cmake. When you run make install, it will call bazel internally.
Thanks #Jamie that solved the find_package() problem I had.
I still had some trouble with the build. Turns out that there was something wrong with my default SDK path, and that setting "CMAKE_OSX_SYSROOT" according to this: Catalina C++: Using <cmath> headers yield error: no member named 'signbit' in the global namespace after an update to XCode did the trick.
After this, I got a lot of strange error messages from Eigen, complaining that i.e. MatrixXd was not defined in the namespace 'Eigen'. For some reason, uninstalling it with brew uninstall eigen and then downloading and building eigen from source solved those problems.
It now works!
I am working on a formula to brew install postfix from source code in the my mac mini. I am able to make the makefiles, make, and make install the software, however brew link can not be completed due to the libdns.a needed to be linked into /usr/local/lib. There is a link in the directory with the same name from bind already installed previously. So, I need to ask for help to resolve the conflict.
Is there any workaround to relocate the link to /usr/local/lib/postfix, /usr/lib, or somewhere else?
Can I ignore the very link and just complete the rest? What will fail?
I have downloaded the face analysis SDK from http://face.ci2cv.net/ and installed the source code according to the documentation. CMake has successfully configured the project. Now I have to use nmake to complete the build. However, when I try to run nmake I get this:
fatal Error U1064: MAKEFILE not found and no target specified.
How can I get this Makefile? Any ideas?
Please help me.
Thanks, B
I'm trying to build Firefox from source and I'm getting hung up on some of the requirements.
I'm trying to build libIDL, which requires glib. I got glib built and installed to /usr/local, but when I try and configure libIDL, I get a failure at:
checking for LIBIDL... configure: error: Package requirements (glib-2.0 >= 2.4.0) were not met:
No package 'glib-2.0' found
I used the very latest version of glib that I can find, ftp://ftp.gtk.org/pub/glib/2.20/glib-2.20.3.tar.gz
However, I've also been searching around and am seeing references to libglib-2.0 such as at http://packages.debian.org/search?keywords=libglib2.0-dev
Are there 2 divergent branches of Glib, like a v1 and v2?
You need to install glib-devel in order to have the glib headers exist on your system. Without the headers, autoconf will mark the library as missing.
You installed glib from source which should have worked. The actual problem was most likely with the paths you chose to install into. The autoconf script may not be looking for glib where you installed it, or it may be looking into another directory first and finding an old version.