I have a program I'm compiling that requires a new version of Curl. Mac default Curl is in /usr/bin and /usr/lib. I have compiled a newer version of curl and compiled using:
gcc mypgm.c -I ./curl-7.58.0/include/curl -I ./cJSON-master -L ./cJSON-master/build ./libcjson.1.7.1.dylib ./libcurl.4.dylib -o mypgm
When I run mypgm I get the error:
Incompatible library version: mypgm requires version 10.0.0 or later, but libcurl.4.dylib provides version 7.0.0
Running otool I found that the libcurl in my build dir is correct, but it seems to be wanting to use the /usr/lib version, which can't be deleted (without disable SIP, delete, reenable, which I don't want to do in case some future version reinstalls).
So my question is two-fold.
I want to know if it is possible like with $PATH to change the way macOS finds libraries (I read something about LD_LIBRARY_PATH and DYLD_LIBRARY_PATH being ignored), and
How should I redo the gcc line to static link those libraries?
This worked after coping the libraries into the /usr/local/lib folder.
gcc -I ./curl-7.58.0/include/curl -I ./cJSON-master /usr/local/lib/libcjson.1.7.1.dylib /usr/local/lib/libcurl.4.dylib mypgm.c -o mypgm
I think the relative path (./) for the libraries rather then absolute path is the key.
Related
I have XCode installed (Version 7.2.1 (7C1002)) in Yosemite and have downloaded and installed command line tools. When I try to check the gcc version I get:
$ gcc -v
Segmentation fault: 11
$
The output for:
$ type -a gcc
gcc is /usr/local/bin/gcc
gcc is /usr/bin/gcc
$
From what I understand, that should mean that I have it installed so I still don't understand why I can't check it's version. Since I will need gcc for other applications I would like to have it fixed...any suggestions? Do I need to link it somehow?
You have a faulty third-party version of gcc (or perhaps another compiler masquerading as gcc) installed in /usr/local. This may be something put there by Homebrew or maybe you installed this build of gcc yourself or something.
A short-term fix would be to modify your PATH environment variable so that /usr/bin comes before /usr/local/bin. Or, you could just always specify the full path to gcc, such as /usr/bin/gcc -v.
Longer term, you probably want to remove the broken gcc that's been installed to /usr/local. How you do that exactly depends on how you originally installed it there.
I installed gcc version 5.1 locally on a cluster having OS as CentOS where I dont have root access (so i cant use any commands like 'sudo'). (The global gcc version installed is 4.4). I also modified the path variable to include the path to my local version at the beginning of the path variable. Before, when I was trying to install boost using the global version, it worked fine. But now, when I try to install boost, it shows the following error:
/users/home/head/cmp/soft/sft/gcc/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/cc1: error while loading shared libraries: libisl.so.10: cannot open shared object file: No such file or directory
Any ideas on how to fix this will be highly appreciated.
Follow the instructions at https://gcc.gnu.org/wiki/InstallingGCC
Specifically, don't install ISL manually in some non-standard path, because GCC needs to find its shared libraries at run-time.
The simplest solution is to use the download_prerequisites script to add the GMP, MPFR, MPC and ISL source code to the GCC source tree, which will cause GCC to build them for you automatically, and link to them statically.
I have the same issue. I solved it as follows:
Download the source code of isl available here
Unzip and install: ./configure && make && make install
cp /usr/local/lib/libisl* /usr/lib
Note: a symlink also works:
$ cd /usr/lib
$ ln -s /usr/local/lib/libisl.so.10 libisl.so.10
You can do the same in Debian distros:
apt-get install libisl-dev
Adjust the references of shared libs:
$ cp /usr/local/lib/libisl* /usr/lib
Note: a symlink also works:
$ cd /usr/lib
$ ln -s /usr/local/lib/libisl.so.10 libisl.so.10
I am trying to build GraphChi on OS X Yosemite but get the following error:
fatal error: 'omp.h' file not found
From this question - How to include omp.h in OS X? - I learned that Yosemite uses Clang instead of gcc, which does not include omp.h.
$ which gcc
/usr/bin/gcc
$ gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
Next, I installed gcc via Homebrew
$ brew info gcc
gcc: stable 4.9.2 (bottled)
http://gcc.gnu.org
/usr/local/Cellar/gcc/4.9.2_1 (1092 files, 177M)
Built from source with: --without-multilib
and updated $PATH to include the path to the new gcc version
$ echo $PATH
/usr/local/Cellar/gcc/4.9.2_1:usr/local/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin
however, gcc -v and which gcc still point to the old version, and building GraphChi still doesn't work due to the missing omp.h file
Does anyone know what else I need to do?
Update
locate omp.h returned:
/usr/local/Cellar/apple-gcc42/4.2.1-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/include/omp.h
/usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9/gcc/x86_64-apple-darwin14.1.0/4.9.2/include/omp.h
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/include/omp.h
my ~/.profile:
export PATH=/usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9/gcc/x86_64-apple-darwin14.1.0/4.9.2/include:/usr/local/Cellar/gcc/4.9.2_1/bin:usr/local/bin:/opt/local/bin:/opt/local/sbin:$PATH
I solved this with installing gcc with homebrew:
brew install gcc --without-multilib
and then building the source code with
CC=gcc-5 CXX=g++-5 cmake ..
CC=gcc-5 CXX=g++-5 make -j7
Once you have installed gcc-4.9 with homebrew, it will automatically be in your path. To use OpenMP, you just need to make sure you are using the newly installed gcc-4.9, and it will be able to find omp.h.
In the case of GraphChi, you will have to go change line 3 of the Makefile to be gcc-4.9. From there, running make should just work. They describe this in their README, but at least the version they describe is out of date https://github.com/GraphChi/graphchi-cpp#problems-compiling-on-mac.
clang does not support OpenMP yet. Also gcc by default links to Apple's LLVM clang compiler (not the GCC installed from brew).
Instead gcc-4.9 would link to GCC. I think if -fopenmp is specified omp.h is included automatically.
It is possible to manually build a version of clang with OpenMP support, see http://clang-omp.github.io
You shouldn't add the include path to PATH; instead, specify it as CFLAGS, including the -I option. You can export the CFLAGS variable, or set it on the fly.
Depending on how you compile things, you could do
CFLAGS=-I/usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9/gcc/x86_64-apple-darwin14.1.0/4.9.2/include/omp.h gcc <whatever>
Of course, in this case you can specify it directly on the gcc command (as -I/usr/local/....), but the CFLAGS variable also works with configure (as configure often won't have an option to specify where it should look for specific include files); probably with make, or even for those installing a Python package: CFLAGS=-I... pip install <some-package>.
Other flags to consider are
CXXFLAGS: C++ specific pre-processor flags
LDFLAGS: linker specific flags (e.g. LDFLAGS=-L/some/path/... for linking with dynamic libraries).
CC: specify the C compiler to use. This is an easy way to avoid the built-in gcc alias for clang on OS X. Just use CC=/usr/local/bin/gcc-4 make or similar.
CXX: specify the C++ compiler to use.
I'm trying to install GalSim on OSX Mavericks, using the anaconda python distribution, but keep running into the error:
Unable to build a python loadable module using the python executable:
/usr/bin/env python,
the library name libpython2.7.a,
and the libdir /Users/harrison/anaconda/lib/python2.7/config.
If these are not the correct library names, you can tell scons the
correct names to use with the flags EXTRA_LIB_PATH and/or EXTRA_LIBS.
the /usr/bin/env python is the anaconda one and there is indeed a libpython2.7.a in that libdir.
scons is installed via the conda package management system.
boost is installed manually as recommended via
./bootstrap.sh --with-python=/Users/harrison/anaconda/bin/python --with-python-root=/Users/harrison/anaconda/
./b2 -a link=shared
sudo ./b2 -a --prefix=/usr/local link=shared install
checking the version of python boost links to gives
$ otool -L /usr/local/lib/libboost_python.dylib
/usr/local/lib/libboost_python.dylib:
libboost_python.dylib (compatibility version 0.0.0, current version 0.0.0)
libpython2.7.dylib (compatibility version 2.7.0, current version 2.7.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
Is this correct (it doesn't seem so to me -- boost seems to be linking to the libpython2.7 in /usr/local/) and is this what is causing the problem installing GalSim?
Thanks
Ian
Full output:
$ scons
scons: Reading SConscript files ...
SCons is version 2.3.0 using python version 2.7.6
Python is from /Users/harrison/anaconda/include/python2.7
Using the following (non-default) scons options:
CXX = g++
These can be edited directly in the file gs_scons.conf.
Type scons -h for a full list of available options.
Using python = /usr/bin/env python
Using default PYPREFIX = /Users/harrison/anaconda/lib/python2.7/site-packages
Using compiler: /usr/bin/g++
compiler version: 4.2.1
Determined that a good number of jobs = 4
Checking for C++ header file fftw3.h... yes
Checking for correct FFTW linkage... yes
Checking for C++ header file boost/shared_ptr.hpp... yes
Checking for C++ header file TMV.h... yes
Using TMV_LINK file: /usr/local/share/tmv/tmv-link
-L/usr/local/Cellar/tmv-cpp/0.71/lib -ltmv -lblas
Mac version is 10.9
WARNING: The Apple BLAS library has been found not to be thread safe on
Mac OS version 10.7 (and possibly higher), even across multiple
processes (i.e. not just multiple threads in the same process).
The symptom is that `scons tests` will hang when running nosetests
using multiple processes.
If this occurs, the solution is to compile TMV either with a
different BLAS library (e.g. ATLAS) or with no BLAS library at
all (using WITH_BLAS=false).
Checking for correct TMV linkage... (this may take a little while)
Checking for correct TMV linkage... yes
Checking if we can build against Python...
Unable to build a python loadable module using the python executable:
/usr/bin/env python,
the library name libpython2.7.a,
and the libdir /Users/harrison/anaconda/lib/python2.7/config.
If these are not the correct library names, you can tell scons the
correct names to use with the flags EXTRA_LIB_PATH and/or EXTRA_LIBS.
Please fix the above error(s) and rerun scons.
Note: you may want to look through the file INSTALL.md for advice.
Also, if you are having trouble, please check the INSTALL FAQ at
https://github.com/GalSim-developers/GalSim/wiki/Installation%20FAQ
Ian, thanks for posting that. Based on the config.log and my own experience, I have an answer that should solve at least this problem (no guarantees that you won't hit something else later in the build).
The key problem here is that if you tell it the compiler is gcc (as is the default), it will try to use openMP. But actually invoking gcc on Mavericks gives you clang++, for which openMP doesn't work. So, you have to explicitly tell galsim that the compiler is clang++ so it won't try to use openMP. (The clue to this is in config.log, there are messages in various places about undefined symbols for x86_64 architecture... I had this problem on my own system when I started using Mavericks. See also https://github.com/GalSim-developers/GalSim/issues/493 )
So, please do scons CXX=clang++ and this problem should go away. I cannot guarantee that you won't hit a boost problem later on, however.
Please also see this question which has two suggestions which may help solve the problem for you as well.
I have a problem concerning libstdc++.so.
I installed a new version of gcc and tried to compile C++ code. The compiling worked, but when I try to execute the binary (m5.opt is its name) I've got the following error:
build/ALPHA_SE/m5.opt: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by build/ALPHA_SE/m5.opt).
Do I need to replace libstdc++.so? And if so, where can I download the version I want? On the GCC-website they say libstdc++ is a part of gcc now.
Details
GCC:
I had gcc 4.1.2 before, but I downloaded gcc 4.2.4. From the untarred gcc-directory I executed ./configure; make; sudo make install`.
When I tried to use gcc or g++ to compile, it's default version was still 4.1.2. To overcome this I replaced some links:
mv /usr/bin/gcc /usr/bin/gcc_bak
ln -s /usr/local/bin/gcc gcc
mv /usr/bin/g++ /usr/bin/g++_bak
ln -s /usr/local/bin/g++ g++
GLIBC(++) -- libstdc++:
/usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.8
/usr/local/lib/libstdc++.so -> libstdc++.so.6.0.9
/lib/libc.so.6 -> libc-2.5.so -> libc-2.5.so
Linux-version:
uname -a gives:
Linux madmax 2.6.18-128.4.1.el5 #1 SMP Tue Aug 4 12:51:10 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
The problem is that you built your new GCC incorrectly: on Linux you should use
./configure --prefix=/usr
The default installation prefix is /usr/local, which is why make install put gcc and g++ binaries into /usr/local/bin, etc.
What's happening to you now is that you compile and link using the new (symlinked) GCC 4.2.4, but at runtime your program binds to the old /usr/lib64/libstdc++.so.6 (version 6.0.8, instead of required 6.0.9). You can confirm that by running ldd build/ALPHA_SE/m5.opt: you should see that it uses /usr/lib64/libstdc++.so.6.
There are several fixes you could do.
env LD_LIBRARY_PATH=/usr/local/lib64 ldd build/ALPHA_SE/m5.opt
should show you that setting LD_LIBRARY_PATH is sufficient to redirect the binary to correct library, and
LD_LIBRARY_PATH=/usr/local/lib64 build/ALPHA_SE/m5.opt
should just run. You could "bake" this path into m5.opt binary by relinking it with -Wl,-rpath=/usr/local/lib64.
A more permanent solution is to fix the libraries the same way you fixed the binaries:
cd /usr/lib64 && mv libstdc++.so.6 libstdc++.so.6_bak &&
ln -s /usr/local/lib64/libstdc++.so.6 .
An even better solution is to reconfigure the new GCC with --prefix=/usr, and then make all install.
I know this is a very old question, but ...
It's not usually a good idea to replace the system compiler (i.e. the one in /usr) because the entire system will have been built with it and depend on it.
It's usually better to install the new compiler to a separate location and then see the libstdc++ FAQ How do I insure that the dynamically linked library will be found? and Finding Dynamic or Shared Libraries in the manual for how to ensure the correct libstdc++.so is found at runtime.
The other answers here should be fine, but the 'quick and easy' solution if you do happen to have gcc installed to /usr/local/ is to just add the new libs to the LD_LIBRARY_PATH
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64
You can also check the to see if you have the right versions of GLIBC installed using
strings /usr/lib/libstdc++.so.6 | grep GLIBC
strings /usr/local/lib64/libstdc++.so.18 | grep GLIBC
I got this last tip from another forum so credits due where credits due!