I'm reading expert c, and got through setjump and longjump section, so want make the code running on my ubuntu 11.10, but when I include setjump.h, the gcc compiler complain that it can't find the header file, I find there is not a setjump.h in the /user/include/ directory.
So what should I do? Can you give me some suggestions?
From the setjmp(3) man page:
SYNOPSIS
#include <setjmp.h>
Related
In order to ensure that the asprintf function is visible in the header file <stdio.h>, I have followed the advice of the man page and put:
#define _GNU_SOURCE
#include <stdio.h>
// ... uses of asprintf();
This works in normal C programs, although presumably only on GNU/Linux and not on the BSDs.
I would like to be able to use the same trick in a flex lexer, e.g.:
%{
#define _GNU_SOURCE
#include <stdio.h>
%}
%%
\"[^\"].+\" {
asprintf(&(yylval.string), "%s", yytext);
return STRING;
}
%%
// ...
but I get a compile warning (implicit-function-declaration) for asprintf.
Upon further investigation, this is because in the C file that flex generates it includes <stdio.h> before my preamble code, without defining _GNU_SOURCE first.
How can I write code which uses this function which
compiles correctly inside flex rules, and
(optionally) also works in non-GNU environments?
Having re-checked the book that got me into the habit of using asprintf, I have discovered that it is indeed a GNU extension.
It is available in a GCC library called libiberty, which you can use in place of the _GNU_SOURCE macro.
I was able to install this on Ubuntu 15.10 and Debian 8.2 using:
sudo apt-get install libiberty-dev
I then modified the preamble to include:
%{
#include <libiberty/libiberty.h>
%}
and everything worked without any warnings.
Assuming that a libiberty package is available for non-Linux distributions (and given that it is part of GCC I would assume this would be the case) this solution should work cross platform (on POSIX-ish OS's.)
I am on OS X 10.10 and trying to build a C 'project' with GLUT and OpenGL.
I reduced it to a minimal example showcasing my problem. I have the following CMakeLists.txt:
cmake_minimum_required(VERSION 2.8)
FIND_PACKAGE(OpenGL REQUIRED)
FIND_PACKAGE(GLUT REQUIRED)
if(OpenGL_FOUND) # never true, but printed as true
link_directories(${OpenGL_LIBRARY_DIRS})
include_directories(${OpenGL_INCLUDE_DIR})
endif(OpenGL_FOUND)
if(GLUT_FOUND)
link_directories(${GLUT_LIBRARY_DIR})
include_directories(${GLUT_INCLUDE_DIR})
endif(GLUT_FOUND)
# print all vars because wtf
get_cmake_property(_v VARIABLES)
foreach(_v ${_v})
message(STATUS "${_v}=${${_v}}")
endforeach()
add_executable(main main.c)
target_link_libraries(main ${GLUT_LIBRARY} ${OPENGL_LIBRARY})
The main.c is just a dummy including two headers:
#include <gl.h>
#include <glut.h>
int main()
{
return 0;
}
Now, cmake . runs fine and for debugging purposes prints all variables. I took the code from somewhere, I do not know enough about cmake to know whether it's doing what I think it is. Anyway, running make returns
main.c:1:10: fatal error: 'gl.h' file not found
#include <gl.h>
^
1 error generated.
The header gl.h is actually present in /System/Library/Frameworks/OpenGL.framework/Headers and as such should be found by cmake, especially since glut.h is in the same structure (simply replace OpenGL with GLUT) and is found just fine. Also, what is confusing to me is that the block in if(GLUT_FOUND)... is never executed (try to put a message statement into it), but among the printed variables it says OPENGL_FOUND=TRUE. But removing the if-condition does not change anything.
The actual question: What the hell is going on? Why does a) cmake not find the header unless specifically included, b) the if-block not execute although OPENGL_FOUND prints as TRUE, c) no such problems occur with glut.h? Spent hours on this and can't fathom why.
It's common to do
#if defined(__APPLE__)
#include <OpenGL/gl.h>
#include <OpenGL/glu.h>
#else
#include <GL/gl.h>
#include <GL/glu.h>
#endif
You can see this being done in one form or another in glfw, glew, sfml and others
I'm surprised that you found OpenGL headers in /System/Library/Frameworks in OS X 10.10. I don't think they have been installed there in quite a few Xcode releases. The most recent header files with Xcode 6.1 on 10.10 should be in:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/OpenGL.framework/Headers
You don't really need to know this path, unless you want to go look at the headers. I believe the compiler automatically uses the SDK that matches the OS you're compiling on. If for some reason you wanted to build for a different platform, you can override that logic with the -isysroot compiler option.
With header files that come from a framework, the naming you use in your #include statement is:
#include <FrameworkName/HeaderFileName.h>
The compiler will resolve this to the actual pathname of the header within the framework.
Therefore, if you want to use the current OpenGL header, which is gl3.h, from the OpenGL framework, the correct include statement is:
#include <OpenGL/gl3.h>
This will give you access to the Core Profile of the highest supported OpenGL version (which is 3.x or 4.x if you have a reasonably new Mac). Or if you want to use OpenGL 2.1 with legacy features:
#include <OpenGL/gl.h>
As pointed out bei pmr, CMake variables are case-sensitive, so the variable OPENGL_FOUND must be queried.
Also, as PeterT wrote, the header is included as #include <OpenGL/gl.h> on OS X.
I ended up coming to this question after updating qt installed from homebrew and had the same error messages. Going off of Reto's comment, I updated CMAKE_OSX_SYSROOT to /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk and everything went back to working as expected.
Looking into learning C. As I understand it when I say #include <stdio.h> it grabs stdio.h from the default location...usually a directory inside your working directory called include. How do I actually get the file stdio.h? Do I need to download a bunch of .h files and move them from project to project inside the include directory? I did the following in a test.c file. I then ran make test and it outputted a binary. When I ran ./test I did not see hello print onto my screen. I thought I wasn't seeing output maybe because it doesn't find the stdio.h library. But then again if I remove the greater than or less than signs in stdio the compiler gives me an error. Any ideas?
I'm on a Mac running this from the command line. I am using: GNU Make 3.81. This program built for i386-apple-darwin10.0
#include <stdio.h>
main()
{
printf("hello");
}
Edit: I have updated my code to include a datatype for the main function and to return 0. I still get the same result...compiles without error and when I run the file ./test it doesn't print anything on screen.
#include <stdio.h>
int main()
{
printf("hello");
return 0;
}
Update:
If I add a \n inside of the printf it works! so this will work:
#include <stdio.h>
int main()
{
printf("hello\n");
return 0;
}
Your code should have preferably
printf("hello\n");
or
puts("hello");
If you want to know where does the standard header file <stdio.h> comes from, you could run your compiler with appropriate flags. If it is gcc, try compiling with
gcc -H -v -Wall hello.c -o hello
Pedantically, a standard header file is even not required to exist as a file; the standard permits an implementation which would process the #include <stdio.h> without accessing the file system (but e.g. by retrieving internal resources inside the compiler, or from a database...). Few compilers behave that way, most really access something in the file system.
If you didn't have the file, you'd get a compilation error.
My guess is the text was printed, but the console closed before you got the chance to see it.
Also, main returns an int, and you should return 0; to signal successful completion.
#include <header.h>, with angle brackets, searches in standard system locations, known to the compiler-- not in your project's subdirectories. In Unix systems (including your Mac, I believe), stdio.h is typically in /usr/include. If you use #include "header.h", you're searching subdirectories first and then the same places as with <header.h>.
But you don't need to find or copy the header to run your program. It is read at compilation time, so your ./test doesn't need it at all. Your program looks like it should have worked. Is it possible that you just typed "test", not "./test", and got the system command "test"? (Suggestion: Don't name your programs "test".)
Just going to leave this here : STILL! in 2018, December... Linux Mint 18.3
has no support for C development.
innocent / # cc ThoseSorts.c
ThoseSorts.c:1:19: fatal error: stdio.h: No such file or directory
compilation terminated.
innocent / # gcc ThoseSorts.c
ThoseSorts.c:1:19: fatal error: stdio.h: No such file or directory
compilation terminated.
innocent / # apt show libc6
(Abbreviated)::
Package: libc6
Version: 2.23-0ubuntu10
Priority: required
Section: libs
Source: glibc
Origin: Ubuntu
Installed-Size: 11.2 MB
Depends: libgcc1
Homepage: http://www.gnu.org/software/libc/libc.html
Description: GNU C Library: Shared libraries
Contains the standard libraries that are used by nearly all programs on
the system. This package includes shared versions of the standard C library
and the standard math library, as well as many others.
innocent / # apt-get install libc6-dev libc-dev
So, magic... and a minute later they are all installed on the
computer and then things work as they should.
Not all distros bundle up all the C support libs in each ISO.
Hunh.
hardlyinnocent / # gcc ThoseSorts.c
hardlyinnocent / # ./a.out
20
18
17
16
... ... ...
I keep getting this error:
c:\cygwin\usr\include/cygwin/socket.h:55:3: error: expected specifier-qualifier-list before '__uid32_t'
My code is mininmal and still can't compile:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/socket.h>
int main(void) {
puts("!!!Hello World!!!"); /* prints !!!Hello World!!! */
return EXIT_SUCCESS;
}
I have include C:\cygwin\usr\include to compiler path and linker to C:\cygwin\usr\lib
please advise
Headers under C:\cygwin\usr\include, and libraries under C:\cygwin\usr\lib, are for use in the Cygwin environment -- which means they should be referred to via their Cygwin paths, /usr/include and /usr/lib.
I haven't used mingw, but I don't think it's part of Cygwin, and I wouldn't expect it to be able to use Cygwin's headers and libraries.
If you're going to use mingw, you should use the headers and libraries that are installed with it. Don't specify any Cygwin-related directories.
Or you can use Cygwin's gcc (which is optional; you'll have to install it with setup.exe). In that case, you can run gcc or make from the command line. I'm not sure whether Cygwin and Eclipse play nicely together.
I know this question is old, and I'm using a newer version, but I had a similar issue and it was resolved by moving #include <sys/socket.h> one line above #include <sys/types.h>.
Something in types.h appears to be blocking socket.h (not sure how). Wish I had more details on the cause, but hope the solution helps some.
My understanding was always that by doing #include <header.h> it looks in the system include directories, and that #include "header.h" it looks in the local directory. But I was just looking at the python source code and it uses the "header.h" method to define headers in a sibling directory.
So in py3k/Python/ast.c it does #include "Python.h". But Python.h is in py3k/Include/Python.h
Is this something common that I've just never seen, not having worked on any real large C project? How do I tell, at least my IDE, to look in py3k/Include?
Update
I figured out how to tell my IDE to include them, it was just me being stupid and a spelling error. But I'm more interested in why "" works. Is that not the different between "" and <>?
Both #include <header> and #include "header" look in "implementation-defined places", i.e. it depends on the compiler you are using and its settings. For #include <h> it's usually some standard system include directories and whatever you configure the compiler to look in additionally.
The difference between the two versions is that if the search for #include "header" is not supported or fails, it will be reprocessed "as if it read #include <header>" (C99, ยง6.10.2).
You need to somehow tell your compiler what directories to search in -- for GCC this means using the -I flag. Look it up for your combination of IDE / compiler.