ld: unrecognized option '--push-state--no-as-needed' - gcc

My build fails with the following linker error message:
FAILED: : && /usr/bin/g++ -Wall -Wextra -Werror -g -fsanitize=undefined,address -Wno-unused-parameter -fsanitize=undefined,address -rdynamic *.o -o SCE -Wl,-rpath,/opt/qt59/lib /opt/qt59/lib/libQt5Widgets.so.5.9.1 /usr/local/lib/libprotobuf.a -lpthread -lutil -lgrpc++ /opt/qt59/lib/libQt5Gui.so.5.9.1 /opt/qt59/lib/libQt5Core.so.5.9.1 && :
/usr/bin/x86_64-linux-gnu-ld: unrecognized option '--push-state--no-as-needed'
You can see the full build log here. The error is in line 2211 and versions are printed in lines 2104ff.
Which tool causes the error?
Is gcc 7.3.0 using an incorrect linker flag? The ld documentation indicates that --push-state and --no-as-needed are separate commands.
Is ld 2.28 too old to understand the linker flag? The change log doesn't list anything that seems related.
The command && /usr/bin/g++ looks odd, it should be /usr/bin/g++. Using make instead of ninja shows the same linking error.
It builds correctly on Debian testing which is using gcc 7.3.0 as well and ld 2.30, but there doesn't seem to be a working binutils-2.30 ppa for Ubuntu Trusty.
How do I successfully build my project on Travis?

GCC 7 is fixed with 7.3.0-16ubuntu3 (tested on Ubuntu 18.04). This version is available though the Ubuntu Toolchain Test PPA (for 16.04.1 and 14.04).
Tested with Make only, but it should work with Ninja too. Both Sanitizer, ASan and UBsan, enabled.
There's not much related to this problem in the changelog though:
gcc-7 (7.3.0-16ubuntu3) bionic; urgency=medium
Update to SVN 20180415 (r259389) from the gcc-7-branch.
Fix PR libstdc++/85222.
Remove our own PR libstdc++/85222 backport.
Update:
GCC 7 (7.3.0-16ubuntu3) is still broken on Ubuntu 16.04 and earlier.
What you can do to workaround this:
A. Update to Ubuntu 18.04
The problem is fixed on Ubuntu 18.04 (LTS)'s Gcc7.
B. Dockerize and update to Ubuntu 18.04
If an update is not possible, eg. running on a CI system, it's still an option to use Docker and an up-to-date Ubuntu.
C. Disable UB Sanitizer
The Problem occurs only when using GCC7 with UB Sanitizer enabled. As tobias-brüll noted in the comments: Turning the UB Sanitizer off prevents the error.
D. Use Gold Linker
Another workaround posted by makerj: Using the Gold Linker doesn't cause the problem.
Eg. on CMake pass it through the CMAKE_EXE_LINKER_FLAGS:
cmake -DCMAKE_EXE_LINKER_FLAGS=-fuse-ld=gold ..

