I've build a Linux image for freescale imx6qpsabreai board and SDK with toolchain which works well on Linux.
Now I want to support development on Windows and following this post I've
downloaded oe meta-mingw into sources/meta-openembedded/meta-mingw
added SDKMACHINE=x86_64-mingw32 to local.conf in my project
however, I can't build new SDK this way.
~/yocto/fsl-community-bsp/build_fsl_framebuffer$ bitbake fsl-image-machine-test -c populate_sdk
Loading cache: 100% |###############################################################################################################################################################################| Time: 0:00:00
Loaded 2 entries from dependency cache.
ERROR: /home/slavskaya/yocto/fsl-community-bsp/sources/meta-openembedded/meta-mingw/recipes-support/libiconv/libiconv_1.14.bb: Error executing a python function in <code>: | ETA: --:--:--
The stack trace of python calls that resulted in this exception/failure was:
File: '<code>', lineno: 13, function: <module>
0009:__anon_35__home_slavskaya_yocto_fsl_community_bsp_sources_poky_meta_classes_devshell_bbclass(d)
0010:__anon_106__home_slavskaya_yocto_fsl_community_bsp_sources_poky_meta_classes_sstate_bbclass(d)
0011:__anon_45__home_slavskaya_yocto_fsl_community_bsp_sources_poky_meta_classes_blacklist_bbclass(d)
0012:__anon_158__home_slavskaya_yocto_fsl_community_bsp_sources_poky_meta_classes_siteinfo_bbclass(d)
*** 0013:__anon_31__home_slavskaya_yocto_fsl_community_bsp_sources_meta_openembedded_meta_mingw_recipes_support_libiconv_libiconv_1_14_bb(d)
File: '/home/slavskaya/yocto/fsl-community-bsp/sources/meta-openembedded/meta-mingw/recipes-support/libiconv/libiconv_1.14.bb', lineno: 28, function: __anon_31__home_slavskaya_yocto_fsl_community_bsp_sources_meta_openembedded_meta_mingw_recipes_support_libiconv_libiconv_1_14_bb
0024:inherit autotools pkgconfig gettext
0025:
0026:python __anonymous() {
0027: if d.getVar("TARGET_OS") != "linux":
*** 0028: return
0029: if d.getVar("TCLIBC") == "glibc":
0030: raise bb.parse.SkipPackage("libiconv is provided for use with uClibc only - glibc already provides iconv")
0031:}
0032:
Exception: TypeError: getVar() missing 1 required positional argument: 'expand'
ERROR: Failed to parse recipe: /home/slavskaya/yocto/fsl-community-bsp/sources/meta-openembedded/meta-mingw/recipes-support/libiconv/libiconv_1.14.bb
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
Also, I am not an experienced C/C++ programmer, but from my point of view mingw doesn't contain compiler for arm architecture, so maybe I just can't get arm toolchain to use on Windows?
meta-mingw builds a cross compile from Linux to Windows (mingw). It then uses this cross compiler to construct a standard toolchain from (mingw) to the target SDK environment. You are using the correct layer, but have a different problem.
It appears that you are using a layer (meta-mingw) that is expecting the newer bitbake semantics:
0027: if d.getVar("TARGET_OS") != "linux":
*** 0028: return
Exception: TypeError: getVar() missing 1 required positional argument: 'expand'
Bitbake used to require two arguments to 'd.getVar', and now only requires one (the second is optional).
I would suggest that you identify which version of oe-core/poky you are using and get a matching version of meta-mingw. (It may be as simple as checking out the correct branch.)
Related
I am trying to cross compile NPM Sqlite3 with sqlcipher support. I am using Ubuntu 16.04 to cross compile for linux armv7 based SOC(system on chip).
So I started with cross-compiling OpenSSL to build sqlcipher for arm. I successfully cross compiled sqlcipher to produce a static library (libsqlcipher.a).
Now I am trying to get the NodeJS side of the project. I need sqlite with sqlcipher support, compiled for arm. I am using SOC SDK to built till now.
I am using node v4.6.1 and npm v2.15.9 to cross compile. I made sure I have the same version installed on Ubuntu as the SOC.
The command I use to cross compile is as follows :
npm install sqlite3 --target_arch=arm --enable-static=yes --build-from-source --sqlite_libname=sqlcipher -fPIC --sqlite=home/onkar/Library/sqlcipher-master/.libs --verbose
I exported the location of the libsqlcipher.a to LDFLAGS. I get the following error when I try to cross compile. Can someone help me with this error?
/home/linuximage/sdk/sysroots/x86_64-angstromsdk-linux/usr/libexec/arm-angstrom-linux-gnueabi/gcc/arm-angstrom-linux-gnueabi/5.2.1/real-ld: error: /home/Library/sqlcipher-master/.libs/libsqlcipher.a(sqlite3.o): requires unsupported dynamic reloc R_ARM_THM_MOVW_ABS_NC; recompile with -fPIC
collect2: error: ld returned 1 exit status
node_sqlite3.target.mk:129: recipe for target 'Release/obj.target/node_sqlite3.node' failed
make: *** [Release/obj.target/node_sqlite3.node] Error 1
Please let me know if you require any additional information, I would be more than happy to provide you with the same.
Thanks,
Onkar
In the first instance, you should check if the -fPIC (position independent code) flag was correctly applied when the libsqlcipher.a file was originally created.
In your output above, it looks like the linker is using the file at:
/home/Library/sqlcipher-master/.libs/libsqlcipher.a
Run the command
objdump -r /home/Library/sqlcipher-master/.libs/libsqlcipher.a | more
... and check for a line close to the start of the output beginning with the text
RELOCATION RECORDS FOR
If you see this line, then the library doesn't contain position independent code.
Disclaimer: I am new here, I've done my best to follow the posting guidelines so please let me know if this needs any extra information. I am also relatively new to Linux development.
Background:
I am in the process of building a library using ActiveMQ-cpp on Linux. I have built and run it successfully on the host Ubuntu PC, but attempting to cross-compile it for the target ARM-based machine is producing some very abstruse errors.
The first step involves building APR (http://apr.apache.org/) using the arm-linux-gcc compiler. After some research, the following command runs the configuration script with little fuss:
CC=/usr/local/arm-linux/bin/arm-linux-gcc ./configure --prefix=/root/apr-arm --host=arm-linux cross_compiling=yes ac_cv_file__dev_zero=no ac_cv_func_setpgrp_void=no apr_cv_tcp_nodelay_with_cork=no apr_cv_process_shared_works=no
This allows the next step - running the makefile.
Current Issue: Entering make on the command line exits prematurely at the following line:
[...]
/root/.local/share/Trash/files/apr-1.5.1/build/mkdir.sh include/private
tools/gen_test_char > include/private/apr)escape_test_char.h
/bin/bash: tools/gen_test_char: cannot execute binary file
make[1]: *** [include/private/apr_escape_test_char.h] Error 126
make[1]: Leaving directory `/root/.local/share/Trash/files/apr-1.5.1'
make: *** [all-recursive] Error 1
Attempted Fixes: A solution to the following question, posted by the asker, has not worked. It is possible that I've not followed the process correctly (Apache Cross Compilation Error ./gen_test_char: cannot execute binary file)
In the same theme, I tried temporarily removing the problem gen_test_char program from its directory but the clever script just rebuilds it.
My aim is to either avoid this error and continue the build process on Ubuntu, or perhaps consider other means of building the library. I have built it with no trouble in VS2013 on Windows, so if it is possible to cross compile that project for ARM architectures I would happily go ahead with that.
APR need gen_test_char to be compiled for system not for arm, why you got "bin/bash: tools/gen_test_char: cannot execute binary file" error because make program is going to execute gen_test_char on your system and if you cross compile then every time you got this error.
To avoid this error please follow below steps:
1) Cross compile APR which is going to fail
2) compile APR for system and copy gen_test_char to cross compiled APR's directory.
3) Again cross compile
After performing above steps you should not get "cannot execute binary file" error.
Cross compile APR which is going to fail
compile APR for system and copy gen_test_char to cross compiled APR's directory.
change the name of gen_test_char to gen_test_char_host
in Makefile file change the name of gen_test_char to gen_test_char_host because make creates it again.
Again cross compile
you may see some struct redefinition which needs to find the file and comment the redefined struct manually.
I've installed Qt SDK 1.2.1, and when I'm building one of the example applications - Haptics Player, for Symbian S60, using Qt 4.7.3.
The example compiles successfully, but it fails on the Deploy step. This is the compiler output:
ERROR: Automatic patching failed at C:\QtSDK\Symbian\SDKs\Symbian1Qt473\bin\createpackage.pl line 357.
make[1]: *** [ok_sis] Error 2
C:\QtSDK\Symbian\SDKs\Symbian1Qt473\epoc32\tools\make.exe: *** [sis] Error 2
01:38:16: The process "C:\QtSDK\Symbian\SDKs\Symbian1Qt473\epoc32\tools\make.exe" exited with code 2.
Error while building project hapticsplayer (target: Symbian Device)
When executing build step 'Create SIS Package'
However, a newly created, empty project runs on my phone successfully, i.e. this error happens in the Example project that ships with Qt SDK, but not for a newly created project.
How do I fix this error?
Upon closer inspection of the compiler output, I noticed this:
Patching: Executable with capabilities incompatible with self-signing detected: "hapticsplayer_patched_caps.exe". (Incompatible capabilities: "ReadDeviceData", "WriteDeviceData".) Reducing capabilities is only supported for libraries.
Patching: Unable to patch the package for self-singing.
Use a proper developer certificate for signing this package.
Apparently, the capabilities WriteDeviceData and ReadDeviceData can't be used for self-signed packages, and require a proper developer's certificate (which is not free, and I don't have it).
Removing those lines from the .pro file fixed the problem, and Haptics Player now compiles:
symbian: {
TARGET.CAPABILITY = WriteDeviceData ReadDeviceData
}
It seems it does not really need those capabilities, I have no idea why they were added. Probably an oversight.
Im trying to set up Klee for a project and Im running into difficulties when testing coreutils as per http://klee.llvm.org/TestingCoreutils.html
src$ $KLEE cut.bc
'main' function not found in module.
*** glibc detected *** /home/klee/Development//klee-build/Debug+Asserts/bin/klee: double free or corruption (!prev): 0x0000000003a79850 ***
The problem is most likely with the llvm build itself, not Klee, because when I dissasemble the .bc files with llvm-dis, only the module ID is there, no actual code
Looking at the build output, what strikes me as odd is this:
Potential incompatible plugin version. GCC: 4.6 (20120301). Expected: 4.6 (20120301)
Defines 'dragonegg_disable_version_check' as env variable to remove this warning
Please note that unexpected errors might occur.
Any ideas are appreaciated.
The problem is with your LLVM version. KLEE is not yet compatible with llvm3.0 or later. Try building one of llvm 2.7 .. 2.9.
I am following the instructions here for cross-compiling GCC. I am on a mac. When I run this command from the gcc source folder: ./configure --target=i586-elf --prefix=/usr/local/cross --disable-nls --without-headers --enable-languages=c,ada,c++,fortran,java,objc,obj-c++,treelang I get this error: configure: error: GMP 4.1 and MPFR 2.2.1 or newer versions required by fortran. When I change the command to this (I couln't compile GMP): ./configure --target=i586-elf --prefix=/usr/local/cross --disable-nls --without-headers --enable-languages=c,ada,c++,java,objc,obj-c++,treelang I get this error:
The following requested languages could not be built: ada
Recognised languages are: c,ada,c++,fortran,java,objc,obj-c++,treelang
which doesn't make sense to me because it says ada is recognized. All other configurations of the enable-languages settings (and when the setting isn't changed and the default is used) give me this error:
/usr/local/cross/i586-elf/bin/ranlib ./libgcov.a
_error_not_here_yet - havent even thought about it - it may even work
make[1]: _error_not_here_yet: Command not found
make[1]: *** [treelang.all.cross] Error 127
make: *** [all-gcc] Error 2
How can I cross compile GCC?
Are you running configure from the gcc source tree? If so: don't do that. Follow the instructions (verbatim) in the page you linked to.
Look carefully and you'll notice that they're running the configure command from outside the gcc source tree.
If your platform is supported by it, the crosstool script (also linked from the bottom of your instructions page) is very helpful.
Edit: As potatoswatter points out in a comment, your installation is probably hosed at this point. Remove the whole tree and start from scratch. (It sounds like it will take too long, and you'll want to take a short cut, but it will be faster in the end if you just start from scratch now.)