Toolchain configuration for softfp using yocto - yocto

I have built images for IMX6 Sabersd using yocto as shown below.
#curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
#repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-3.10.53-1.1.0_ga
#repo sync
#source setup-environment build
#bitbake core-image-minimal
During build time it is getting the gcc-4.8 source and compiling tool chian for IMX6. The toochain is using hard floating point(checked using "./arm-poky-linux-gnueabi-gcc -v" and output is having "--float-with=hard" ), my requirement is the toolchain has to use softfp.
The reason behind this is I am using 3rd party pre-built libraries, which are not compatible for hardfp. So during compilation time I am getting errors as shown below.
ld: error: *Executable* uses VFP register arguments, *Library* does not
ld: failed to merge target specific data of file *Library*
Can you help on how I can change the configuration in yocto to compile tool chain with softfp.
I couldn't find which version of yocto freescale is using, but I could see gcc-4.8 recipies under "poky/meta/recipes-devtools/gcc/".

Given that I do not know what core processor you are using.
The files that you want to modify should be in poky/meta/conf/machine/include/
you could also add something like this in conf/local.conf to override:
TARGET_CC_ARCH = "-march=armv7 -mfpu=vfp -mfloat-abi=softfp"

Related

How do I get a complex non-Yocto makefile-based project to cross-compile in a Yocto layer?

This follows on from
How do I strip and objcopy a built .so file in the Yocto bitbake compile step?
This leads back to considerable background information.
As mentioned in the previous question, I am seeking to build OCA, which I have
as a non-Yocto makefile-based project, in Yocto. The project, which builds
fine outside of Yocto, and even in Yocto, is quite complex. The issue is that it
is not cross-compiling for my target, which is aarch64 armv8-a. It is building
successfully, but for my host machine, which is x86-64. Then Yocto sensibly
refuses to package it, saying "Unable to recognise the format of the input
file".
I changed the compile flags in my makefile to -march=armv8-a, but got the error
"cc1plus: error: bad value ('armv8-a') for '-march=' switch" which seems to
mean that I can't use the host's installed gcc for cross-compiling, but rather a
cross-compiler is needed. I previously custom-added two additional layers, a
sample helloworld and mDNS (see previous questions for lots of background), and
they all cross-compiled fine, so I know that Yocto is basically set up to do it.
What is the method to get the cross-compilation to happen? Do I need to do a lot
of pervasive changes to my project's makefile system? It may not ever have been
designed with Yocto in mind.
I am looking into this: "cross-compile library recipe in yocto":
cross-compile library recipe in yocto
which seems to have some relevant information. Edit: it was only standard stuff that I had seen before; nothing about how cross-compilation gets invoked instead of the host machine's gcc.
Edit: My updated recipe, with the FILES_${PN} added and make changed to
oe_runmake.
DESCRIPTION = "OCA"
PRIORITY = "optional"
SECTION = "protocols"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = "file://oca-1.2.7"
S = "${WORKDIR}/oca-1.2.7/Src"
# Need to override S because BitBake expects the source to be in a dir called
# oca-1.2.7 in the work dir, but it's actually additionally under Src/.
# Need a do_compile, since OCA has a makefile with a non-standard name,
# makefileOCA. Also needs non-standard flags, -f and linuxRelease.
do_compile() {
export CAP_HOME="${WORKDIR}/oca-1.2.7"
oe_runmake -f makefileOCA linuxRelease
}
do_install() {
install -d ${D}${libdir}
cp ../Obj/linuxApp/Release/OcaProtoController.so ${D}${libdir}/OcaProtoController.so
chmod 0755 ${D}${libdir}/OcaProtoController.so
}
FILES_${PN} += "${libdir}/OcaProtoController.so"
Edit: I found some info:
https://www.yoctoproject.org/docs/1.8.1/adt-manual/adt-manual.html
https://www.yoctoproject.org/docs/1.8.1/adt-manual/adt-manual.html#setting-up-the-cross-development-environment
I commented-out the setting of CC and LD in makeOCA.inc.
I did the cleaning actions of deleting the tmp folder from my build-wayland
build dir, and did "bitbake -c cleansstate oca". Then I did "time bitbake oca".
Now it looks like it is using the cross compiler.
The first error I got now is:
~/Yocto/imx-yocto-bsp/build-wayland/tmp/work/aarch64-poky-linux/oca/1.2.7-r0/oca-1.2.7/Obj/linuxApp/Release/OcaAgentProxies.a
aarch64-poky-linux-ld: cannot find crus: No such file or directory
So this is the next question: Can you tell me what "crus" means in "LDFLAGS = crus $#"?