If option D (from ollo's answer) is not working for you try next commands:
sudo add-apt-repository ppa:jonathonf/binutils --yes
sudo apt-get update -qq --yes
sudo apt-get install -qq --yes --force-yes binutils
This is from: https://github.com/Project-OSRM/osrm-backend/blob/master/scripts/travis/before_install.x86_64-asan.sh
And the issue was discribed here: https://github.com/Project-OSRM/osrm-backend/issues/3216

Related

Not able to install mod_perl in freeswitch 1.6.5

Freeswitch is installed and working as it should. Now i want to install perl module(mod_perl) for that i have uncomment the line
'languages/mod_perl' in freeswitch/modules.conf
and in uncomment the line
'<load module="mod_perl"/>' in /usr/local/freeswitch/conf/autoload_configs/modules.conf.xml
and i am trying this but getting this error,
make mod_perl-install
Error:: /usr/bin/ld: /usr/local/lib/perl5/5.22.1/x86_64-linux/CORE/libperl.a(op.o): relocation R_X86_64_32 against `PL_memory_wrap' can not be used when making a shared object; recompile with -fPIC
I have tried to recompile with '-fPIC' as suggested by the system with these different ways, but without any success,
./configure CONFIGURE_CFLAGS=-fPIC
./configure CONFIGURE_CFLAGS=-fPIC --with-pic
./configure --disable-file --without-pic --disable-shared
Even change the variable in Makefile
from CXXFLAGS = -g -O2
to CXXFLAGS = -fPIC
Yet not able to install mod_perl in Freeswitch 1.6.5.
Any help would be appreciated.
Thanks,
Devang
=============
Okay, got the solution::
Somehow perl's latest version 5.22.1 is not going well with Freeswitch 1.6.5
so i used 5.20.2 and after that try to install mod_perl and i got success.
Thanks though.
solution to your problem is:
install the perl with thread option.

Caffe compilation fails due to unsupported gcc compiler version

I struggle with Caffe compilation. Unfortunately I failed to compile it.
Steps I followed:
git clone https://github.com/BVLC/caffe.git
cd caffe
mkdir build
cd build
cmake ..
make all
Running make all fails with the following error message:
[ 2%] Building NVCC (Device) object src/caffe/CMakeFiles/cuda_compile.dir/util/cuda_compile_generated_im2col.cu.o
In file included from /usr/include/cuda_runtime.h:59:0,
from <command-line>:0:
/usr/include/host_config.h:82:2: error: #error -- unsupported GNU version! gcc 4.9 and up are not supported!
#error -- unsupported GNU version! gcc 4.9 and up are not supported!
^
CMake Error at cuda_compile_generated_im2col.cu.o.cmake:207 (message):
Error generating /mydir/caffe/build/src/caffe/CMakeFiles/cuda_compile.dir/util/./cuda_compile_generated_im2col.cu.o
Software version:
OS: Debian.
gcc version: 5.3.1.
nvcc version: 6.5.12.
cat /proc/driver/nvidia/version result:
NVRM version: NVIDIA UNIX x86_64 Kernel Module 352.63 Sat Nov 7 21:25:42 PST 2015
GCC version: gcc version 4.8.5 (Debian 4.8.5-3)
Attempts to solve the problem
1st try
Simple solutions are often best ones, so (as suggested here) I tried to comment out macro checking gcc version from /usr/include/host_config.h (line 82). Unfortunately it doesn't work and compilation fails badly:
1 catastrophic error detected in the compilation of "/tmp/tmpxft_000069c2_00000000-4_im2col.cpp4.ii".
2nd try
I tried to run:
cmake -D CMAKE_CXX_COMPILER=g++-4.8 ..
make
but it fails with exactly the same error message (even though g++-4.8 should be accepted).
3rd try
I've found similar problem (though not related to Caffe) and I tried to solve it as suggested in the accepted answer.
What I did:
I've ran grep -iR "find_package(CUDA" caffe command and found Cuda.cmake file which has find_package(CUDA 5.5 QUIET) in line 225.
I added set(CUDA_HOST_COMPILER /usr/bin/gcc-4.8) to Cuda.cmake, line before line: find_package(CUDA 5.5 QUIET).
I removed everything from build directory and ran cmake and make again - with and without -D CMAKE_CXX_COMPILER=g++-4.8.
Unfortunately result is exactly the same. Caffe probably overwrites it somehow - I didn't figure it out how.
make VERBOSE=1 2>&1 | grep -i compiler-bindir returns nothing.
What's interesting, make VERBOSE=1 prints command that fails, which is:
/usr/bin/nvcc -M -D__CUDACC__ /mydir/caffe/src/caffe/util/im2col.cu -o /mydir/caffe/build/src/caffe/CMakeFiles/cuda_compile.dir/util/cuda_compile_generated_im2col.cu.o.NVCC-depend -ccbin /usr/bin/cc -m64 -DUSE_LMDB -DUSE_LEVELDB -DUSE_OPENCV -DWITH_PYTHON_LAYER -DGTEST_USE_OWN_TR1_TUPLE -Xcompiler ,\"-fPIC\",\"-Wall\",\"-Wno-sign-compare\",\"-Wno-uninitialized\",\"-O3\",\"-DNDEBUG\" -gencode arch=compute_20,code=sm_21 -Xcudafe --diag_suppress=cc_clobber_ignored -Xcudafe --diag_suppress=integer_sign_change -Xcudafe --diag_suppress=useless_using_declaration -Xcudafe --diag_suppress=set_but_not_used -Xcompiler -fPIC -DNVCC -I/usr/include -I/mydir/caffe/src -I/usr/include -I/mydir/caffe/build/include -I/usr/include/hdf5/serial -I/usr/include/opencv -I/usr/include/atlas -I/usr/include/python2.7 -I/usr/lib/python2.7/dist-packages/numpy/core/include -I/mydir/caffe/include -I/mydir/caffe/build
when I add --compiler-bindir /usr/bin/gcc-4.8 flag manually, it prints error:
nvcc fatal : redefinition of argument 'compiler-bindir'
which may be related to this bug report.
Edit: I didn't notice that --compiler-bindir and -ccbin are the same options, and the latter is already set in above command that failed. When I changed -ccbin /usr/bin/cc to -ccbin /usr/bin/gcc-4.8 in above command that failed, it completes successfully. Now I need to find option in Caffe's CMake file that overwrite -ccbin in all subsequent Caffe's CMakes. Looking at cmake/Cuda.cmake:252:list(APPEND CUDA_NVCC_FLAGS ${NVCC_FLAGS_EXTRA} seems to be good way to go.
How can I successfully complete my compilation? Any help is appreciated.
Related SO questions:
host_config.h:unsupported GNU version! gcc versions later than 4.9 are not supported.
CUDA 6.5 complains about not supporting gcc 4.9 - what to do?.
cmake -D CUDA_NVCC_FLAGS="-ccbin gcc-4.8" .. && make causes successful compilation.
Now another problem showed up: linking Google's libgflags or libprotobuf fails probably due to fact that it was compiled with newer gcc version but it's not related to asked question.
My machine runs Ubuntu 15.10, and my default compiler version is gcc 5.2.1 .
Commenting out the #error directive in line 115 of file
/usr/local/cuda-7.5/include/host_config.h
(or whatever the path on your system is) did the trick for me. Caffe compiled fine, all tests ran smoothly.
On the other hand, if one chooses to ignore this and proceed to compile part of the project with one compiler version, part of the project with another (for me it was gcc-4.8 and gcc-5.2.1), linking problems will arise. The linking problems of protobuf and libgflags another answer mentions are not unrelated to this.

CUDA incompatible with my gcc version

I have troubles compiling some of the examples shipped with CUDA SDK.
I have installed the developers driver (version 270.41.19) and the CUDA toolkit,
then finally the SDK (both the 4.0.17 version).
Initially it didn't compile at all giving:
error -- unsupported GNU version! gcc 4.5 and up are not supported!
I found the line responsible in 81:/usr/local/cuda/include/host_config.h and changed it to:
//#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 4)
#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 6)
from that point on I got only a few of the examples to compile, it stops with:
In file included from /usr/include/c++/4.6/x86_64-linux-gnu/bits/gthr.h:162:0,
from /usr/include/c++/4.6/ext/atomicity.h:34,
from /usr/include/c++/4.6/bits/ios_base.h:41,
from /usr/include/c++/4.6/ios:43,
from /usr/include/c++/4.6/ostream:40,
from /usr/include/c++/4.6/iterator:64,
from /usr/local/cuda/include/thrust/iterator/iterator_categories.h:38,
from /usr/local/cuda/include/thrust/device_ptr.h:26,
from /usr/local/cuda/include/thrust/device_malloc_allocator.h:27,
from /usr/local/cuda/include/thrust/device_vector.h:26,
from lineOfSight.cu:37:
/usr/include/c++/4.6/x86_64-linux-gnu/bits/gthr-default.h:251:1: error: pasting "__gthrw_" and "/* Android's C library does not provide pthread_cancel, check for
`pthread_create' instead. */" does not give a valid preprocessing token
make[1]: *** [obj/x86_64/release/lineOfSight.cu.o] Error 1
As some of the examples compile I reckon this is not a driver problem, but rather must have something to do with an unsupported gcc version. Downgrading is not an option as gcc4.6 has a whole system as a dependency at this point...
As already pointed out, nvcc depends on gcc 4.4. It is possible to configure nvcc to use the correct version of gcc without passing any compiler parameters by adding softlinks to the bin directory created with the nvcc install.
The default cuda binary directory (the installation default) is /usr/local/cuda/bin, adding a softlink to the correct version of gcc from this directory is sufficient:
sudo ln -s /usr/bin/gcc-4.4 /usr/local/cuda/bin/gcc
Check the maximum supported GCC version for your CUDA version:
CUDA version
max supported GCC version
12
12.1
11.4.1+, 11.5, 11.6, 11.7, 11.8
11
11.1, 11.2, 11.3, 11.4.0
10
11
9
10.1, 10.2
8
9.2, 10.0
7
9.0, 9.1
6
8
5.3
7
4.9
5.5, 6
4.8
4.2, 5
4.6
4.1
4.5
4.0
4.4
Set an env var for that GCC version. For example, for CUDA 10.2:
MAX_GCC_VERSION=8
Make sure you have that version installed:
sudo apt install gcc-$MAX_GCC_VERSION g++-$MAX_GCC_VERSION
Add symlinks within CUDA folders:
sudo ln -s /usr/bin/gcc-$MAX_GCC_VERSION /usr/local/cuda/bin/gcc
sudo ln -s /usr/bin/g++-$MAX_GCC_VERSION /usr/local/cuda/bin/g++
(or substitute /usr/local/cuda with your CUDA installation path, if it's not there)
See this GitHub gist for more information on the CUDA-GCC compatibility table.
gcc 4.5 and 4.6 are not supported with CUDA - code won't compile and the rest of the toolchain, including cuda-gdb, won't work properly. You cannot use them, and the restriction is non-negotiable.
Your only solution is to install a gcc 4.4 version as a second compiler (most distributions will allow that). There is an option to nvcc --compiler-bindir which can be used to point to an alternative compiler. Create a local directory and then make symbolic links to the supported gcc version executables. Pass that local directory to nvcc via the --compiler-bindir option, and you should be able to compile CUDA code without affecting the rest of your system.
EDIT:
Note that this question, and answer, pertain to CUDA 4.
Since it was written, NVIDIA has continued to expand support for later gcc versions in newer CUDA toolchain release
As of the CUDA 4.1 release, gcc 4.5 is now supported. gcc 4.6 and 4.7 are unsupported.
As of the CUDA 5.0 release, gcc 4.6 is now supported. gcc 4.7 is unsupported.
As of the CUDA 6.0 release, gcc 4.7 is now supported.
As of the CUDA 7.0 release, gcc 4.8 is fully supported, with 4.9 support on Ubuntu 14.04 and Fedora 21.
As of the CUDA 7.5 release, gcc 4.8 is fully supported, with 4.9 support on Ubuntu 14.04 and Fedora 21.
As of the CUDA 8 release, gcc 5.3 is fully supported on Ubuntu 16.06 and Fedora 23.
As of the CUDA 9 release, gcc 6 is fully supported on Ubuntu 16.04, Ubuntu 17.04 and Fedora 25.
The CUDA 9.2 release adds support for gcc 7
The CUDA 10.1 release adds support for gcc 8
The CUDA 10.2 release continues support for gcc 8
The CUDA 11.0 release adds support for gcc 9 on Ubuntu 20.04
The CUDA 11.1 release expands gcc 9 support across most distributions and adds support for gcc 10 on Fedora linux
There is presently (as of CUDA 11.1) no gcc 10 support in CUDA other than Fedora linux
Note that NVIDIA has recently added a very useful table here which contains the supported compiler and OS matrix for the current CUDA release.
Gearoid Murphy's solution works better for me since on my distro (Ubuntu 11.10), gcc-4.4 and gcc-4.6 are in the same directory, so --compiler-bindir is no help. The only caveat is I also had to install g++-4.4 and symlink it as well:
sudo ln -s /usr/bin/gcc-4.4 /usr/local/cuda/bin/gcc
sudo ln -s /usr/bin/g++-4.4 /usr/local/cuda/bin/g++
If using cmake for me none of the hacks of editing the files and linking worked so I compiled using the flags which specify the gcc/g++ version.
cmake -DCMAKE_C_COMPILER=gcc-6 -DCMAKE_CXX_COMPILER=g++-6 ..
Worked like charm.
For CUDA7.5 these lines work:
sudo ln -s /usr/bin/gcc-4.9 /usr/local/cuda/bin/gcc
sudo ln -s /usr/bin/g++-4.9 /usr/local/cuda/bin/g++
Check out how to use "update-alternatives" to get around this issue:
... If you install gcc 4.6 you can also use the update-alternatives
command to allow for easily switching between versions. This can be
configured with:
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.6
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.7 40 --slave /usr/bin/g++ g++ /usr/bin/g++-4.7
sudo update-alternatives --config gcc
On most distributions you have the possibility to install another gcc and g++ version beside a most recent compiler like gcc-4.7. In addition most build systems are aware of the CC and CXX environment variables, which let specify you other C and C++ compilers respectively. SO I suggest something like:
CC=gcc-4.4 CXX=g++-4.4 cmake path/to/your/CMakeLists.txt
For Makefiles there should be a similar way. I do not recommend setting custom symlinks within /usr/local unless you know what you are doing.
This works for fedora 23. The compat gcc repositories will be slightly different based on your version of fedora.
If you install the following repositories:
sudo yum install compat-gcc-34-c++-3.4.6-37.fc23.x86_64 compat-gcc-34-3.4.6-37.fc23.x86_64
Now make the soft links as mentioned above assuming your cuda bin folder is in /usr/local/cuda/
sudo ln -s /usr/bin/gcc-34 /usr/local/cuda/bin/gcc
sudo ln -s /usr/bin/g++-34 /usr/local/cuda/bin/g++
You should now be able to compile with nvcc without the gcc version error.
Gearoid Murphy's solution works like a charm. For me I had two directories for cuda -
/usr/local/cuda
/usr/local/cuda-5.0
The soft links had to be added only to the directory mentioned below -
/usr/local/cuda
Also, both g++ and gcc soft links were required as mentioned by SchighSchagh.
Another way of configuring nvcc to use a specific version of gcc (gcc-4.4, for instance), is to edit nvcc.profile and alter PATH to include the path to the gcc you want to use first.
For example (gcc-4.4.6 installed in /opt):
PATH += /opt/gcc-4.4.6/lib/gcc/x86_64-unknown-linux-gnu/4.4.6:/opt/gcc-4.4.6/bin:$(TOP)/open64/bin:$(TOP)/share/cuda/nvvm:$(_HERE_):
The location of nvcc.profile varies, but it should be in the same directory as the nvcc executable itself.
This is a bit of a hack, as nvcc.profile is not intended for user configuration as per the nvcc manual, but it was the solution which worked best for me.
CUDA is after some header modifications compatible with gcc4.7 and maybe higher version:
https://www.udacity.com/wiki/cs344/troubleshoot_gcc47
For people like me who get confused while using cmake, the FindCUDA.cmake script overrides some of the stuff from nvcc.profile. You can specify the nvcc host compiler by setting CUDA_HOST_COMPILER as per http://public.kitware.com/Bug/view.php?id=13674.
I had to install the older versions of gcc, g++.
sudo apt-get install gcc-4.4
sudo apt-get install g++-4.4
Check that gcc-4.4 is in /usr/bin/, and same for g++
Then I could use the solution above:
sudo ln -s /usr/bin/gcc-4.4 /opt/cuda/bin/gcc
sudo ln -s /usr/bin/g++-4.4 /opt/cuda/bin/g++
In $CUDA_HOME/include/host_config.h, find lines like these (may slightly vary between different CUDA version):
//...
#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 9)
#error -- unsupported GNU version! gcc versions later than 4.9 are not supported!
#endif [> __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 9) <]
//...
Remove or change them matching your condition.
Note this method is potentially unsafe and may break your build. For example, gcc 5 uses C++11 as default, however this is not the case for nvcc as of CUDA 7.5. A workaround is to add
--Xcompiler="--std=c++98" for CUDA<=6.5
or
--std=c++11 for CUDA>=7.0.
If you encounter this error, please read the log file:
$ cat /var/log/cuda-installer.log
[INFO]: Driver installation detected by command: apt list --installed | grep -e nvidia-driver-[0-9][0-9][0-9] -e nvidia-[0-9][0-9][0-9]
[INFO]: Cleaning up window
[INFO]: Complete
[INFO]: Checking compiler version...
[INFO]: gcc location: /usr/bin/gcc
[INFO]: gcc version: gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)
[ERROR]: unsupported compiler version: 9.2.1. Use --override to override this check.
Just follow the suggestion in the log file:
sudo sh cuda_<version>_linux.run --override
Job done :)
I just installed CUDA 10.2 with gcc 9.2 on Kubuntu 19.10 using the --override option.
For CUDA 6.5 (and apparently 7.0 and 7.5), I've created a version of the gcc 4.8.5 RPM package (under Fedora Core 30) that allows that version of gcc to be install alongside your system's current GCC.
You can find all of that information here.
To compile the CUDA 8.0 examples on Ubuntu 16.10, I did:
sudo apt-get install gcc-5 g++-5
cd /path/to/NVIDIA_CUDA-8.0_Samples
# Find the path to the library (this should be in NVIDIA's Makefiles)
LIBLOC=`find /usr/lib -name "libnvcuvid.so.*" | head -n1 | perl -pe 's[/usr/lib/(nvidia-\d+)/.*][$1]'`
# Substitute that path into the makefiles for the hard-coded, incorrect one
find . -name "*.mk" | xargs perl -pi -e "s/nvidia-\d+/$LIBLOC/g"
# Make using the supported compiler
HOST_COMPILER=g++-5 make
This has the advantage of not modifying the whole system or making symlinks to just the binaries (that could cause library linking problems.)
This solved my problem:
sudo rm /usr/local/cuda/bin/gcc
sudo rm /usr/local/cuda/bin/g++
sudo apt install gcc-4.4 g++-4.4
sudo ln -s /usr/bin/gcc-4.4 /usr/local/cuda/bin/gcc
sudo ln -s /usr/bin/g++-4.4 /usr/local/cuda/bin/g++
In my case, I had CUDA already installed from the Ubuntu version and cmake would detect that one instead of the newly installed version using the NVidia SDK Manager.
I ran dpkg -l | grep cuda and could see both versions.
What I had to do is uninstall the old CUDA (version 9.1 in my case) and leave the new version alone (version 10.2). I used the purge command like so:
sudo apt-get purge libcudart9.1 nvidia-cuda-dev nvidia-cuda-doc \
nvidia-cuda-gdb nvidia-cuda-toolkit
Please verify that the package names match the version you want to remove from your installation.
I had to rerun cmake from a blank BUILD directory to redirect all the #include and libraries to the SDK version (since the old paths were baked in the existing build environment).
This is happening because your current CUDA version doesn't support your current GCC version. You need to do the following:
Find the supported GCC version (in my case 5 for CUDA 9)
CUDA 4.1: GCC 4.5
CUDA 5.0: GCC 4.6
CUDA 6.0: GCC 4.7
CUDA 7.0: GCC 4.8
CUDA 7.5: GCC 4.8
CUDA 8: GCC 5.3
CUDA 9: GCC 5.5
CUDA 9.2: GCC 7
CUDA 10.1: GCC 8
Install the supported GCC version
sudo apt-get install gcc-5
sudo apt-get install g++-5
Change the softlinks for GCC in the /usr/bin directory
cd /usr/bin
sudo rm gcc
sudo rm g++
sudo ln -s /usr/bin/gcc-5 gcc
sudo ln -s /usr/bin/g++-5 g++
Change the softlinks for GCC in the /usr/local/cuda-9.0/bin directory
cd /usr/local/cuda-9.0/bin
sudo rm gcc
sudo rm g++
sudo ln -s /usr/bin/gcc-5 gcc
sudo ln -s /usr/bin/g++-5 g++
Add -DCUDA_HOST_COMPILER=/usr/bin/gcc-5 to your setup.py file, used for compilation
if torch.cuda.is_available() and CUDA_HOME is not None:
extension = CUDAExtension
sources += source_cuda
define_macros += [("WITH_CUDA", None)]
extra_compile_args["nvcc"] = [
"-DCUDA_HAS_FP16=1",
"-D__CUDA_NO_HALF_OPERATORS__",
"-D__CUDA_NO_HALF_CONVERSIONS__",
"-D__CUDA_NO_HALF2_OPERATORS__",
"-DCUDA_HOST_COMPILER=/usr/bin/gcc-5"
]
Remove the old build directory
rm -rd build/
Compile again by setting CUDAHOSTCXX=/usr/bin/gcc-5
CUDAHOSTCXX=/usr/bin/gcc-5 python setup.py build develop
Note: If you still get the gcc: error trying to exec 'cc1plus': execvp: no such file or directory error after following these steps, try reinstalling the GCC like this and then compiling again:
sudo apt-get install --reinstall gcc-5
sudo apt-get install --reinstall g++-5
Credits: https://github.com/facebookresearch/maskrcnn-benchmark/issues/25#issuecomment-433382510

