I searched sourcery mentor but only sourcery code bench found.
I need the latest version but I find only some old version on webs.
arm-none-linux-gnueabi doesn't describe a unique toolchain from a specific supplier however you need to get the toolchain that's matching with your target or deliver new libraries to your target probably ending up creating a new file tree.
Otherwise Linaro provides quite a few toolchains:
https://launchpad.net/linaro-toolchain-binaries
https://launchpad.net/gcc-arm-embedded
Related
Following this post, where I have used these instructions to install NVIDIA's OpenCL SDK. The clinfo tool detects a 1.2 OpenCL version correctly. However, The below CMakeLists.txt file:
cmake_minimum_required(VERSION 3.1)
project(OpenCL_Example)
find_package(OpenCL REQUIRED)
include_directories(${OpenCL_INCLUDE_DIRS})
link_directories(${OpenCL_LIBRARY})
add_executable(main main.c)
target_include_directories(main PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
target_link_libraries(main ${OpenCL_LIBRARY})
copied from here, detects the wrong version of OpenCL 1.1 :
-- Looking for CL_VERSION_1_1 - found
-- Found OpenCL: C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v3.2/lib/Win32/OpenCL.lib (found version "1.1")
I would appreciate it if you could help me know what is the problem and how I can resolve it.
P.S.1. you may use the below dummy main.c C code just for testing
#include <CL/cl.h>
#include <stdio.h>
int main() {
printf("Hello, World! \n");
return 0;
}
P.S.2. Following this Tweet, I ran the cmake .. --debug-find command and got this log. But still not sure what is the problem.
P.S.3. Following this Tweet, it turns out that I had installed a very outdated CUDA toolkit. Uninstalling that, now I get
-- Found OpenCL: C:/Program Files (x86)/IntelSWTools/system_studio_2020/OpenCL/sdk/lib/x86/OpenCL.lib (found version "2.2")
which is Intel's SDK. It was basically the second result on Google search " NVIDIA OpenCL SDK download", firstly being completely confusing. So I had to uninstall it and install the latest version from here. NVIDIA could at least mention that one has to install CUDA toolkit to get the OpenCL SDK!
NVidia Cuda v3.2 was released according to this on Nov 2010 and OpenCL 1.2 spec was released one year later on November 15, 2011. So I suspect cmake is detecting OpenCL 1.1 correctly.
If you have another SDK installed and you want cmake to detect OpenCL 1.2 despite having another SDKs supporting older version you need to specify that information in cmake. Otherwise it will find the first OpenCL on the search path and stop. So it should be specified find_package(OpenCL 1.2 REQUIRED) or as #squareskittles pointed find_package(OpenCL 1.2 EXACT REQUIRED) if you want exact version.
However you may need to add other SDKs paths to PATH or specify them in cmake so that it has a chance to examine other OpenCL versions. If you have a look at find cmake macros content they contain some typical search paths specified and if you have SDK installed in other not standard path you have to tell that cmake yourself. That is especially the case on Windows where you don't have standard more specific install paths for includes or libraries like for example on Linux. On Windows there is really Program Files but that is too generic and cmake would have to search through it recursively and I'm not sure if that is even supported.
I suspect you may have nvidia cuda 3.2 toolkit path added to PATH only or you specified that path in cmake only. So here would the problem lie. Adding other SDKs paths may resolve the issue.
Also I think clinfo checks runtime OpenCL installations meaning it can be any vendor OpenCL.dll which supports OpenCL 1.2 on your NVidia GPU and cmake checks in SDK's header which OpenCL version your installed SDK supports. So here can be the discrepancy. In this case you may need to install newer cuda toolkit.
I want to run an application based on Qt5 shared objects.
Although I have apt installed qt5-default, qttools5-dev and qttools5-dev-tools I get the error bellow:
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.7' not found
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5' not found
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5: version `Qt_5' not found
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5: version `Qt_5' not found
I have also tried to change some environment variables as LD_LIBRARY_PATH and DYLD_LIBRARY_PATH, resulted in no success!
What do you suggest?
When you built your application, which version of Qt5 did you build against? You can see this in QtCreator by looking at the currently selected kit:
If you just installed QtCreator from binary, it is shipped with it's own set of Qt5 shared libraries that your application is linked against, however your OS' version of those libraries (those installed from apt-get and similar) may not match.
When you try to run the application on it's own outside QtCreator, it may try to link against the OS version of the libs which are usually much older.
There are many ways to resolve this. One way, which would be preferred if you don't care for the newest version of Qt, is simply building towards the Qt libs supploed by the OS. You can do this by creating a new kit that specifies to build against the OS' libraries following this procedure.
Another way is shipping the shared libraries that you used from QtCreator together with the application so that those will override the OS ones. Usually just chucking them into the same folder as the executable will do the trick, as they will be found before the ones under /usr/lib/whatever etc.
Yet another way is to build your own static version of Qt and link with that. This has some benefits and some drawbacks. This is an advanced topic, so I won't go into detail (you can see here). But in this case the Qt libs are built into your app and will not depend on any external Qt libs version.
I am using the cmake to build my project. However, I need to build this project on a machine that I do not have the permission to install any software on it. I thought I can use the generated makefile but it has the dependencies on CMake,and says cmake:command not found.Is there any solution that force the generated makefile do not have any cmake related command such as check the system version? Thanks
Is there any solution that force the generated makefile do not have any cmake related command such as check the system version?
No. There is no incentive for cmake to provide such an option, because the whole point of the cmake system is that the cmake program examines the build machine and uses what it finds to generate a Makefile (if you're using that generator) appropriate to the machine. The generated Makefiles are tailored to the machine, and it is not assumed that they would be suitable for any other machine, so there is no reason to suppose that one would need to use one on a machine that does not have cmake. In fact, if you look at the generated Makefiles you'll find all sorts of dependencies on cmake.
Depending on the breadth of your target machine types, you might consider the Autotools instead. Some people dislike them, and they're not a good choice if you want to support Microsoft's toolchain on Windows, but they do have the advantage that an Autotools-based build system can be used to build software on machines that do not themselves have the Autotools installed.
one easy solution is to use static libraries and the 'static' parameter in the command line.
Then you should be able to drop the executable on the target machine and run it.
I need to use the GCC compiler version 4.1.1 on Windows, from a MingGW distribution if possible.
I've been looking for a way to install an older version with the mingw-get installer but I don't find any option to select a specific version. Nevertheless, the official Sourceforge repository doesn't seem to contain the files for this version (http://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/)
After searching in alternative distributions like Nuwen or TDM-GCC I haven't found a release including GCC 4.1.1.
My question is, is there any place to obtain a MinGW with GCC 4.1.1, or is there another way to obtain this toolchain?
Thanks.
I'm trying to cross-compile the OpenCV library for using it on an embedded system running Montavista Linux(the system has an ARM926 processor). I've managed to configure and generate the makefiles; the sources are built OK, including the 3rd party libraries. The trouble comes at link time. For some reason libtool picks some libraries from the host system (libjpeg, libtiff, libpng) and tries to link them against the ARM9 object files(which evidently is wrong). The error I get is
/usr/lib/libpng12.so: could not read symbols: File in wrong format.
I couldn't and I still can't figure out what exactly is wrong with my setup(I even tried to build the library directly on the ARM9 system but unfortunately it has a very small amount of RAM and gcc chokes). I also modified the LD_LIBRARY_PATH envvar to contain the target's system libraries and exported it before running configure and make.
Below is what I pass to configure:
LDFLAGS="-L/opt/Montavista/pro/devkit/arm/v5t_le/target/usr/lib" CFLAGS="-I/opt
/Montavista/pro/devkit/arm/v5t_le/target/usr/include -fsigned-char -march=armv5te
-mtune=arm926ej-s -ffast-math -fomit-frame-pointer -funroll-loops" CC=/opt/Montavista
/pro/devkit/arm/v5t_le/bin/arm_v5t_le-gcc CXXFLAGS="-fsigned-char -march=armv5te
-mtune=arm926ej-s -ffast-math -fomit-frame-pointer -funroll-loops" CXX=/opt/Montavista
/pro/devkit/arm/v5t_le/bin/arm_v5t_le-g++ ./configure --host=armv5tl-montavista-linux-
gnueabi --without-gtk --without-v4l --without-carbon --without-quicktime --without-
1394libs --without-ffmpeg --without-imageio --without-python --without-swig --enable-
static --enable-shared --disable-apps --prefix=/home/dev/Development/lib
I found this question on SO but unfortunately it does not provide a solution for me.
I'm using gcc version 4.2.0 (MontaVista 4.2.0-16.0.32.0801914 2008-08-30) on Montavista Linux for ARM(Leopard board powered by a TI DM365), OpenCV 2.0.0. My host system is Ubuntu 10.4.
Any pointers on how to tackle this issue would be of very much help.
Thanks
[UPDATE][SOLVED]: The autotools based method of generating the makefiles for OpenCV 2.0.0 seems to be broken when trying cross-compiling(or for some odd reason it did not work for me). I used the CMake GUI and specified a proper toolchain.cmake file and everything went smooth. See the answer below.
Procedure for cross-compiling OpenCV 2.0 for ARM using CMake GUI
Requirements
OpenCV 2.0 source tarball
CodeSourcery ARM cross-compiler v2009q1 or v2010.09(both tested)
Ubuntu 10.10/11.04 host machine
CMake >= v2.6 with CMake GUI
Steps
Unpack somewhere on your host machine the OpenCV tarball; cd to that location and create a build directory
Open the CMake GUI. Select:
Where is the source code:==path to the folder you unpacked the OpenCV tarball
Where to build the binaries:==path to the build folder you created in the first step
Add a new entry named COMPILER_ROOT as a path entry and set its value to the path of your cross compiler e.g. /opt/CodeSourcery/Sourcery_G++_Lite/bin
Set CMAKE_TOOLCHAIN_FILE to the path of your toolchain file on your host machine; example toolchain.cmake:
# this one is important
SET(CMAKE_SYSTEM_NAME Linux)
#this one not so much
SET(CMAKE_SYSTEM_VERSION 1)
# specify the cross compiler
set(COMPILER_ROOT /opt/CodeSourcery/Sourcery_G++_Lite/bin)
set(CMAKE_C_COMPILER ${COMPILER_ROOT}/arm-none-linux-gnueabi-gcc)
set(CMAKE_CXX_COMPILER ${COMPILER_ROOT}/arm-none-linux-gnueabi-g++)
# specify how to set the CMake compilation flags
# CPP
SET(CMAKE_CXX_FLAGS $ENV{CXX_FLAGS} CACHE FORCE "")
SET(CMAKE_CXX_FLAGS_DEBUG $ENV{CXX_FLAGS_DEBUG} CACHE FORCE "")
SET(CMAKE_CXX_FLAGS_RELEASE $ENV{CXX_FLAGS_RELEASE} CACHE FORCE "")
SET(CMAKE_CXX_FLAGS_RELWITHDEBINFO $ENV{CXX_FLAGS_RELWITHDEBINFO} CACHE FORCE "")
SET(CMAKE_CXX_LINK_FLAGS $ENV{CMAKE_EXE_LINKER_FLAGS} CACHE FORCE "")
SET(CMAKE_C_LINK_FLAGS $ENV{CMAKE_EXE_LINKER_FLAGS} CACHE FORCE "")
SET(CMAKE_CXX_LINK_FLAGS_RELEASE $ENV{CMAKE_EXE_LINKER_FLAGS} CACHE FORCE "")
SET(CMAKE_CXX_LINK_FLAGS_DEBUG $ENV{CMAKE_EXE_LINKER_FLAGS} CACHE FORCE "")
# C
#SET(CMAKE_C_FLAGS $ENV{C_FLAGS} CACHE FORCE "")
SET(CMAKE_C_FLAGS_DEBUG $ENV{C_FLAGS_DEBUG} CACHE FORCE "")
SET(CMAKE_C_FLAGS_RELEASE $ENV{C_FLAGS_RELEASE} CACHE FORCE "")
SET(CMAKE_C_FLAGS_RELWITHDEBINFO $ENV{C_FLAGS_RELWITHDEBINFO} CACHE FORCE "")
# where is the target environment
SET(CMAKE_FIND_ROOT_PATH ${COMPILER_ROOT})
# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
Tweak other settings to your needs e.g.EXECUTABLE_OUTPUT_PATH LIBRARY_OUTPUT_PATH CMAKE_BUILD_TYPE CMAKE_CFLAGS_DEBUG CMAKE_CFLAGS_RELEASE, third party libraries you want to build with etc.
Press Configure then Generate; check for eventual errors(everything should run smoothly but you never know)
If everything went OK in the generation phase then cd to the build folder, type make then sit back and relax until the build process is done
It seems you are using an old version of OpenCv since it still uses the .configure mechanism. This is good in a sense, because CMake is not known to be cross-compilation friendly.
LDFLAGS="-L/opt/Montavista/pro/devkit/arm/v5t_le/target/usr/lib"
This is were the linker will look for libraries. It should be enough. Are you sure the libraries needed by OpenCV are in this PATH ?
A first Hack would be to rename the libraries in /usr/lib, so that the linker don't find them, and see if it find the target libraries. This is ugly, maybe more than ugly. Don't do it. Yet.
A second solution is to do native compilation. But it an emulated ARM box, not on real, slow and memory poor hardware. I have no experience either with this kind of cross-compile method, but here is a link to get you started.
EDIT
Wait !!, Which version of OpenCV are you using ? I thought OpenCV was not using .configure et al. ? There is probably a more elegant solution using .configure flags. Or maybe non optionnal libraries are somehow hardcoded.
Interestingly I'm currently trying to get version 2.1.0 to build for ARM. It relies on cmake which is a real pain to try to get ready for cross-compiling. There's no way to specify what toolchain to use, I have to spot the variable names for all binutils, hoping not to forget any. There are still a bunch of magically defined variables that prevent it from building, I'm giving up right now. I'm still seeing some -march=i686 magically appended and some libs referenced from my build system. What a mess !
Maybe when I have time I'll try to downgrade to an older version making use of more standard tools, but cmake clearly complicates the situation here.