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.
Related
I am developing a C application, and using Eclipse CDT IDE, which I find great. The project uses Glib,Gtk,and GStreamer , so whenever I use some of their features in a file, I need to include:
#include <glib.h>
#include <gtk/gtk.h>
#include <gst/gst.h>
The code compiles without any error, since the PATH variable to search those headers is set correctly in a CMakeLists.txt.
However, while working on the project, I found annoying errors highlighting in my code, regarding type definitions like gchar or GValue or GTKApplication; the error outlined is "symbol **** could not be resolved". These definitions are inside a header file that my Eclipse IDE cannot find (included by glib.h), if not at compile time (indeed the program compiles correctly). Instead, the type GError , defined in gst.h , is not highlighted as an error by the pre-compiler.
I would like then that my Eclipse IDE could search on nested headers (#include inside an #inlcude inside...) to find those type definition, in order so to not have those annoying errors highlighting. How can I do so? I would not like to have to include directly all files where the type definitions are done.
EDIT: As Jonah Graham outlined, the problem is not beacuse Eclispe does a "single-step research" on the headers, since it inspects includes inside other includes like any other IDE. It is a CMake bug with c and Eclipse
Thanks in advance.
The problem you are facing is a CMake bug*. CMake adds __cplusplus into the defined symbols unconditionally, which means that glib headers are not parsed properly when in C mode. You can see this clearly by opening gmacros.h around the definition for G_BEGIN_DECLS:
Because CMake told CDT __cplusplus is defined, it thinks G_BEGIN_DECLS is also defined, which makes code like this from gtypes.h parse incorrectly:
G_BEGIN_DECLS
/* Provide type definitions for commonly used types.
* These are useful because a "gint8" can be adjusted
* to be 1 byte (8 bits) on all platforms. Similarly and
* more importantly, "gint32" can be adjusted to be
* 4 bytes (32 bits) on all platforms.
*/
typedef char gchar;
...
Of course with no gchar defined, everything else is going to go badly.
Luckily there is a quick workaround until the problem is resolved in CMake, remove __cplusplus from the info in CDT.
Open Project Properties
C/C++ Include Paths and Symbols
Remove __cplusplus from the list and press OK
(sometimes necessary) Right-click on project -> Index -> Rebuild
* There may be some other workarounds if you know CMake better. The bug says also it will be fixed for the next release of CMake.
I'm fairly new to programming with c and i am having a hard time including the squash library into my program.
I cloned the repository and ran ./configure and make sudo make install.
That installed the files:
/usr/local/lib/pkgconfig/squash-0.8.pc
/usr/local/lib/libsquash0.8.so.0.8
/usr/local/lib/libsquash0.8.so.0.8.0
/usr/local/lib/libsquash0.8.so
/usr/local/lib/cmake/Squash-0.8.0/SquashConfig.cmake
/usr/local/bin/squash
And some more files in this directories:
/usr/local/include/squash-0.8/
/usr/local/lib/squash/0.8/plugins/
In the squash examples the library is included by #include <squash/squash.h> but when i am trying to compile it i get fatal error: squash/squash.h: No such file or directory
Also #include <squash-0.8/squash.h> doesnt work because then i get fatal error: hedley/hedley.h: No such file or directory That file is located at
/usr/local/include/squash-0.8/squash/hedley/hedley.h
I guess the solution is pretty simple for an experienced c programmer but i am failing here..
Do i need to set some sort of environment variable to let the compiler find the library?
And how do i link the library to the compiler anyway?
I found something like:
-rdynamic ../squash/libsquash0.8.so.0.8 but could not test it yet because of the error above.
Try to change
#include <squash/squash.h>
to
#include "squash/hedley/hedley.h"
or
#include "<squash-0.8/squash/hedley/hedley.h>"
easier and faster solution would be adding the path to your includes during compilation:
-I/usr/local/include/squash-0.8/squash/
I've installed libssh following the instructions and even though everything seems to be OK my compiler still returns the error "file not found" in the line "#include ". I guess it has something to do with directories or links (I have "make install" in the same folder where I downloaded it) but I don't know where should I put it so I can #include it in any project.
This is how I installed it:
I downloaded it and unzip it into the folder "libssh" on my Desktop (Mac).
Then I did
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug ..
make
and finally:
sudo make install
Then in my program I have:
#include <libssh/sftp.h>
And XCode returns: "libssh/sftp.h file not found". I tried adding the libssh folder in the Desktop to the project, but I still have similar problems.
I guess I should install it (somehow) to the /usr/include folder, so that any project can use it (like pthread or many others), but I don't know how to do this.
If I include any other file in /usr/include it works fine (like ) but when I #include it returns file not found, even though if I cd to /usr/include/libssh the file libssh.h does exist.
This is the very simple sample code:
#include <stdio.h>
#include <pthread.h> //OK
#include <libssh/libssh.h> //Not OK, file not found.
int main(int argc, const char * argv[])
{
printf("Hello World!");
return 0;
}
In the tutorial is described how you have to link the library
You have two possibilities here:
As described you have to add those two lines to your code
#define LIBSSH_STATIC 1
#include <libssh/libssh.h>
You compile your code with the LIBSSH_STATIC flag.
gcc -DLIBSSH_STATIC test.c -o test.o
I thought that if you have the library in /usr/include the compiler will automatically link it. For instance, the pthread.h file is included properly without doing anything.
This is a system library which gets linked automatically most of the time. libssh is not. Thats why you have to be more specific on how to compile/link it.
Ive had a very similar problem several times and I have solved it by removing the ≤ ≥ symbols from around my header files and using ""s and the absolute path to the header file you're including. Now this doesn't solve your libssh install problems but it will allow you to compile just the way you have it as long as you know the absolute path of your header file and all of your header's dependencies are in the respective locations that they were inteded to look for them in. Hope this helps.
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
... ... ...
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.