How to build Qtkeychain with Windows?

I'm trying to build my OwnCloud client. I'm using "Generic Build Instructions" from this link - https://doc.owncloud.org/desktop/2.5/building.html.
I'm stuck at 3 step with an error:
Could NOT find Qt5Keychain (missing: QTKEYCHAIN_LIBRARY)
I downloaded Qtkeychain and compiled it using this link - https://github.com/frankosterfeld/qtkeychain/wiki.
Everything is in my C disk. PATHS are set correctly. Can someone tell me what am missing here.
Adding PATH photo:
Adding a photo to be clear what am talking about:
How did you compile qtkeychain?
With the environment variable %QTDIR% set correctly, e.g. C:\Qt\Qt5.6.0\5.6\msvc2015, you should be able to compile qtkeychain
cmake -G "MinGW Makefiles" .
mingw32-make
and get a 32bit file named "libqt5keychain.dll.a".
You can then add the directory containing this file to your Windows path environment variable. This should work (it does for Nextcloud, at least).

Compiling with icc and MAGMAmic cannot find "complex" system file

I am trying to compile a source file with icc compiler and MAGMAmic library. However I get the following error:
icc -c -o direct.o direct.c -O3 -openmp -DADD_ -Wall -DHAVE_MIC -I/opt/intel/mic/coi/include -I/usr/include/intel-coi -I/opt/intel/compilers_and_libraries_2017.2.174/linux/mkl/include:/opt/intel/compilers_and_libraries_2017.2.174/linux/ipp/include:/opt/intel/compilers_and_libraries_2017.2.174/linux/mkl/include:/opt/intel/compilers_and_libraries_2017.2.174/linux/tbb/include:/opt/intel/compilers_and_libraries_2017.2.174/linux/daal/include -I/home/dslavchev/install/magmamic-1.4.0/include -I/home/dslavchev/install/magmamic-1.4.0/contol
icc: command line remark #10411: option '-openmp' is deprecated and will be removed in a future release. Please use the replacement option '-qopenmp'
In file included from /home/dslavchev/install/magmamic-1.4.0/include/magma_types.h(134),
from /home/dslavchev/install/magmamic-1.4.0/include/magmablas_z.h(17),
from /home/dslavchev/install/magmamic-1.4.0/include/magmablas.h(12),
from /home/dslavchev/install/magmamic-1.4.0/include/magma.h(17),
from direct.c(21):
/opt/intel/compilers_and_libraries_2017.2.174/linux/compiler/include/complex(30): catastrophic error: cannot open source file "complex"
#include_next <complex>
^
The MAGMAmic library has compiled correctly and I can run it's test ok.
I have looked at the way testing_dgesv_mic.cpp example compiles and used the same includes and link, however in my case I get the above error.
I have added the following in my .bashrc file in order to get the Intel compilers' and libraries' enviromental variables:
#for MAGMA mic
export MAGMA_PATH=/home/dslavchev/install/magmamic-1.4.0
source /opt/intel/bin/compilervars.sh intel64
source /opt/intel/mkl/bin/mklvars.sh intel64
Any ideas what might cause icc to be unable to include the "complex" file?
The file complex really exists in "/opt/intel/compilers_and_libraries_2017.2.174/linux/compiler/include/complex"
icc vesrion is:
[dslavchev#sl051 results]$ icc -v
icc version 17.0.2 (gcc version 4.4.7 compatibility)
magmamic version is magmamic-1.4.0
EDIT: Removed unnecessary code comment
EDIT2: Added version info.
MAGMAmic is a C++ library and it cannot be used with C code directly.
When icc detects that you want to compile .c++ file it automatically switches to icpc (Intel C++ compiler) which in turn results in the above error.
Solution: Either switch to icpc or rename your files to .c++
This question was answered by mark on the MAGMA forums. Link:
http://icl.cs.utk.edu/magma/forum/viewtopic.php?f=2&t=1587&p=4442#p4442

libswiftDemangle.so on Linux

While compiling Swift on Mac machine, there is a dynamic library libswiftDemangle.dylib created. I need the dynamic library created on Linux machine as well, however, the dynamic library isn't created after a compilation of a source code.
The file CMakeLists.txt at lib/SwiftDemangle/CMakeLists.txt contains:
add_swift_library(swiftDemangle SHARED
SwiftDemangle.cpp
MangleHack.cpp
LINK_LIBRARIES swiftBasic)
directive, however the library isn't created.
I use this command ./swift/utils/build-script -R -c --build-subdir build --install-prefix /mnt/servers/swift/install -j4 to build the project, eventually it runs cmake and ninja to build the project.
Any ideas?
I can take a shot at explaining why the library is not getting built on Linux, even if it's late probably.
The main subdirectory containing the library you mention is:
https://github.com/apple/swift/tree/master/lib
To build the libs in that directory, which are organized in subdirectories, the following CMakeLists.txt is used:
https://github.com/apple/swift/blob/master/lib/CMakeLists.txt.
As can be clearly seen in this file, the library that you mention is only built if the system is OSX/Darwin and not in the Linux case. The relevant code in the aforementioned CMakeLists.txt is:
add_subdirectory(RemoteAST)
add_subdirectory(Sema)
add_subdirectory(Serialization)
if(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
add_subdirectory(SwiftDemangle)
endif()
add_subdirectory(SIL)
add_subdirectory(SILGen)
As you can see it,
if(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
add_subdirectory(SwiftDemangle)
endif()
prevents SwiftDemangle to be built on Linux.
A superficial double check can be to look at:
https://github.com/apple/swift/blob/master/lib/SwiftDemangle/CMakeLists.txt
which will install or simlynk only *.dylib files.
It it worth mentioning that the swift-demangle tool (different from what you asked)
https://github.com/apple/swift/tree/master/tools/swift-demangle
is built on Linux.

How to build levmar using MATLAB?

I am using Windows XP and matlab version is 7.10.0.
I have the levmar(Levenberg Marquardt) package from http://www.ics.forth.gr/~lourakis/levmar/levmar-2.5.tgz
In the README file, we are told to compile in matlab using mex using the following command:
mex -DHAVE_LAPACK -I.. -O -L -L levmar.c -llevmar -lclapack -lblas -lf2c.
I downloaded lapack.lib , blas.lib and f2c.lib for windows
UPDATE:
The original error got resolved after I built a vc project file given in the package.
But now there are some error messages like :
levmar.lib(misc.obj) : error LNK2019: unresolved external symbol _dgemm_ referenced in function _dlevmar_trans_mat_mat_mult
Did you create a file with a mex-function gateway? You can't just compile a c-function for Matlab; you need to do a little bit of work to take care of the I/O between Matlab and the c-code.
If you follow the steps outlined in this document, you should do fine.
You may have a look at immoptibox, which comprises Levenberg-Marquardt algorithm as well.
I just figured it out after searching a while and noticed that the levmar package included a vc project file which i needed to build and it created a file called levmar.lib .
But now I am getting some errors which involves messages like 'unable to resolve external symbols'