I build sample code with cross compile linaro. I have two situations
Situation 1:
I download gcc-linaro-5.5.0-2017.10-x86_64_arm-linux-gnueabihf from linaro website and extract it to path /home/xxx/opt/toolchains. I also
export
PATH=$PATH:/home/xxx/opt/toolchains/gcc-linaro-5.5.0-2017.10-x86_64_arm-linux-gnueabihf/bin
Then i use eclipse for testing some simple example codes with Cross Settings /home/xxx/opt/toolchains/gcc-linaro-5.5.0-2017.10-x86_64_arm-linux-gnueabihf/bin. But when i compile, i get this error.
/home/xxx/opt/toolchains/gcc-linaro-5.5.0-2017.10-x86_64_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.5.0/../../../../arm-linux-gnueabihf/bin/ld:
cannot find crt1.o: No such file or directory
/home/xxx/opt/toolchains/gcc-linaro-5.5.0-2017.10-x86_64_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.5.0/../../../../arm-linux-gnueabihf/bin/ld:
cannot find crti.o: No such file or directory
I found and know that crti.o and crt1.o in /home/xxx/opt/toolchains/gcc-linaro-5.5.0-2017.10-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/libc/usr/lib.
Situation 2:
When i follow another way. The first, i install
sudo apt-get install gcc-arm-linux-gnueabihf
Then in eclipse path of Cross Settings i config /usr/bin/ and build. Everything is OK.
So with situation 1, How I setup correctly in Eclipse? Thank for your support.
Related
I'm starting to work with llvm infrastructure, and i'm interested in the use of the debugger tool lldb instead of default gdb. I followed the tutorial of installation of clang (Linux System, through svn options) and now wanted to know if is possible to install lldb only, instead of rebuild the whole structure of llvm. I don't found a especific documentation for that and i don't know any especific forum for llvm, so if anyone know some forum of llvm,
Sorry about my english, i'm a brazilian developer.
I actually found the solution yesterday, but was not sure how the policies to answer your own questions work here, but according to this it's allright. :)
In fact, it is quite simple.
First, you must identify the directory 'src-root' of the installation of the tools llvm/clang using the command 'llvm-config':
llvm-config --src-root
Once you find the directory, you must navigate to the path $src-root/tools and checkout the lldb:
svn co http://llvm.org/svn/llvm-project/lldb/trunk lldb
The next step is go to the build directory, if the steps of the tutorial has been followed, is just necessary to clean the build directory:
rm -rf *
Now, is the step of building the lldb, I personally have used the autoconf options (classical configure make && make install), but cmake can be used as well. When the configure script runs, the binaries of llvm and clang already installed will be detected, avoiding rebuild the whole structure of llvm/clang.
The parameters of the configure script can be changed, I use as follow because I intend to use the llvm libraries:
../llvm/configure --enable-optimized --enable-assertions --enable-shared --enable-targets=host
Then:
make -j4
sudo make install
where -j4 option is the number of threads (jobs) to be created.
Reference: http://www.felixmorgner.ch/en/blog/building-clang-lldb-and-libc-on-ubuntu/
When I tried to run an installer that uses GLEW as one of its dependencies, I got:
fatal error: GL/glew.h: No such file or directory
Downloaded glew1.10 from the official site and installed according to given instructions.
After that I got the same error again- did some research and copied glew.h to /usr/include/GL/glew.h. Ran the installer again and this time got:
/usr/bin/ld: error: cannot find -lGLEW
To my understanding this is a a common error in Linux for many projects and many libraries, probably I should copy some files from the source folder or add some path to an environment variable, what should i do?
I know that there are apt-get packages- libglew1.6-dev and libglew1.6, but its built upon glew1.6, which works but is probably out-dated for what i'm trying to build.
The automatic installer is node.js's npm, and what causes this error is trying to install node-webgl module.
Solved.
As it turned out, the installation seems to have placed the needed files inside /usr/lib64, and the linker searched for those files inside /usr/lib/ which probably is the right behavior in most cases.
Since i'm not familiar with node.js's npm (and with linking in general), my fix was as follows:
sudo cp /usr/lib64/libGLEW* /usr/lib/
sudo cp /usr/lib64/pkgconfig/* /usr/lib/pkgconfig/
Meaning, I reconstructed the same hirarchy inside the /usr/lib folder. This is probably not a best practice, but it works.
I previously had some troubles updating old code that still needed a not supported compiler and expensive libraries to a version with gfortran in Eclipse on Windows. I let it rest for a while and recently I took a whole other approach, rebuilding the program from scratch, developping on a ubuntu machine, but now I want to bring it back to a windows machine so that my co-workers can contribute on it.
The status:
Program compiles, runs and gives good results on an ubuntu machine with the GCC GNU compiler
Windows 7 machine, 64bit
Cygwin installation (for gnu fortran) with lapack and liblapack-devel (however, I don't use these, because I compile blas and lapack manually)
(C:/cygwin/lib added to windows Path)
Original Issue:
The program compiles in cygwin (by calling the make-command, calling the make command with the makefile situated here: http://thijsvandenbrande.be/phd/hamfemInstall/makefile
This returns the file hamfem.exe which returns the following error when runned by double-clicking on it in windows: The program can't start because cyglapack-0.dll is missing from your computer. Try reinstalling the program to fix this problem.
When running the executable from cygwin, by calling the ./hamfem.exe command the executable starts to run. However, I want a solution so that I can give this executable to my co-workers so that they can change the input files (located in a folder in that has a relative path to the executable).
Going further on the comments below, I tried the next things:
Adding the exact path to the C:\cygwin\lib\lapack\cyglapack-0.dll file in windows path and even rebooting afterwards doesn't help.
adding a -static to the makefile before calling the library, resulting in dependency errors because I use two commands of the lapack library that depend on quite a lot of other commands (DPBTRF and DPBTRS). These commands are used in the mainprog.f90 module. The error: /usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../liblapack.a(dpbtrf.f.o): In function 'dpbtrf':
/usr/src/debug/lapack-3.4.2-1/SRC/dpbtrf.f:277: undefined reference to 'dtrsm_'
and a couple of more lines stating the dependencies.
add the liblapack.a file to the src folder, but compiler always goes back to the lapack in cygwin
On the website of lapack you can normally download the functions with their dependencies (example DPBTRF), but these are not available anymore. Does anyone have another idea how to include these two functions and their dependencies in a static library-file that I can compile beforehand and add to the src-folder?
Current (semi-)Fix
The next thing worked (a bit) for me: following the instructions on http://gcc.gnu.org/wiki/GfortranBuild to manually build libblas.a and liblapack.a in the /usr/src folder of Cygwin and refering to this folder in the makefile. The updated makefile can be found here: http://thijsvandenbrande.be/phd/hamfemInstall/makefileNew
The code compiles nicely on Windows by running the make command from cygwin (next step in the process, running it out of Eclipse) and i get a .exe file that can be run by double clicking it and that keeps running if I move it with its folder to another location. Because this process is quite labour intensive, figuring it all out, I added the answer here below, stating the commands you have to parse to cygwin in order to make it work.
For your information: my file structure looks like this (after the build, I move the .exe file one folder up, both in the linux version as the windows version):
hamfem.exe
in
input.txt
NGCR_building01.txt
out
(empty folder for output files of the routine)
src
hamfem.f90 (main file)
mainprog.f90 (file that contains the commands from lapack)
...(a bunch of other modules)
makefile
I figured things out myself, with some pointers from all over stackoverflow. In order for others to help them resolve similar issues, I would like my work method here so that the question is fully documented.
The issue can be resolved by clean building the Lapack library !and the Blas library on your local machine in cygwin and pasting the liblapack.a and libblas.a file to the library folder that you refer to in the makefile. The errors that were casted by calling Lapack staticly where a result of some routines of Blas used in the two commands.
These are the steps I followed:
download the lapack.tgz and blas.tgz files from the website and past them in the C:\Cygwin\usr\src folder
Extract these files with the following commands in cygwin:
cd /usr/src
tar -xvzf lapack.tgz
tar -xvzf blas.tgz
Build the two library files with the commands shown below in Cygwin. Compiling Lapack can take a while and will result in some errors in the end because of some missing links in the test files. These tests are run for accuracy tools. A more detailed look into the make.inc file is needed to resolve these issues.
cd $HOME
cd /usr/src/BLAS
make
mv blas_LINUX.a ../libblas.a
cd ../lapack-3.4.2
mv make.inc.example make.inc
make
mv liblapack.a ../liblapack.a
check the makefile included in this repository for the correct linking to the libraries. These should say /usr/src and -static -llapack -lblas, the other options are for the linux compiler.
I have been trying to do build and use OpenCV 2.3.0 on my Fedora15 Lovelock 64bit machine.
Background:
First, on my 64bit Fedora15, OpenCV2.2.0 seems to be in the locations namely
/usr/share/opencv
/usr/doc
/usr/lib64 &
/usr/bin
I do not find the include files though (in /usr/include). This means that the development package was n t installed. My package manager does not list the development packages when i try to Add/remove software.
I have a need to create applications, some of which just link to 2.2 and others which link to 2.3.O of the OpenCV library.So, I thought the best solution would be to have a separate location for 3rd party libraries that i use for my development . So I created a directory in /local named soft and created an OpenCV directory. A directory structure like this one.
/local/soft/
OpenCV/
OpenCV2.2.0/
source-files
build
OpenCV2.3.0/
source-files
build
installation
share/opencv
doc
include
lib
Now, i tried building OpenCV2.3.0 and i succeeded. I configure CMake to use CMAKE_INSTALL_PREFIX to the directory named "installation" (see above), instead of the default /usr/local/. Clean. huh?
I tried building and installing OpenCv 2.2.0 in the same way. Alas 2.2.0 complains something during the build. So i thought i ll link to the already existing version in the standard locations. BUT, when i try to install the dev packages for 2.2 using my package manager,the development files for x86_64 are not found :-) which means i dont have the headers to link to the libraries in the standard location.
I cant build my executable since linker ld would not find the OpenCV that i have installed in the non-standard location.(although i point it to the exact location using the -L and -l options with gcc in my Eclipse).
Question 1: Am i doing the right thing in maintaining installations in non-standard locations? Is /usr/ the standard location where the package manager will always do the installation?
Question2 : What is the right way of linking to these libraries installed in non-standard locations? Why would not ld recognize my .so files in the lib folder?
sudo g++ logpolar.cpp -o logpolar.o -I /local/soft/OpenCV/opencv2.3.1/installation/include/ -l/local/soft/OpenCV/opencv2.3.1/build/lib/libopencv_core.so
But ld canot find -l/local/soft/OpenCV/opencv2.3.1/build/lib/libopencv_core.so
I checked the lib folder and there sure is a beautiful symbolic link to libopencv_core.so.2.3
The standard approach is to use /usr/local directory structure that already has predefined paths like /usr/local/bin, /usr/local/sbin, /usr/local/include, /usr/local/lib.
You put your software here and everything will JustWork(TM). Every Linux distro (incl. Fedora) is set up so it will load programs (libraries, headers) from this libraries.
If you would use GNU toolchain (autoconf, automake => autotools) you would be fine. With CMake you probably need to setup paths for /usr/local/include and /usr/local/lib.
On the other hand this approach wont let you use multiple versions. You can only have one. The one in /usr/local overrides the system one (installed in /usr/bin) because these paths goes first.
You can keep your approach, it is nothing incorrect. We usually put such a software in the /opt folder, so you would go for /opt/opencv/X.Y where X.Y are the version numbers.
Q2: Read the gcc man page and search for the -L option. You need something like:
gcc ... -I/opt/opencv/2.0/include -lsystem_lib -L/opt/opencv/2.0/lib -lopencv ... ...
Do not forget to set LD_LIBRARY_PATH when running programs in multiple versions to properly load correct version:
LD_LIBRARY_PATH=/opt/opencv/2.0/lib /opt/opencv/2.0/bin/opencv
I am trying to install mod_java on ubuntu.
I have installed the latest java(1.6).
I have configured freeswitch with mod_java module enabled in module.conf.xml
then when i run the make file, it says:
freeswitch_java.h:5:17: error: jni.h: No such file or directory
I have searched through the java installtion folders, but did not find any include folder or jni.h.
Can anyone help, what is being the problem here.
Thanks for reading this question.
I had the same problem. The solution was to run configure with the option --with-java:
./configure --with-java=/usr/lib/jvm/java-1.6.0-openjdk/include/
I don't know if it makes any difference but I added mod_java after building freeswitch without it. It was disabled in my initial build in module.conf.xml but afterwards I ran the above command plus:
make mod_java-install
It worked for me on ubuntu with openjdk. Are you using the Sun JDK? Maybe in the version you have dont have the include folder which has the source files. Try installing the other JDK. Or try and see of ther are some other related packages in apt that will get you the include folder.
Type this linux command to locate your jni.h file on your filesystem.
locate jni.h
you should be able to get it somewhere
in /usr/lib/java directory or some other directory
depending upon your java home.
copy paste the jni.h in src/include folder of your freeswitch src.
It will throw you some more errors for different .h files
just copy all of them to your src/include folder.
in latest freeswitch, installing through Makefile, its not possible to configure as the Makefile downloads and installs. Its possible by modifying the Makefile.in file to add the include path
mod_java_la_CPPFLAGS
-I/usr/lib/jvm/default-java/include \