I'm trying to install the Haskell regex-pcre library using:
cabal install --extra-include-dirs=/usr/local/include \
--extra-include-dirs=/usr/include regex-pcre
However I get this weird error:
Resolving dependencies...
Configuring regex-pcre-0.94.2...
Preprocessing library regex-pcre-0.94.2...
In file included from /Library/Frameworks/GHC.framework/Versions/7.0.2-i386/usr/lib/ghc-7.0.2/include/HsFFI.h:68,
from /Library/Frameworks/GHC.framework/Versions/7.0.2-i386/usr/lib/ghc-7.0.2/template-hsc.h:4,
from dist/build/Text/Regex/PCRE/Wrap_hsc_make.c:1:
/usr/include/float.h:8:24: error: float.h: No such file or directory
In file included from /Library/Frameworks/GHC.framework/Versions/7.0.2-i386/usr/lib/ghc-7.0.2/template-hsc.h:9,
from dist/build/Text/Regex/PCRE/Wrap_hsc_make.c:1:
/usr/include/stdarg.h:4:25: error: stdarg.h: No such file or directory
compiling dist/build/Text/Regex/PCRE/Wrap_hsc_make.c failed (exit code 1)
command was: /usr/bin/gcc -c dist/build/Text/Regex/PCRE/Wrap_hsc_make.c -o dist/build/Text/Regex/PCRE/Wrap_hsc_make.o -march=i686 -m32 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -fno-stack-protector -march=i686 -m32 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -fno-stack-protector -march=i686 -m32 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -D__GLASGOW_HASKELL__=700 -Ddarwin_BUILD_OS -Ddarwin_HOST_OS -Di386_BUILD_ARCH -Di386_HOST_ARCH -I/usr/include -I/usr/local/include -DHAVE_PCRE_H -DSPLIT_BASE=1 -I/Library/Frameworks/GHC.framework/Versions/7.0.2-i386/usr/lib/ghc-7.0.2/bytestring-0.9.1.10/include -I/Library/Frameworks/GHC.framework/Versions/7.0.2-i386/usr/lib/ghc-7.0.2/base-4.3.1.0/include -I/Library/Frameworks/GHC.framework/Versions/7.0.2-i386/usr/lib/ghc-7.0.2/include -I/Library/Frameworks/GHC.framework/Versions/7.0.2-i386/usr/lib/ghc-7.0.2/include -I/Library/Frameworks/GHC.framework/Versions/7.0.2-i386/usr/lib/ghc-7.0.2/include/
cabal: Error: some packages failed to install:
regex-pcre-0.94.2 failed during the building phase. The exception was:
ExitFailure 1
The gist of it, seems to be that it can't find a second float.h file:
/usr/include/float.h:8:24: error: float.h: No such file or directory
I've opened /usr/include/float.h and line 8 reads:
#include_next <float.h>
I've done my searching on Google, and although I don't know that much C I think I understand what that line is supposed to say, but... I don't know how to really solve this problem. I don't know where else I have a float.h file on my system.
The GHC and GCC versions I'm using. GCC comes from XCode 4. GHC is 32bit, but I've tried the 64bit version too, with the same results.
$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.2
OS X version is 10.6.7.
Any help greatly appreciated.
Looks to me like ticket #5011 - XCode 4 on Mac + GHC 7.0.2 fails to link.
This is fixed in GHC 7.0.3 which will be part of the mid-April release of the Haskell Platform.
And alternative fix is to downgrade to the 2010.2 Haskell Platform.
See this question yesterday: Can't install OpenGLRaw-1.1.0.1 on OS X
Related
I am trying to install Lektor on a MacbookPro with OS X 10.6.8.
Imagemagick and Python2.7 are already installed.
When I run the installation command:
curl -sf https://www.getlektor.com/install.sh | sh
The build process runs until it gets an error when building '_watchdog_fsevents' extension. The error is:
cc1: error: -Werror=unused-command-line-argument-hard-error-in-future: No option -Wunused-command-line-argument-hard-error-in-future
I've cut and pasted the output just prior to the error into the following code section.
How should I overcome this?
running build_ext
building '_watchdog_fsevents' extension
creating build/temp.macosx-10.6-x86_64-2.7
creating build/temp.macosx-10.6-x86_64-2.7/src
gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -I/usr/local/include -I/usr/local/opt/sqlite/include -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-error=unused-command-line-argument-hard-error-in-future -DWATCHDOG_VERSION_STRING="0.8.3" -DWATCHDOG_VERSION_MAJOR=0 -DWATCHDOG_VERSION_MINOR=8 -DWATCHDOG_VERSION_BUILD=3 -I/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c src/watchdog_fsevents.c -o build/temp.macosx-10.6-x86_64-2.7/src/watchdog_fsevents.o -std=c99 -pedantic -Wall -Wextra -fPIC -Wno-error=unused-command-line-argument-hard-error-in-future
cc1: error: -Werror=unused-command-line-argument-hard-error-in-future: No option -Wunused-command-line-argument-hard-error-in-future
cc1: error: -Werror=unused-command-line-argument-hard-error-in-future: No option -Wunused-command-line-argument-hard-error-in-future
error: command 'gcc-4.2' failed with exit status 1
----------------------------------------
Failed building wheel for watchdog
Failed to build watchdog
Most likely your version of OS X is too old to support the installation of watchdog with the version of gcc you have. If you cannot upgrade your OS X installation then I recommend installing a recent version of clang via brew and install lektor after exporting CC=clang.
Note though that Lektor is not tested for OS X < 10.9.
Your problem may be an updated version of Xcode in which you have not agreed to the license. Try running this first:
sudo xcodebuild -license
scroll to the very bottom and it will allow you to type "agree".
This resolved the issue for me.
I am trying to install a python module (SPArse Modeling Software) but the install script doesn't seem to be able to find the system's default Python.framework. This is an almost new (no migration assistant) Mac OS 10.9.5 system with both the default system python and Anaconda installed. I briefly installed Enthought Canopy but removed it when I decided to go with Anaconda. /System/Library/Frameworks/Python.framework exists and seems to have all the files you would expect.
In terminal, this is what happens:
bash-3.2$ which python
//anaconda/bin/python
bash-3.2$ cd spams-python
bash-3.2$ python setup.py build
running build
running build_py
running build_ext
building '_spams_wrap' extension
gcc -fno-strict-aliasing -I//anaconda/include -arch x86_64 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -Ispams/linalg -Ispams/prox -Ispams/decomp -Ispams/dictLearn -I//anaconda/lib/python2.7/site-packages/numpy/core/include -I/usr/include/python2.7/ -I//anaconda/include/python2.7 -c spams_wrap.cpp -o build/temp.macosx-10.5-x86_64-2.7/spams_wrap.o -DNDEBUG -DUSE_BLAS_LIB -fPIC -fopenmp -m32
clang: warning: argument unused during compilation: '-fopenmp'
#Omitting some irrelevant (I think) warnings#
4 warnings generated.
gcc -bundle -undefined dynamic_lookup -L//anaconda/lib -arch x86_64 -arch x86_64 build/temp.macosx-10.5-x86_64-2.7/spams_wrap.o -L//anaconda/lib -lstdc++ -lblas -llapack -o build/lib.macosx-10.5-x86_64-2.7/_spams_wrap.so -m32 -framework Python
ld: framework not found Python
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: command 'gcc' failed with exit status 1
So, my question is, is my diagnosis of the problem correct? How can I tell GCC where Python.framework is? Is there some environment variable that isn't set correctly?
The Anaconda Python is not a Framework build of Python. If the module expects that it's not going to work. Commenting out commenting out "'-framework', 'Python'" in setup.py sounds like a good start, and if it works, then it probably is the right solution.
Compile it with gcc-5, and I successed.
This is a follow-up to the question at Element-Wise Matrix Multiplication in Rcpp
I have been getting a number of different kinds of errors with RcppArmadillo since upgrading to Mavericks. I have Xcode 5.0.2 and Command Line Tools installed. Also, gfortran from Homebrew. But I keep encountering the error below --
> cppFunction("arma::mat schur(arma::mat& a, arma::mat& b)
{ return(a % b); }", depends="RcppArmadillo")
ld: library not found for -lgfortran
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [sourceCpp_18474.so] Error 1
clang++ -I/Library/Frameworks/R.framework/Resources/include -DNDEBUG -I/usr/local/include - I"/Library/Frameworks/R.framework/Versions/3.0/Resources/library/Rcpp/include" -I"/Library/Frameworks/R.framework/Versions/3.0/Resources/library/RcppArmadillo/include" -fPIC "-mtune=native -g -O2 -Wall -pedantic -Wconversion" -c fileaf992bfb8f84.cpp -o fileaf992bfb8f84.o clang++ -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/usr/local/lib -L/usr/local/lib -o sourceCpp_18474.so fileaf992bfb8f84.o -L/Library/Frameworks/R.framework/Resources/lib -lRlapack -L/Library/Frameworks/R.framework/Resources/lib -lRblas -lgfortran /Library/Frameworks/R.framework/Versions/3.0/Resources/library/Rcpp/lib/libRcpp.a -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
Error in sourceCpp(code = code, env = env, rebuild = rebuild, showOutput = showOutput, :
Error 1 occurred building shared library.
WARNING: The tools required to build C++ code for R were not found.
Please install Command Line Tools for XCode (or equivalent).
# Contents of Makevars
$ cat ~/.R/Makevars
CC=clang
CXX=clang++
CXXFLAGS="-mtune=native -g -O2 -Wall -pedantic -Wconversion"
FLIBS=-lgfortran
Commenting FLIBS=-lgfortran does not help and results in even more error messages --
> cppFunction("arma::mat schur(arma::mat& a, arma::mat& b) { return(a % b); }", depends="RcppArmadillo")
ld: warning: directory not found for option '-L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3/x86_64'
ld: warning: directory not found for option '-L/usr/local/lib/x86_64'
ld: warning: directory not found for option '-L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3'
ld: library not found for -lgfortran
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [sourceCpp_50381.so] Error 1
Thanks in advance.
Update
Following suggestions from response from Kevin and Dirk below, I re-installed Rcpp, RcppArmadillo and inline from source and updated FLIBS to point to the actual directory. This solved the issue.
# Update FLIBS in ~/.R/Makevars
FLIBS=-L/usr/local/Cellar/gfortran/4.8.2/gfortran
#Re-Install from source
install.packages(c("Rcpp","RcppArmadillo","inline"),type="source")
#Restart R
EDIT: If you're a Homebrew user, you now instead need to use brew install gcc (gfortran is no longer provided separate of gcc), and you can then follow the instructions here to get set up.
You have to symlink the libraries to /usr/local/lib manually:
ln -s /usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libgfortran.* /usr/local/lib/
I thought brew link gfortran would handle this, but apparently it only symlinks the gfortran program and not the actual libraries. So, unfortunately, you have to do it yourself.
(Replace 4.8.2 with whichever version of gfortran you're using from homebrew.)
Alternatively, if you want to keep from modifying /usr/local/lib, you can use
FLIBS=-L/usr/local/Cellar/gfortran/4.8.2/gfortran
in your ~/.R/Makevars file instead, so R knows where to find the gfortran libraries.
I can only suggest you study the numerous threads on the r-sig-mac list, the different answers here on SO as well as the posts on the rcpp-devel list.
As your error comes from the failed Fortran linking, maybe also review the standard page by Simon U. as well as the tools page it points too. AFAIK you should use the (older) gfortran 4.2.* from that page with R -- but then I am not an OS X user.
Edit in late 2016: We now have more detailed instructions in section 2.16 of the Rcpp FAQ.
I'm trying to install PyGSL on my computer (64 bit Windows 7), with Python 2.7 and GSL 1.15 installed. I'm pretty much stuck and I would love for some extra help. GSL installed fine, but its the wrapper that's the problem. For some reason I can't build pygsl. Apparently gcc is the problem (got the same problem on another windows machine). Or it could be that pygsl appears to be using a file named AMD64 while my computer is x86. I would love to use the windows binary for pygsl, but it only exists for python 2.5, and my project needs 2.6 or higher. I've used both the windows binary for GSL and built it from source, but I get the same problem either way. I tried copying dlls from GSL into pygsl but that didn't work. Some forums mentioned a file called gsl.dll but I can't seem to find it. I've also tried to use Cygwin and to compile with minGW32 to no avail.
cmds I ran:
python setup.py install
python setup.py build
python setup.py build_ext -i
python setup.py build --compiler=mingw32
Any ideas?? Thanks.
Cheers,
Bereket
Got the same message in Cygwin as in the windows cmd prompt. Error message:
$ /cygdrive/c/Python27/python.exe setup.py build_ext -i
numpy
Forcing DISTUTILS_USE_SDK=1
Building testing ufuncs!
running build_ext
building 'errno' extension
C compiler: gcc -g -DDEBUG -DMS_WIN64 -mno-cygwin -O0 -Wall -Wstrict-prototypes
compile options: '-DSWIG_COBJECT_TYPES=1 -DGSL_RANGE_CHECK=1 -DDEBUG=1 -DNUMERIC=0 -DPYGSL_GSL_MAJOR_VERSION=1 -DPYGSL_GSL_MINOR_VERSION=15 -UNDEBUG -IC:\Users\Bereket\gsl-1.15\include -IInclude -I. -IC:\Python27\lib\site-packages\numpy\core\include -IC:\Python27\include -IC:\Python27\PC -c'
gcc -g -DDEBUG -DMS_WIN64 -mno-cygwin -O0 -Wall -Wstrict-prototypes -DSWIG_COBJECT_TYPES=1 -DGSL_RANGE_CHECK=1 -DDEBUG=1 -DNUMERIC=0 -DPYGSL_GSL_MAJOR_VERSION=1 -DPYGSL_GSL_MINOR_VERSION=15 -UNDEBUG -IC:\Users\Bereket\gsl-1.15\include -IInclude -I. -IC:\Python27\lib\site-packages\numpy\core\include -IC:\Python27\include -IC:\Python27\PC -c src/init/errorno.c -o build\temp.win-amd64-2.7\Release\src\init\errorno.o
Found executable C:\cygwin\bin\gcc.exe
gcc -g -mno-cygwin -shared build\temp.win-amd64-2.7\Release\src\init\errorno.o -LC:\Users\Bereket\gsl-1.15\lib -LC:\Python27\libs -LC:\Python27\PCbuild\amd64 -lgsl -lgslcblas -lm -lpython27 -lmsvcr90 -o C:\Python27\Lib\pygsl-0.9.5\pygsl\errno.pyd
build\temp.win-amd64-2.7\Release\src\init\errorno.o: In function `add_errno':
/cygdrive/c/Python27/Lib/pygsl-0.9.5/src/init/errorno.c:14: undefined reference to `__imp__PyInt_FromLong'
/cygdrive/c/Python27/Lib/pygsl-0.9.5/src/init/errorno.c:20: undefined reference to `__imp__PyDict_SetItemString'
build\temp.win-amd64-2.7\Release\src\init\errorno.o: In function `initerrno':
/cygdrive/c/Python27/Lib/pygsl-0.9.5/src/init/errorno.c:37: undefined reference to `__imp__Py_InitModule4_64'
/cygdrive/c/Python27/Lib/pygsl-0.9.5/src/init/errorno.c:40: undefined reference to `__imp__PyModule_GetDict'
collect2: ld returned 1 exit status
error: Command "gcc -g -mno-cygwin -shared build\temp.win-amd64-2.7\Release\src\init\errorno.o -LC:\Users\Bereket\gsl-1.15\lib -LC:\Python27\libs -LC:\Python27\PCbuild\amd64 -lgsl -lgslcblas -lm -lpython27 -lmsvcr90 -o C:\Python27\Lib\pygsl-0.9.5\pygsl\errno.pyd" failed with exit status 1
I'm pretty sure now that my GSL install with Cygwin failed / had unresolved dependencies. I'm now trying to install it with visual studio 2010. Here are some good sites for doing that:
Instructions
Alt Method
Installing the Python 2.7 compiler for Windows is a good place to start
http://www.microsoft.com/en-gb/download/details.aspx?id=44266
Running python setup.py build_ext --inplace does the trick for me.
If this doesn't work let me know. You might need to add an environment variable.
Is your Python 32 or 64? To check open Python and do
import sys
sys.versions
I'm trying to get llvm-gcc 4.2.2.9 to compile on this x86_64 system which runs the 3.0.0-21-generic kernel. llvm 2.9 itself builds fine. I suspected the downloadable version of llvm-gcc was causing some other problems, so I decided to build llvm-gcc myself.
Like suggested in the README.LLVM I configured with
../llvm-gcc-4.2-2.9.source/configure \
--prefix=/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install \
--disable-multilib \
--program-prefix=llvm- \
--enable-llvm=/opt/llvm-2.9 \
--host=x86_64-generic-linux-gnu
--enable-languages=c,c++
I'm running this from the /opt/llvm-gcc4.2-2.9 directory, while the sources are sitting in /opt/llvm-gcc-4.2-2.9.source and my llvm 2.9 lives in /opt/llvm-2.9. Note that I'm setting the --host instead of the --target as this implicitly sets the --target to the same architecture.
make does build a lot of stuff (producing a sizeable amount of warnings) when finally stopping at this error:
make[3]: Entering directory `/opt/llvm-gcc4.2-2.9/gcc'
/opt/llvm-gcc4.2-2.9/./gcc/xgcc -B/opt/llvm-gcc4.2-2.9/./gcc/ -B/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/bin/ -B/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/lib/ -isystem /opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/include -isystem /opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../llvm-gcc-4.2-2.9.source/gcc -I../../llvm-gcc-4.2-2.9.source/gcc/. -I../../llvm-gcc-4.2-2.9.source/gcc/../include -I../../llvm-gcc-4.2-2.9.source/gcc/../libcpp/include -I../../llvm-gcc-4.2-2.9.source/gcc/../libdecnumber -I../libdecnumber -I/opt/llvm-2.9/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer -fno-asynchronous-unwind-tables \
-c ../../llvm-gcc-4.2-2.9.source/gcc/crtstuff.c -DCRT_BEGIN \
-o crtbegin.o
In file included from /usr/include/stdio.h:28,
from ../../llvm-gcc-4.2-2.9.source/gcc/tsystem.h:90,
from ../../llvm-gcc-4.2-2.9.source/gcc/crtstuff.c:68:
/usr/include/features.h:323:26: error: bits/predefs.h: No such file or directory
/usr/include/features.h:356:25: error: sys/cdefs.h: No such file or directory
/usr/include/features.h:388:23: error: gnu/stubs.h: No such file or directory
I find it a bit odd that the include path goes from my system's stdio.h back to llvm-gcc headers and then tries again to include system headers. But maybe that's normal?
After that error hundreds of lines with more errors follow from the same compilation unit.
Could it be that my system's gcc 4.6.1 or my system's headers maybe grew incompatible with the dated llvm-gcc 4.2 headers? Then again, I know that on a different system (running the 2.6 kernel) gcc 4.5.2 plays well with llvm 2.7's gcc 4.2.
I'm at a loss here, because I do need a recent llvm 2.*, and the other two acceptable llvm versions (2.7, 2.8) didn't show any result more helpful.
It seems that /usr/include on your system provides 32-bit headers, thus the compilation fails since you do not have all multilib headers installed. You might need to patch llvm-gcc the same way as your distribution patches gcc in order to find the headers locations.
Alternatively, you might try to install 32-bit headers and try multilib build of llvm-gcc.
But the best way will be switch to LLVM 3.1 and clang :)