What does 4: mean in g++ apt-get install version string?

On EasyPeasy 1.1 (for mini notebooks) derived from Ubuntu I installed g++ using apt-get:
$ apt-get install g++
One of the lines displayed was:
Setting up g++ (4:4.3.1-1ubuntu2) ...
What the does "4:" mean?
$ g++ --version
g++ (Ubuntu 4.3.2-1ubuntu12) 4.3.2
What is the relationship of the "4.3.1" in apt-get to the "4.3.2" g++ version?
It is an epoch. According to the debian policy manual,
the purpose of epochs is to allow us
to leave behind mistakes in version
numbering, and to cope with situations
where the version numbering scheme
changes
IIRC gcc 3.4.x introduced ABI-incompatible changes from the 3.3.x series, and this epoch may have been introduced by debian maintainers at that time.

changing search-dirs for $ sudo gcc

On OS X I'm trying to install the zlib prerequisite for haskell's Cabal. I get this error:
$ sudo ./Setup build
Preprocessing library zlib-0.5.0.0…
ld: library not found for -lgmp
collect2: ld returned 1 exit status
linking dist/build/Codec/Compression/Zlib/Stream_hsc_make.o failed
command was: /usr/bin/gcc -lz -L/sw/lib/ghc-6.8.3/lib/bytestring-0.9.0.1.1 -L/sw/lib/ghc-6.8.3/lib/array-0.1.0.0 -L/sw/lib/ghc-6.8.3/lib/base-3.0.2.0 -L/sw/lib/ghc-6.8.3 -lm -lgmp -ldl dist/build/Codec/Compression/Zlib/Stream_hsc_make.o -o dist/build/Codec/Compression/Zlib/Stream_hsc_make
The library -lgmp is found in /sw/lib, so I can run that command ("/usr/bin/gcc ...") successfully if I manually add -L/sw/lib. The problem is that sudo doesn't know about /sw/lib. Behold:
$ gcc -print-search-dirs | grep sw
libraries: =/lib/i686-apple-darwin9/4.0.1/:/lib/:/usr/lib/i686-apple-darwin9/4.0.1/:/usr/lib/:./i686-apple-darwin9/4.0.1/:./:/sw/lib/i686-apple-darwin9/4.0.1/:/sw/lib/:/usr/lib/gcc/i686-apple-darwin9/4.0.1/:/usr/lib/gcc/i686-apple-darwin9/4.0.1/:/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../../i686-apple-darwin9/lib/i686-apple-darwin9/4.0.1/:/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../../i686-apple-darwin9/lib/:/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../i686-apple-darwin9/4.0.1/:/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../
$ sudo gcc -print-search-dirs | grep sw
$
How do I tell the sudo version of gcc to look in /sw/lib for libraries? Do I add an environment variable on root's .bash_profile? If so, which one?
UPDATE:
There’s probably a more proper way to do this, but here’s what worked. I created a bash script with this in it:
#!/bin/sh
export LIBRARY_PATH=/sw/lib:$LIBRARY_PATH
./Setup build
And then I ran
$ sudo ./script.sh
That compiled zlib without complaining - hooray! Unfortunately cabal-install is still giving me the error:
$ ./Setup configure
Configuring cabal-install-0.6.2…
Setup: At least the following dependencies are missing:
zlib >=0.4 && <0.6
So I went back to the cabal-install dir (which is what I'm trying to do in the first place), and ran...
$ ./bootstrap.sh
...and that installed everything as expected.
Why you use sudo ever? You should not compile as super user. Compile as normal user and install as super user.
Try setting LDFLAGS=-L/sw/lib.
GHC now comes with an installer for OS X (Leopard, not sure about Tiger). The only issue is that if you use macports or fink, these will probably not see that you have GHC installed and try to install their own version of it.

Resources