I'm using Cygwin to make the makefile of kore.io on Windows 10 and get the following error:
gcc -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wshadow -Wpointer-arith -Wcast-qual -Wsign-compare -Iincludes -std=c99 -pedantic -DPREFIX='"/usr/local"' -O2 -c src/kore.c -o obj/kore.o
src/kore.c:20:24: fatal error: sys/socket.h: No such file or directory
compilation terminated.
make: *** [obj/kore.o] Fout 1
I've looked around, but none of the solutions I found worked for me.
I checked the Cygwin /usr/include/sys folder and did find socket.h.
I read through the makefile and don't see anything wrong with the lib references.
I've been trying to get this work for over an hour now.
Thanks in advance.
To find which package you need to install, use cygcheck to find the package containing sys/socket.h
$ cygcheck -p usr/include/sys/socket.h
Found 5 matches for usr/include/sys/socket.h
cygwin-devel-2.6.1-1 - cygwin-devel: Core development files (installed binaries and support files)
cygwin-devel-2.7.0-1 - cygwin-devel: Core development files
cygwin-devel-2.8.0-1 - cygwin-devel: Core development files
cygwin32-2.5.2-1 - cygwin32: Cygwin 32bit toolchain (installed binaries and support files)
cygwin32-2.6.0-1 - cygwin32: Cygwin 32bit toolchain (installed binaries and support files)
So you need to install cygwin-devel that contains the cygwin standard headers.
Related
When attempting to compile GNU GCC 5.3.0 I encounter the following error when it tries to build libjavamath.la.
/bin/bash ../../../libtool --tag=CC --mode=link /home/borish/Downloads/gcc-build/./gcc/xgcc -B/home/borish/Downloads/gcc-build/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -Iyes/include -g -O2 -module -version-info 0:0:0 -no-undefined -Lyes/lib -lgmp -avoid-version -o libjavamath.la -rpath /usr/local/lib/../lib64/gcj-5.3.0-16 gnu_java_math_GMP.lo ../../../native/jni/classpath/jcl.lo
../../../libtool: line 5209: cd: yes/lib: No such file or directory
libtool: link: cannot determine absolute directory name of `yes/lib'
Makefile:403: recipe for target 'libjavamath.la' failed
This is on a Debian 8.4 system with GCC 4.9.2-10 installed. I believe I have satisfied all of the prerequisites, and Google wasn't been much help.
Any thoughts?
Update:
I used the following for running the configuration script:
../gcc-5.3.0/configure --disable-multilib --with-mpc --with-isl --with-mpfr --with-gmp
It sounds like you didn't run "configure" correctly. For example:
https://software.ecmwf.int/issues/browse/SUP-676
OK, I see a problem already, the "--with-jasper" option must point the
to the prefix of the "jasper" installation, for example
$./configure --with-jasper=/usr/local/jasper --with-png-support.
Otherwise the value "yes" is set as prefix..
For example, if you look here:
http://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html
you'll see that a flag like ‘--with-headers=directory’ REQUIRES YOU TO ENTER A DIRECTORY PATH. I suspect the same thing is happening with your "-with-mpc" etc.
SUGGESTION: clean your build directory, and (carefully!) re-run ./configure.
The culprit appears to be the --with-gmp, --with-mpc and --with-mpfr switches when initiating the configure script. I suspect since libgmp is a prerequisite for libmpc and libmpfr, a bug feature in the configure script will include the offending -I and -L directives. Inclusion of any of them will result in the following in the root Makefile
HOST_GMPLIBS = -Lyes/lib -lmpc -lmpfr -lgmp
HOST_GMPINC = -Iyes/include
I haven't confirmed this to be the case in any of the other Makefiles, but I suspect something similar is going on elsewhere which is what I ran into when it attempted to building libjavamath.la.
The work around is to omit those switches from the configure invocation. They should be included in any event since the configure script will fail if they aren't present on the host.
I am trying to compile a Python PCL module which builds some C++ source. I am getting this error:
$ python setup.py install
running install
running build
running build_py
running build_ext
skipping 'pcl/_pcl.cpp' Cython extension (up-to-date)
building 'pcl._pcl' extension
/usr/bin/clang -fno-strict-aliasing -fno-common -dynamic -g -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Library/Python/2.7/site-packages/numpy/core/include -I/usr/local/Cellar/pcl/HEAD/include/pcl-1.8 -I/usr/local/Cellar/eigen/3.2.3/include/eigen3 -I/usr/local/Cellar/pcl/HEAD/include/pcl-1.8 -I/usr/local/Cellar/flann/1.8.4/include -I/usr/local/Cellar/pcl/HEAD/include/pcl-1.8 -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c pcl/_pcl.cpp -o build/temp.macosx-10.6-intel-2.7/pcl/_pcl.o
pcl/_pcl.cpp:244:10: fatal error: 'boost/smart_ptr/shared_ptr.hpp' file not
found
#include "boost/smart_ptr/shared_ptr.hpp"
^
1 error generated.
error: command '/usr/bin/clang'
For whatever reason clang isn't looking in /usr/local/include where it most definitely would find the boost headers. As you can see it is linking all the other dependencies fine. What can I add that so clang will find boost?
On OSX 10.10, nothing fancy happening anywhere. Boost was probably installed by homebrew, but the files are all in /usr/local/include/boost as I'd expect.
Check the output of /usr/bin/clang++ -v some_test_file.cpp but chances are /usr/local/include isn't in the standard search path of the compiler.
You'll need to add -I/usr/local/include to CXXFLAGS or CPPFLAGS or whatever appropriate place in your build script or environment. It seems the python build script is failing to properly detect Boost.
If the above is not true (and /usr/local/include does show up in the output), make sure /usr/local/include/boost/smart_ptr/shared_ptr.hpp exists.
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've installed gcc on my Mac (Snow Leopard) so I can compile for AVR microcontrollers. However, it seems to be preventing me from compiling for anything else. I'd like to build the packages from astrometry.net, and when I run ./configure then make i get the following:
make -C ./qfits-an stage CFLAGS=" -g -Wall -ffinite-math-only -fno-signaling-nans -march=native -O3 -fomit-frame-pointer -DNDEBUG -fPIC -Winline -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE" LDFLAGS=" -g -Wall -ffinite-math-only -fno-signaling-nans -march=native -O3 -fomit-frame-pointer -DNDEBUG -fPIC -Winline" CC="gcc"
make -C src stage
gcc -g -Wall -ffinite-math-only -fno-signaling-nans -march=native -O3 -fomit-frame-pointer -DNDEBUG -fPIC -Winline -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -c -o anqfits.o anqfits.c
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc -v gives:
Using built-in specs.
Target: avr
Configured with: ./configure --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --prefix=/usr/local/staging.avr-gcc
Thread model: single
gcc version 4.1.1
I'm not sure how to proceed! It seems that currently everything is set up to only build for the AVR platform, but I have Xcode installed so somewhere there are more versions of gcc lurking. This install was via http://www.micahcarrick.com/installing-gnu-tools-avr-gcc.html if that helps to see how it was set up (I had Xcode installed prior to this).
The solution, I expect, is simple. I just want to avoid messing up my settings and then not being able to compile for either platform.
Many thanks!
You probably want to remove the non-cross-compiler named versions of the AVR tools you have installed (i.e. gcc, ld, etc.), so the cross-compiler, and related tools, are only available using target-specific names.
To do this, find the directory where they are installed (/usr/local/bin ?) and find all the tools installed at the same time. As an example, this is what happens on my Linux machine (to give you an idea):
$ which gcc
/usr/bin/gcc
$ cd /usr/bin
$ ls -li *gcc*
189389 -rwxr-xr-x 2 root root 268088 Dec 6 2011 gcc
195145 -rwxr-xr-x 1 root root 2018 Aug 16 2010 gccmakedep
189389 -rwxr-xr-x 2 root root 268088 Dec 6 2011 x86_64-redhat-linux-gcc
I would then remove gcc, leaving x86_64-redhat-linux-gcc as the only way of starting that compiler (they are hard linked as they share the same inode). There will be other tools as well, which you can identify by date in the same directory.
An alternative approach is to install the cross-compiler into a directory that isn't in your $PATH.
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 :)