I have a 64 bit Cygwin on my 64 bit Win7.
I installed gcc-core and gcc-g++ packages.
I made a simple C program:
#include <stdio.h>
int main() {
exit(0);
}
when I compile with: gcc-c test.c I got:
fatal error: stdio.h: No such file or directory
Doing it with -v flag I see:
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/include
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/include-fixed
/usr/include
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../lib/../include/w32api
End of search list.
GNU C (GCC) version 4.8.3 (x86_64-pc-cygwin)
The stdio.h which comes with gcc-core package is present on my pc at this location (which is fine according to Cygwin's package searcher also):
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/include/ssp/stdio.h
What it means that ssp directory and why stdio.h is placed there ?
Why gcc cannot find stdio.h present at this location ?
The file you found in the ssp directory is not a version of <stdio.h>. It only contains extra information about some of the functions in <stdio.h> for the stack-smash protector feature in gcc.
The actual <stdio.h> should be in /usr/include.
This line in your -v output is very interesting:
/usr/inlude
How did you get a /usr/inlude with no c?
Oops, the missing c in inlude was deleted in the edit by Keith Thompson.
So your gcc should be finding /usr/include/stdio.h if you have it. Is it there? As far as I can tell from the package file lists, it's supposed to be part of the cygwin base system (i.e. even if you haven't installed the compiler it should be there).
Are you missing any other header files? <stdlib.h> and <string.h> are good test candidates.
Here are some commands to investigate the cygwin package and whether it contains the file:
cygcheck -f /usr/include/stdio.h
cygcheck -c cygwin
cygcheck -l cygwin | grep stdio
UPDATE: so it seems I'm behind the times and there's a cygwin-devel package now. The header files aren't in the base cygwin package any more. To check the correct package on the latest cygwin, you'd use
cygcheck -c cygwin-devel
as has already been done in the comments. And since it's listed as "incomplete" the solution is probably to reinstall it using cygwin's setup program.
Related
In the process of trying to build some software AVL I'm getting some X11 library issues. I've done this install a few years ago and remember it being straight forward, but it was on an older version of OS el capitan I think and I'm on a "lite" version of Big Sur. I installed XQuartz and I can see the files it's expecting, but it seems to have trouble with the path to X11 per my understanding of this error
In file included from xwin11/Xwin2.c:74:
/usr/X11/include/X11/Xlib.h:44:10: fatal error: 'X11/X.h' file not found
In order for it to find Xlib.h I modified this (which I'm pretty sure isn't correct)
from
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/cursorfont.h>
to
#include </usr/X11/include/X11/Xlib.h>
#include </usr/X11/include/X11/Xutil.h>
#include </usr/X11/include/X11/cursorfont.h>
Before it would die on finding Xlib.h. It also seems to be ignoring the linking line I gave it in the config.make file
LINKLIB = -I/usr/X11/include -L/usr/X11/lib -lX11
Is there an environment variable or path I'm missing in my profile? Is it ignoring the linking flag. Or did I set this up incorrectly in the config file? What's really odd is that now it's finding Xlib.h but it can't find X.h and they live in the same folder, which really makes me think it just doesn't know where to find the X11 "stuff" .
Thanks!
Here's how to solve it:
determine from the compiler messages what include files the compiler cannot find
find them yourself
tell the compiler where they are
repeat above steps for libraries it cannot link
So, it cannot find Xlib.h. Let's find that:
find / -name Xlib.h 2>/dev/null
and, on my machine, I find:
/opt/X11/include/X11/Xlib.h
So that means I need to tell the compiler where to look for header files like this:
g++ -I /opt/X11/include ...
Then, when it encounters this in your code:
#include <X11/Xlib.h>
that means it will actually be expecting to find:
/opt/X11/include/X11/Xlib.h
Now, let's do the libraries:
find / -name libX11.dylib 2> /dev/null
and, on my machine, I find:
/opt/X11/lib/libX11.dylib
so that means I need:
g++ -I /opt/X11/include -L /opt/X11/lib/ ...
Thanks #MadScientist your comment was the key. I moved the
-I/usr/X11/include
out of the linking flag and into the compile flag and that solved it!
I have a problem using Apache Portable Runtime on Ubuntu with GCC 4.8.1
The problem is that the off64_t from <sys/types.h> is not available when compiling with gcc. (When compiling with g++ everything work fine)
Does anybody know which compiler switch to use to enable off64_t? (I know that defining _LARGEFILE_SOURCE _LARGEFILE64_SOURCE avoids the problem, but wondering if this is the right way)
To reproduce the error one can simply try to compile the following code:
#include <sys/types.h>
off64_t a_variable;
off64_t is not a language defined type. No compiler switch will make it available.
It is defined in sys/types.h, but (on a 32 bit system) only if
_LARGEFILE64_SOURCE is defined
Which will make the 64 bit interfaces available (off64_t, lseek64(), etc...).
The 32 bit interfaces will still be available by their original names.
_FILE_OFFSET_BITS is defined as '64'
Which will make the names of the (otherwise 32 bit) functions and data types refer to their 64 bit counterparts.
off_t will be off64_t, lseek() will use lseek64(), and so on...
The 32 bit interface is no longer available.
Make sure that if you define these macros anywhere in your program, you define them at the beginning of all your source files. You don't want ODR violations to be biting you in the ass.
Note, this is for a 32 bit system, where off_t is normally a 32 bit value.
On a 64 bit system, the interface is already 64 bits wide, you don't need to use these macros to get the large file support.
off_t is a 64 bit type, lseek() expects a 64 bit offset, and so on.
Additionally, the types and functions with 64 in their name aren't defined, there's no point.
See http://linux.die.net/man/7/feature_test_macros
and http://en.wikipedia.org/wiki/Large_file_support
You also may be interested to know that when using g++, _GNU_SOURCE is automatically defined, which (with the gnu c runtime library) leads to _LARGEFILE64_SOURCE being defiend. That is why compiling your test program with g++ makes off64_t visible. I assume APR uses the same logic in making _LARGEFILE64_SOURCE defined.
Redefine off64_t to __off64_t in your compile flag. Edit your Makefile so it contains:
CFLAGS= -Doff64_t=__off64_t
then, just run $ make 1 (assuming you have 1.c in your directory)
A bit late, but still current.
I simply add -Doff64_t=_off64_t to the compiler flags.
In my environment gcc version 4.1.2, I need to define __USE_LARGEFILE64. I found this macro from /usr/include/unistd.h who defines lseek64()
#define __USE_LARGEFILE64
#include <sys/types.h>
#include <unistd.h>
You should define $C_INCLUDE_PATH to point to linux headers, something like
export C_INCLUDE_PATH=/usr/include/x86_64-linux-gnu
To install linux header, use
sudo apt-get install linux-headers-`uname -r`
P.S.
$ cat 1.c
#include <sys/types.h>
off64_t a_variable;
int main(){return 0;}
$ gcc --version
gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
$ echo $C_INCLUDE_PATH
/usr/include/x86_64-linux-gnu
$ grep off64_t /usr/include/x86_64-linux-gnu/sys/types.h
typedef __off64_t off_t;
#if defined __USE_LARGEFILE64 && !defined __off64_t_defined
typedef __off64_t off64_t;
# define __off64_t_defined
Sorry for the lateness but I did never had to embed perl code in C programs untill today ^^
I solved the issue in Unix/Linux systems (I think it is possible to create such feature in Windows since Vista) by creating a symbolic link pointing to the CORE folder of perl version...
ln -s $(perl -MConfig -e 'print $Config{archlib}')/CORE /usr/include/perl
In your project file, source code, simply add:
#include <perl/EXTERN.h>
#include <perl/perl.h>
...and I came from long list of notes and errors related to off_t and off64_t to a clean build result ^^
Also late to the party, but the main reason for receiving this issue was installing the 64-bit version of MinGW instead of 32-bit:
https://sourceforge.net/projects/mingw/
I am trying to read and understand some of the c++11 code from clang-3.4. But I couldn't find standard headers. I am using mingw32 and build clang from source to default location at /usr/local/lib/clang/3.4.
I tried to look for and did
$ find |grep iostream
from that folder and it returned nothing. I can however compile code with fine.
Where are the clang implementation of c++11? Am I looking at the wrong folder?
--- Update ---
I built clang 3.4 from source under Windows XP 64-bit, using mingw32 (from mingw.org). I configured clang/llmv in MSYS using:
./configure --enable-pic --disable-docs --enable-targets=x86,cpp
So, I assume that clang is installed to /usr/local/, and indeed find clang/3.4 under usr/local/lib. But maybe the header files are elsewhere as suggested by the comment, I did another find/grep in the entire MinGW folder (containing MSYS) and still couldn't find the iostream file. The only thing I got was gcc version:
$ cd /c/mingw
$ find | grep iostream
./lib/gcc/mingw32/4.8.1/include/c++/iostream
./mingw32/lib/gcc/mingw32/4.8.1/include/c++/iostream
-- Update 2 ---
I tried install libcxx, using cmake
cmake -G"MSYS Makefiles" ../libcxx-3.4
make
, and got the following error:
...
[100%] Building CXX object lib/CMakeFiles/cxx.dir/__/src/support/win32/support.c
pp.obj
d:/temp/tdm/libcxx-3.4/src/support/win32/support.cpp: In function 'size_t wcsnrt
ombs(char*, const wchar_t**, size_t, size_t, mbstate_t*)':
d:/temp/tdm/libcxx-3.4/src/support/win32/support.cpp:134:88: error: 'wcrtomb_s'
was not declared in this scope
result = wcrtomb_s( &char_size, dst + dest_converted, dest_remainin
g, c, ps);
...
Clang builds separately from libc++, so you need to install it first to get that <iostream> include file.
Alternatively, you can instal MinGW, which comes with GNU libstdc++.
For a week I've been struggling with compiling openCV programs. I've tried everything I could possibly find on the internet.
What I did is: I've downloaded OpenCV-2.3.1-win-superpack.exe and followed this official installation guide.
In the CMake (gui) my source was: D:\opencv and build destination was: C:\opencv.
I've also added C:\opencv\install\bin;C:\opencv\bin to my system's PATH variable.
What I want is to compile openCV programs on my Windows OS using MinGW's gcc/g++ compilers.
I've tried various gcc/g++ parameters that I've found on the internet and days playing with the -I and -L options the compiler can never find the openCV functions or structures.
What I am trying to compile:
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <cv.h>
#include <highgui.h>
int main(int argc, char *argv[])
{
// Nothing but create a window
cvNamedWindow("mainWin", CV_WINDOW_AUTOSIZE);
cvMoveWindow("mainWin", 100, 100);
cvWaitKey(0);
return 0;
}
Error:
Input:
gcc test.c -o test -I"C:\opencv\install\include" -I"C:\opencv\install\include\opencv" -L"C:\opencv\install\bin"
Output:
...\ccK4MfHv.o:test.c:(.text+0xa0b): undefined reference to `cvFree_'
Or with g++:
Input:
g++ test.c -o test -I"C:\opencv\install\include" -I"C:\opencv\install\include\opencv" -L"C:\opencv\install\bin"
Output:
...\ccXCTKa1.o:test.c:(.text+0x1e): undefined reference to `cvNamedWindow'
Side note: trying to compile in VS2005 I get the same error.
Thank you for your time!
In case someone else needs to solve this issue, here's how I got the posted OpenCV/HighGUI sample code to compile in Windows 7 x64 using MinGW, MSYS, and CMake:
build OpenCV from source using MinGW/MSYS/CMake. This is because I could not get the MinGW compiled version in the OpenCV-win-SuperPack to link properly in MinGW/MSYS/Windows 7 x64.
For full reference, here's how I compiled OpenCV:
make sure you have an up-to-date CMake (v2.6 or later) and MinGW (with GCC, G++, and MSYS options) installed
if you want the new Qt-based OpenCV HighGUI front-end, you will need to install Qt 4 (SDK).
download a OpenCV source/superpack version 2.2 or later (I used OpenCV-2.3.1-win-superpack.exe)
unzip the contents to [OPENCV_SOURCE_DIR] (I put it in C:/opencv, so there should be a file at C:/opencv/README for example)
create a [OPENCV_BUILD_DIR] directory elsewhere (I used C:/opencv/build/mingw)
use the CMake-GUI tool, specify the source directory as [OPENCV_SOURCE_DIR], the build directory as [OPENCV_BUILD_DIR], and click "Configure".
you may wish/need to go tweak the options (e.g. I ticked "Qt" and "Qt-OpenGL" entries, then clicked "Configure" again, then had to provide the path to the qmake executable)
once you have finished configuring OpenCV, click "Generate"
in a MSYS terminal, browse to [OPENCV_BUILD_DIR], and run "make" to build the code (this may take a while)
once the has been built properly, run "make install", which collects the built code/libraries/include dirs into [OPENCV_BUILD_DIR]/install folder (or a different folder if you changed the corresponding option when using the CMake-GUI tool)
add [OPENCV_BUILD_DIR]/install/bin folder to the PATH environmental variable. If you do not know how to do this, then I'd recommend using the Path Editor GUI tool.
if you end up using Qt, you will also need to put the bin folder of Qt SDK in the PATH environmental variable. This is the folder that includes qmake.exe.
put the following sample code into a file called test.c. I modified the includes slightly to make them compatible with OpenCV v2.2 and above.
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <opencv/cv.h>
#include <opencv/highgui.h>
int main(int argc, char *argv[])
{
// Nothing but create a window
cvNamedWindow("mainWin", CV_WINDOW_AUTOSIZE);
cvMoveWindow("mainWin", 100, 100);
cvWaitKey(0);
return 0;
}
in a MSYS terminal, browse to the folder where you put test.c, and run:
gcc -o test -I"[OPENCV_BUILD_DIR]/install/include" test.c \
-L"[OPENCV_BUILD_DIR]/install/lib" \
-lopencv_core[OPENCV_VERSION] \
-lopencv_imgproc[OPENCV_VERSION] \
-lopencv_highgui[OPENCV_VERSION]
So in my case:
gcc -o test -I"/c/opencv/build/mingw/install/include" test.c \
-L"/c/opencv/build/mingw/install/lib" \
-lopencv_core231
-lopencv_imgproc231
-lopencv_highgui231
Path Editor: http://www.redfernplace.com/software-projects/patheditor/
You have the directory, C:\opencv\install\bin, to locate libraries on the gcc/g++ command line, but I think you'll also need to specify the libraries to use as linker inputs as well. I'm not sure what libraries are part of the OpenCV distribution, but going by the example on the instruction page you linked to, one might be:
-lopencv_calib3d220.dll
You'll probably have to add one or more other ones (that follow the name pattern lib*.a in the C:\opencv\install\bin directory - or maybe some other lib directory that you should be passing in a -L option).
I have installed the latest version of Cygwin, selecting the following packages during setup:
libgcc1
gcc
gcc-core
And created a file (test.c) with only this line:
#include <link.h>
Then ran the following from my Cygwin bash:
$ gcc test.c
... but got this error:
test.c:1:18: link.h: No such file or directory
Any ideas how I can fix it?
Cygwin is based on the Win32 subsystem, which means it uses Windows' executable format (COFF) and dynamic linker, i.e. it does not have an ELF dynamic linker. Hence providing the ELF-specific <link.h> would probably make little sense.