I got the problem when installing Caffe with opencv3.0+ and CUDA on Ubuntu 16.04
I also added opencv_imgcodescs and opencv_videoio to my Makefile, but that's not solving the issue.
I have checked several answers on the Caffe user group, but no answers solve my problem.
My error message:
nvcc warning : The 'compute_20', 'sm_20', and 'sm_21' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).
AR -o .build_release/lib/libcaffe.a
LD -o .build_release/lib/libcaffe.so.1.0.0-rc3
/usr/bin/ld: cannot find -lopencv_imgcodecs
/usr/bin/ld: cannot find -lopencv_videoio
collect2: error: ld returned 1 exit status
Makefile:566: recipe for target '.build_release/lib/libcaffe.so.1.0.0-rc3' failed
make: *** [.build_release/lib/libcaffe.so.1.0.0-rc3] Error 1
My setting in Makefile
LIBRARIES += glog gflags protobuf boost_system boost_filesystem m hdf5_hl hdf5 opencv_core opencv_highgui opencv_imgproc opencv_imgcodecs opencv_videoio
My imgcodecs and videoio is under ~/miniconda2/envs/frcnn/include/opencv2/
(fastrcnn) pohsuan#pohsuan-Predator-G9-592:~/miniconda2/envs/fastrcnn/include/opencv2$ ls
aruco dnn.hpp imgcodecs photo structured_light videostab
aruco.hpp dpm.hpp imgcodecs.hpp photo.hpp structured_light.hpp videostab.hpp
bgsegm.hpp face imgproc plot.hpp superres xfeatures2d
bioinspired face.hpp imgproc.hpp reg superres.hpp xfeatures2d.hpp
bioinspired.hpp features2d line_descriptor rgbd surface_matching ximgproc
calib3d features2d.hpp line_descriptor.hpp rgbd.hpp surface_matching.hpp ximgproc.hpp
calib3d.hpp flann ml saliency text xobjdetect.hpp
ccalib flann.hpp ml.hpp saliency.hpp text.hpp xphoto
ccalib.hpp fuzzy objdetect shape tracking xphoto.hpp
core fuzzy.hpp objdetect.hpp shape.hpp tracking.hpp
core.hpp hdf opencv.hpp stereo video
cvconfig.h hdf.hpp opencv_modules.hpp stereo.hpp video.hpp
datasets highgui optflow stitching videoio
dnn highgui.hpp optflow.hpp stitching.hpp videoio.hpp
Where I modified my Makfile.config regarding my Miniconda virtual environment :
ANACONDA_HOME := $(HOME)/miniconda2
PYTHON_INCLUDE := $(ANACONDA_HOME)/include \
$(ANACONDA_HOME)/include/python2.7 \
$(ANACONDA_HOME)/lib/python2.7/site-packages/numpy/core/include \
INCLUDE_DIRS := $(PYTHON_INCLUDE) /usr/local/include /usr/include/hdf5/serial /home/pohsuan/miniconda2/envs/fastrcnn/include
LIBRARY_DIRS := $(PYTHON_LIB) /usr/local/lib /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/hdf5/serial /home/pohsuan/miniconda2/fastrcnn/lib
Maybe uncomment
OPENCV_VERSION := 3
on line 21, if you haven't already.
Worse case, uninstall OpenCV, and install a version less than 3.
I struggled a lot with this, finally decided to use OpenCV 2.4.9.1, and it worked.
Related
After upgrading python 3.8.6 to 3.9.10 using homebrew, my Cython extensions no longer without explicitly adding /usr/local/include (for my Intel MacBook) or /opt/homebrew/include to the include_dirs of my extension.
My setup.py.in:
import os, sys
from numpy.distutils.core import setup, Extension
from Cython.Build import cythonize
link_arguments = []
extra_include_dirs = []
if (sys.platform == 'darwin'):
link_arguments.append("-Wl,-rpath")
link_arguments.append("-Wl,#loader_path/")
if os.path.exists('/opt/homebrew/'):
extra_include_dirs.append("/opt/homebrew/include/")
else:
extra_include_dirs.append("/usr/local/include/")
else:
link_arguments.append("-Wl,-rpath=${CMAKE_SOURCE_DIR}/lib/")
pynwp_extension = Extension(
name="pynwp",
sources=["${CMAKE_CURRENT_SOURCE_DIR}/lambert.f90", "${CMAKE_CURRENT_SOURCE_DIR}/pynwp.f90", "${CMAKE_CURRENT_SOURCE_DIR}/readAtmosphereGen.f90", "${CMAKE_CURRENT_SOURCE_DIR}/ptogrot.f", "${CMAKE_CURRENT_SOURCE_DIR}/bilin1.f", "${CMAKE_CURRENT_SOURCE_DIR}/fl2pres_f.f","${CMAKE_CURRENT_SOURCE_DIR}/message.c","${CMAKE_CURRENT_SOURCE_DIR}/gridWindDirCorrection.F"],
libraries=["HirlamUtils_fPIC", "eccodes_f90", "jasper"],
library_dirs=["${PROJECT_BINARY_DIR}", "${CMAKE_SOURCE_DIR}/build${CMAKE_BUILD_TYPE}/src/libHirlamUtils/", "/opt/homebrew/lib/"],
extra_link_args = link_arguments,
include_dirs=["${CMAKE_SOURCE_DIR}/include", "/usr/lib64/gfortran/modules/",
"${CMAKE_SOURCE_DIR}/build${CMAKE_BUILD_TYPE}"] + extra_include_dirs,
extra_f90_compile_args=["-DLINUX", "-DIS_LITTLE_ENDIAN", "-DUSEWALLTIME", "-DHAS_BLAS", "-DHAS_LAPACK", "-DGRIB32", "-DTIMING", "-DPREC32", "-fno-whole-file", "-g", "-fbounds-check"]
#compiler_directives={'language_level' : "3"}
)
setup(name="pynwp",
author="me",
author_email="me!me.com",
version="1.0.1",
description="Python wrapper for pynwp",
package_dir={"": "${CMAKE_CURRENT_SOURCE_DIR}"},
url="http://emaddc.eu",
license="MIT License",
ext_modules=[pynwp_extension]
)
In the file above, I have hardcoded the location (temporarily) of the homebrew library dir and added some functionality for the include dir based on /opt/homebrew being found. If I remove this from the file, compilation fails as eccodes.mod cannot be found, see the output when I run the command generate by python/CMake manually:
buildDebug git:(master) ✗ /opt/homebrew/bin/gfortran -Wall -g -fno-second-underscore -fPIC -O3 -funroll-loops -I<project_dir>//include -I/usr/lib64/gfortran/modules/ -I<project_dir>//buildDebug -Ibuild/src.macosx-12-arm64-3.9/build/src.macosx-12-arm64-3.9 -I/opt/homebrew/lib/python3.9/site-packages/numpy/core/include -Ibuild/src.macosx-12-arm64-3.9/numpy/distutils/include -I/opt/homebrew/opt/python#3.9/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c -c <project_dir>//src/pynwp/readAtmosphereGen.f90 -o build/temp.macosx-12-arm64-3.9<project_dir>//src/pynwp/readAtmosphereGen.o -DLINUX -DIS_LITTLE_ENDIAN -DUSEWALLTIME -DHAS_BLAS -DHAS_LAPACK -DGRIB32 -DTIMING -DPREC32 -fno-whole-file -g -fbounds-check
f951: Warning: Nonexistent include directory '/usr/lib64/gfortran/modules/' [-Wmissing-include-dirs]
f951: Warning: Nonexistent include directory 'build/src.macosx-12-arm64-3.9/build/src.macosx-12-arm64-3.9' [-Wmissing-include-dirs]
f951: Warning: Nonexistent include directory 'build/src.macosx-12-arm64-3.9/numpy/distutils/include' [-Wmissing-include-dirs]
<project_dir>//src/pynwp/readAtmosphereGen.f90:3:7:
3 | use eccodes
| 1
Fatal Error: Cannot open module file 'eccodes.mod' for reading at (1): No such file or directory
compilation terminated.
This extension is part of a larger project that is build using CMake. When running the gfortran command manually, the same errors indicating that eccodes.mod cannot be found. The file is however located on a default location on the gfortran/gcc search path:
locate eccodes.mod
/opt/homebrew/Cellar/eccodes/2.24.2/include/eccodes.mod
/opt/homebrew/include/eccodes.mod
And the search path for gfortran:
gfortran -E -Wp,-v -
#include <...> search starts here:
/opt/homebrew/include
/opt/homebrew/Cellar/gcc/11.2.0_3/bin/../lib/gcc/11/gcc/aarch64-apple-darwin21/11/include
/opt/homebrew/Cellar/gcc/11.2.0_3/bin/../lib/gcc/11/gcc/aarch64-apple-darwin21/11/include-fixed
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks
End of search list.
Another project uses gcc/ld and has a similar problem. I need to explicitly add LINK_DIRECTORIES(/opt/homebrew/lib) to CMakeList.txt in order for gcc to find the eccodes library. Without that, I get:
gcc-11: warning: this compiler does not support X86 (arch flags ignored)
ld: library not found for -leccodes
collect2: error: ld returned 1 exit status
make[2]: *** [src/smoothModeS-v51/smoothModeS-v51.x] Error 1
make[1]: *** [src/smoothModeS-v51/CMakeFiles/smoothModeS-v51.x.dir/all] Error 2
make: *** [all] Error 2
Adding the paths to CPATH and LIBRARY_PATH had no effect.
This method works but seems hard to maintain. What am I missing and what has changed that gfortran/gcc no longer search in the default paths for but libraries and headers/modules?
EDIT
Just found that the standalone executable that uses similar code as the python extension and also uses eccodes has a similar issue. If I do not include INCLUDE_DIRECTORIES(/opt/homebrew/include) in CMakeLists.txt , I get:
cd <project_dir>/buildDebug/src/collocEHS && /opt/homebrew/bin/gfortran -I<project_dir>/buildDebug -I<project_dir>/include -I<project_dir>/src/readASTERIX2 -I<project_dir>/src/geomag70_linux -I<project_dir>/src/libDTG -fallow-argument-mismatch -ffpe-trap=invalid,zero,overflow -DPREC32 -DLINUX -DIS_LITTLE_ENDIAN -DUSEWALLTIME -DHAS_BLAS -DHAS_LAPACK -DGRIB32 -DTIMING -ffixed-line-length-none -g -fcheck=all -Wall -fcheck=bounds -O0 -g -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk -c <project_dir>/src/pynwp/readAtmosphereGen.f90 -o CMakeFiles/collocEHSv2.dir/__/pynwp/readAtmosphereGen.f90.o
<project_dir>/src/pynwp/readAtmosphereGen.f90:3:7:
3 | use eccodes
| 1
Fatal Error: Cannot open module file 'eccodes.mod' for reading at (1): No such file or directory
compilation terminated.
make[2]: *** [src/collocEHS/CMakeFiles/collocEHSv2.dir/__/pynwp/readAtmosphereGen.f90.o] Error 1
make[1]: *** [src/collocEHS/CMakeFiles/collocEHSv2.dir/all] Error 2
make: *** [all] Error 2
So I guess the problem is unrelated to python but more with gcc/gfortran (gcc version 11.2.0 (Homebrew GCC 11.2.0_3).
EDIT 2
A reboot of the laptop fixed the issue with the python extension build and setup.py requiring additional directories. For normal builds using CMake, I still require the extra INCLUDE_DIRECTORIES and LINK_DIRECTORIES order for gcc/gfortran to find libraries installed by brew in /opt/homebrew (or /usr/local for intel MacBook).
As per homebrew devs, this is desired behaviour: /opt/homebrew and /usr/local are "special" directories to be manually added in e.g., CMake projects. This is explained in my bug report on home-brew's GitHub, see https://github.com/Homebrew/homebrew-core/issues/95561.
I haven't been able to confirm this with documentation.
I am getting a linking error while compiling opencv with cuda on Mac OS X high Sierra (10.13.6).
Error message:
[ 21%] Linking CXX shared library ../../lib/libopencv_cudev.dylib
ld: warning: directory not found for option '-L/Users/unknownn/opencv/-Wl,-rpath,/usr/local/cuda'
ld: warning: directory not found for option '-L-Wl,-rpath,/usr/local/cuda'
ld: library not found for -llib
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [lib/libopencv_cudev.4.0.1.dylib] Error 1
make[1]: *** [modules/cudev/CMakeFiles/opencv_cudev.dir/all] Error 2
make: *** [all] Error 2
I have already tried pretty much every cuda (9, 9.2, 10) and opencv (3.4, 4.0.1) version. Also I am aware that every cuda version requires a specific Xcode version.
I have also tried various cmake versions
I checked for the correct cuda paths in ccmake.
I dont know why the ld warnings appear since /usr/local/cuda exist.
What is -llib?
I had the same problem as well, what's interesting is that the problem does not appear to be with OpenCV, but with cmake.
The FindCUDA that comes with cmake seems to be broken, producing that strange -llib. You can see it during the cmake run as well as:
Extra dependencies: cudart_static lib nppc nppial nppicc nppicom nppidei nppif nppig nppim nppist nppisu nppitc npps cublas cufft -L/usr/local/cuda/lib -L-Wl,-rpath,/usr/local/cuda
(Note the second element "lib", the last two -L... elements will cause problem when you do make install as well)
However, the opencv source package comes with FindCUDA.cmake files that seem to work.
Assuming:
cmake is in /usr/local/share/cmake
opencv source is in ~/opencv
Do the following first:
mv /usr/local/share/cmake/Modules/FindCUDA* /tmp # Or some other back up location
cp -r ~/opencv/cmake/FindCUDA* /usr/local/share/cmake/Modules
Then run your build steps as before (cmake ..., make ..., make install), and hopefully it will work this time (it did for me).
As far as I can tell, cmake has deprecated FindCUDA.cmake, so I'm guessing it won't get fixed any time soon.
Answer by Jack Leow was very usefull, but I had to make farther investigation, because indeed his solution doesn't work any more.
Finally I have found this answer on opencv github by alalek. If in short, he proposes to add following cmake definition:
-DOPENCV_CUDA_FORCE_BUILTIN_CMAKE_MODULE=ON
This solution works to me.
P.S.: Currently I managed to solve few more issues on my way to get awesome opencv build. But currently build is in progress (44%) hope it will be finished in next half an hour, haha!
sorry, although this workaround worked once with opencv-3.4.9 / XCode8.2 (Clang 8) / CMake 3.12, now the switching of the FindCUDA files does not work anymore with the combination
opencv-3.4.9 / XCode9.2 (Clang 9) / CMake 3.16 with the following error:
CMake Error at /Applications/CMake.app/Contents/share/cmake3.16/Modules/FindCUDA.cmake:416 (file):
file failed to open for writing (Permission denied):
/Users/filippo/opencv- 3.4.9/modules/core/CMakeFiles/cuda_compile.dir/src/cuda/cuda_compile_genera ted_gpu_mat.cu.o.depend
Call Stack (most recent call first):
/Applications/CMake.app/Contents/share/cmake-3.16/Modules/FindCUDA.cmake:1363 (cuda_include_nvcc_dependencies)
/Applications/CMake.app/Contents/share/cmake-3.16/Modules/FindCUDA.cmake:1650 (CUDA_WRAP_SRCS)
/Applications/CMake.app/Contents/share/cmake-3.16/Modules/FindCUDA.cmake:1663 (cuda_compile_base)
cmake/OpenCVDetectCUDA.cmake:262 (CUDA_COMPILE)
cmake/OpenCVUtils.cmake:1513 (ocv_cuda_compile)
cmake/OpenCVModule.cmake:927 (ocv_add_library)
cmake/OpenCVModule.cmake:848 (_ocv_create_module)
modules/core/CMakeLists.txt:81 (ocv_create_module)
I had to update XCode to the 9.2 because I had a "nullability" compiling error in the building opencv-3.4.9 probably caused by Clang.
I am currently trying to set up a Go project, and considering I am running Windows, while the other 2 developers are working on a Mac, I have some trouble with installing a few packages.
After trying to install the packages with cmd, I was only able to install 2 out of 4. The other two needed gcc.
Therefore, I installed MinGW. I was able to install a third package that way, but now I am stuck on https://github.com/mikkyang/id3-go.
It seems to depend on another underlying project, https://github.com/djimenez/iconv-go. The moment I try to go install id3-go, I am always left with this error:
src\github.com\djimenez\iconv-go\converter.go:8:19: fatal error: iconv.h: No such file or directory
Somehow, I need to use libiconv with MinGW, but I have no idea how to connect both parts. I'm not really an expert in that field, so any help would be appreciated a lot. I already downloaded libiconv for Windows.
Related issue for additional information I found on the github project:
https://github.com/mikkyang/id3-go/issues/21
EDIT: I made some progress on the whole problem. I now got all the files I need, but now I am stuck with this warning:
# github.com/djimenez/iconv-go
E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -liconv
collect2.exe: error: ld returned 1 exit status
I tried to add the libiconv2.a from my libiconv installation to the mingw32 lib folder, but then this is what I end up with:
# github.com/djimenez/iconv-go
E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib/../lib/libiconv.a when searching for -liconv
E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib/../lib\libiconv.a when searching for -liconv
E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib/libiconv.a when searching for -liconv
E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib\libiconv.a when searching for -liconv
E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib/../lib/libiconv.a when searching for -liconv
E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib/libiconv.a when searching for -liconv
E:/Tools/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -liconv
collect2.exe: error: ld returned 1 exit status
I have no idea how to proceed from here.
I've met the same problem when I want to go install github.com/google/gopacket which need CGO. It's because your libiconv2.a is generated by other compiler, so it's incompatible with mingw32 compiler as the error message says. We need generate the static lib with the mingw32 toolset:
find libiconv-2.dll(the coresonding dynamic library) in your PC
run gendef(located in C:\TDM-GCC-64\x86_64-w64-mingw32\bin in my 64-bit Windows ) on those files gendef libiconv-2.dll, this will generate libiconv2.def file
Then generate the static library:
dlltool --as-flags=--64 -m i386:x86-64 -k --output-lib libiconv2.a --input-def libiconv2.def
copy libiconv2.a to proper location.
Since several versions of GCC and Ubuntu I am experiencing annoying issues with paths and naming of several header and object files that are necessary for the installation of GCC.
Description: After installing ubuntu (e.g. in my case 12.04) and installing all prerequisites of the gcc, I run the following commands:
sudo mkdir /usr/local/stow/gcc-4.8.0
./configure --prefix /usr/local/stow/gcc-4.8.0
make
sudo make install
For the sake of completeness, the rest of the installation procedure:
cd /usr/local/stow
sudo stow -t /usr/local/ gcc-4.8.0
gcc -v
However, this simple and proper way of installing gcc has some issues during the 'make' step with the following error messages:
1.) The problem with 'stubs.h'
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
which can be fixed with the following commands added to ~/.bashrc:
if [ -z "$CPATH"]; then
export CPATH="/usr/include/i386-linux-gnu"
else
export CPATH=$CPATH:"/usr/include/i386-linux-gnu"
fi
2.) The problem with 'crti.o', 'crtn.o', and 'crt1.o'
/usr/bin/ld: cannot find crti.o: No such file or directory
/usr/bin/ld: cannot find crtn.o: No such file or directory
/usr/bin/ld: cannot find crt1.o: No such file or directory
which can be fixed with the very ugly solution:
sudo ln -s /usr/lib/i386-linux-gnu/crti.o /usr/lib/i386-linux-gnu/crtn.o /usr/lib/i386-linux-gnu/crt1.o /usr/lib
since - and I don't know why - the following commands do not solve the problem during linking steps of 'sudo make install'
if [ -z "$LIBRARY_PATH"]; then
export LIBRARY_PATH="/usr/lib/${multiarch}"
else
export LIBRARY_PATH=$LIBRARY_PATH:"/usr/lib/${multiarch}"
fi
if [ -z "$LD_LIBRARY_PATH"]; then
export LD_LIBRARY_PATH="/usr/lib/${multiarch}"
else
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:"/usr/lib/${multiarch}"
fi
(With these solutions I could compile GCC-4.7.2 on Ubuntu 12.04. - I have still issues compiling GCC-4.8.0 on Ubuntu 12.04, but that's different topic.)
My questions are: Does anybody know the reason/background that we have these issues? Does anybody know a proper solution? (With "proper solution" I mean a solution that does not require setting environment variables or symbolic linking libraries to different directories. To me these kind of changes are ugly, since they require changes to the system that one may not be able to trace back or redo.)
In the root folder of your GCC source execute ./contrib/download_prerequisites script.
These are the issues i encountered while compiling GCC 4.8.0 on Ubuntu 12.04 with solutions.
This might help you.
Compilation guide for compiling GCC 4.8 on ubuntu 12.04
ERROR 1
configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
their locations. Source code for these libraries can be found at
their respective hosting sites as well as at
ftp://gcc.gnu.org/pub/gcc/infrastructure/. See also
http://gcc.gnu.org/install/prerequisites.html for additional info. If
you obtained GMP, MPFR and/or MPC from a vendor distribution package,
make sure that you have installed both the libraries and the header
files. They may be located in separate packages.
SOLUTION
Download and install gmp version >=4.3.2 package because mpc needs higher version
download the source code from gmplib.org
compile the source code and install
while compiling gmp see ERROR 2 for help
Installed gmp version 5.1.1
Download and install mpfr package
Installed mpfr version 3.1.2
Download and install mpc package
Installed mpc version 1.0
Download the packages from
http://ftp.gnu.org
ERROR 2
Error while compiling gmp library
checking for suitable m4... configure: error: No usable m4 in $PATH or /usr/5bin
SOLUTION
sudo apt-get install m4
http://ubuntuforums.org/showthread.php?t=850491
ERROR 3
Cannot find g++ compiler
I got this error because I installed the OS recently and had not installed the compilers.
SOLUTION
sudo apt-get install build-essential
This installs all the standard build essential software
ERROR 4
checking for i686-pc-linux-gnu-gcc... /home/suhastheju/projects/gcc/gcc-4.8.0/host-i686-pc-linux-gnu/gcc/xgcc -B/home/suhastheju/projects/gcc/gcc-4.8.0/host-i686-pc-linux-gnu/gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include
checking for suffix of object files... configure: error: in `/home/suhastheju/projects/gcc/gcc-4.8.0/i686-pc-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[2]: *** [configure-stage1-target-libgcc] Error 1
make[2]: Leaving directory `/home/suhastheju/projects/gcc/gcc-4.8.0'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/suhastheju/projects/gcc/gcc-4.8.0'
make: *** [all] Error 2
SOLUTION
Though gcc documentation specify , that , we can provide the path of gmp
and mpfr installtion through –with-gmp and –with-mpfr flag ,
but unfortunately , i tried to give the path but it didnt work.
I am not in position to say final word about , this , whether it is a bug
in build script or something else , but bellow is the solution of the problem.
while building , add gmp and mpfr installation path in LD_LIBRARY_PATH environment
variable. Do as follows
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
If you have the libraries in different path, add the path where libraries are present
ERROR 5
libbackend.a(tree-vect-data-refs.o):tree-vect-data-refs.c:(.text+0x87da): more undefined references to `vector_type_mode(tree_node const*)' follow
collect2: error: ld returned 1 exit status
make[3]: *** [cc1] Error 1
make[3]: Leaving directory `/home/suhastheju/projects/gcc/gcc-4.8.0/host-i686-pc-linux-gnu/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/suhastheju/projects/gcc/gcc-4.8.0'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/suhastheju/projects/gcc/gcc-4.8.0'
make: *** [all] Error 2
SOLUTION
recompiled the source code from begining, It worked magically
make clean all
ERROR 6
/home/suhastheju/projects/gcc/gcc-4.8.0/host-i686-pc-linux-gnu/gcc/../.././gcc/gcov.c:416: undefined reference to `gcc_init_libintl()'
collect2: ld returned 1 exit status
make[3]: *** [gcov] Error 1
make[3]: Leaving directory `/home/suhastheju/projects/gcc/gcc-4.8.0/host-i686-pc-linux-gnu/gcc'
SOLUTION
Added -I/usr/include
I'm trying to create a project as a shared library in OS X using CMake 2.8 and gcc 4.6 (from macports). When CMake gets to the point of linking my library into a .dylib, I get the following error from gcc:
g++ -dynamiclib -headerpad_max_install_names -o libmycoollibrary.dylib etc...
g++: error: unrecognized option '-h'
make[2]: *** [libnrtCore.dylib] Error 1
make[1]: *** [CMakeFiles/nrtCore.dir/all] Error 2
make: *** [all] Error 2
This -headerpad_max_install_names seems to be the problem, but I've never seen it before. Does anyone know how to either get CMake to not include this option, or to get GCC to accept this option?
You can re-build cmake to fix this -- it's apparently generating code for the XCode / Darwin version of g++ (a special version of 4.2), which accepts a number of non-standard linker flags.
Just change the Modules/Platform/Darwin*.cmake files and re-build. The culprit lines look like this:
SET(CMAKE_CXX_LINK_FLAGS "-Wl,-search_paths_first -headerpad_max_install_names")