GtkGlArea is listed in the Widget Gallery of Gtk+3.0. There is official documentation for it, which states that I only have to include gtk/gtk.h to use the desired widget.
But I can't find any OpenGl mentions among header files of gtk+-3.0 package. And of course, I can't call any of the gtk_gl_area_* functions without stumbling upon undefined reference error.
Is GtkGlArea not available in Gtk+ 3.0? If so, why is it showcased on the official website?
If it is available, how can I use it in my C project?
GtkGLArea was added in GTK+ 3.16. If you look at the documentation page for GtkGLArea, you will see
Since: 3.16
under gtk_gl_area_new().
If you are running GTK+ 3.14 or lower, you do not have access to GtkGLArea. Your distribution can tell you which version you have installed. If your distribution does offer a newer version, then you will need to install it. (The current version as of this writing is GTK+ 3.18.)
If you don't have GTK+ 3.16 or newer, and need to stay with the version of your distribution that you use, you have a few options:
find someone else's OpenGL widget; here's one and here's another
use jhbuild to install a local version of a newer GTK+ version and use that to develop
use a virtual machine with a newer distro to develop
EDIT: You can also see documentation for the specific version of GTK+ you need to target by choosing a version from this list. (The same applies to the other documentation sets on developer.gnome.org.) If backward compatibility is your thing, you should also look into the GDK_VERSION_MIN_REQUIRED and GDK_VERSION_MAX_ALLOWED macros.
Related
Is there a way to list all the installed libraries and/or query if a specific library is installed with gcc? I want to know if glut is available on my system (without browsing all the library path).
I am using mingw w/ gcc 4.5.2 under windows.
The way to check will generally be platform and compiler dependent. Getting it 100% right is hard.
You can use a build system like CMake for generating your actual build system (confused yet ;-)?)
I found a small tutorial which explains how to find glut for you. Essentially, all you need is
find_package(GLUT)
in your CMakeLists.txt. To get to know cmake, I suggest you read/follow their tutorial
I believe your best bet is to try to compile and link a simple example.
Gcc will complain about any libraries it can't find.
You may also try to use a smart IDE (CDT) and try to auto-complete your #include statement. That may as well list all your installed libs.
Is it possible to build classic Windows executables (Windows 8 support is not required) from C source code using the latest Xcode/clang compilers on a current Mac (e.g. without using gcc or a VM to run Linux or Windows)?
After thinking why the hell would you want to do this?, I just surprised myself and found what may actually be a solution!
The Cocotron
The Cocotron is an open source project which aims to implement a cross-platform Objective-C API similar to that described by Apple Inc.'s Cocoa documentation. This includes the AppKit, Foundation, Objective-C runtime and support APIs such as CoreGraphics and CoreFoundation.
Also see this blog post: Win-win with Cocotron and Xcode 4.3 — code for Mac, build for Windows (Part 1)
Although the last entry on the Cocotron site was from 2010 - so it may or may not still be alive
Starting with Xcode 4.5 the possibility of building for armv6 devices is not given anymore (iPhone/iPod touch 1st and 2nd generation). This means no new versions of our app for iPhone 2G and 3G which is very unlucky. Does anyone know if there will be a workaround? I really don´t see any technical reasons for this.
You can have multiple versions of xcode installed. In the past, that has been the fix needing to use an older xcode feature.
It is a workaround, and the project files may eventually evolve in a way that no longer supports the older tools, but for the time being, that will allow you to build for older targets.
If you have a single project that you want to work with in both versions of XCode, then you may end up having to manage separate project control files via source control tricks and/or file shuffling.
I would also recommend that project structure changes and binary file management (e.g. Core Data models) happen via the old version, as XCode 4.5 will be backward compatible, but forward compat is rarely assured.
There's another solution I found in chpwn blog: Building for armv6 in Xcode 4.5.
This allows you to work with Xcode 4.5 but compile using 5.1 SDK.
The downside: you can’t use the iOS 6 SDK when using this trick, and you can’t build for armv7s.
Yes, there are workarounds. If you need to actually take advantage of new iOS 6 features, try either of the first couple answers to this related question. The first answer requires using both Xcode 4.4 and 4.5. If you never want to have to open Xcode 4.4, then use the second answer.
If you just want to be able to build an executable in Xcode 4.5 that works on armv6, armv7 and armv7s devices, without actually taking advantage of new iOS 6 SDK APIs, then you can see my answer to another question, which is much simpler ... but has the limitation that you can't take advantage of new iOS 6 features on iOS 6 devices.
You can add the string "armv6 armv7" as architecture. Do not select a predefined setting.
Compiler is mingw32. Language is C99. OS is windows. Graphics card is Nvidia 260GTX
I can link against opengl32/glu32 and build against it, but nothing from OpenGL 3.x is included... in fact, I would say its probably missing 2.x extensions!
GLEW and GLM are both C++ and doesn't work with straight C. Glee doesn't have any mingw32 binaries (and doesn't build cleanly on my system).
I'm using SDL and that has some OpenGL functions (??), but again, looks way outdated.
I just I don't understand the fundamental problem on why it's so difficult to get C/OpenGL working on windows? Why is is so unique? Why doesn't the Khronos provide an SDK/libraries/headers, etc?
I do OpenGL via Java/lwjgl and takes no time to set it up and get it compiling/running.
In Windows anything above OpenGL-1.1 is only accessible through extensions. This is how it has been designed and how it goes. GLEW works perfectly well with plain C (if I'm not mistaken GLEW is written in plain C).
Khronos cannot provide a SDK because actually providing the OpenGL API is a task left to the operating system vendor and in Windows the graphics drivers are required to provide the implementation. In the case of Windows this is Microsoft, who left the ARB some years ago, in favour of their proprietary Direct3D technology; there used to be heated debates which was the better API, but now that the whole world, except Microsoft settled on OpenGL this time of arguing is over.
Anyway, if you want things to be really easy, instead of GLUT, SDL, etc. use GLFW http://glfw.org, a really excellent OpenGL framework, that does all the hard things for you, does extension loading and OpenGL-3 context setup if you ask it so (you still need some extension wrapper to use extensions in your own code – however creating a pure OpenGL-3 context requires some proxy context, loading a few extensions using that and use the functions obtained to create a real OpenGL-3 context. Just for clarification).
I'm trying to disassemble a C/C++ DLL, and have made some progress, but I would like to create my own C DLL with the same function the original exports, and compare disassemblies.
Visual Studio adds to much crap, and when I remove the crap and build my project, the expected DLL is missing.
I need a lightweight, preferably IDE, tool to edit and build very simple C libraries.
Take a look at Code::Blocks
I need a lightweight, preferably IDE, tool to edit and build very simple C libraries.
I have found that one of the best ways to do integrated C-only Win32 development is using the freely available Lcc Win32 Compiler which comes with a built-in IDE, including resource editor.
In fact, it is really very lightweight and can be run from a USB stick with some manual tweaking.
It's indeed a really small download of just 6 mb and you can even download an optional Win32 API help file which is really useful while doing development.
The compiler also comes with a C tutorial, as well as good user documentation detailing how to use the integrated Win32 resource editor "wedit", there's also an advanced manual about more complex development tasks.
Dev-C++ is a nice and fast IDE which works well with MingW.
But it's all been asked and answered before ...
MinGW adds its own crap. Install your VC express properly and save yourself a lifetime of trouble.
Btw, you don't need to use Visual Studio for its compiler or vice versa. The oddity of missing a build dll is probably because you are not looking at the right path.
If you are building C DLLs you really would benefit from its command line toolset and utilities, sdks, easy config etc. MS lock-in proprietary extensions are widely used (in context of you trying to emulate another dll), and last thing you need is chasing cross compiler issues..
GCC + any text editor such as VIM is a very light alternative.
For Windows Development, all you need is inside MinGW
Edit: If you are in dire need of an IDE you can also use the MinGW tools from Eclipse with the CDT plugin. Although it adds weight to the solution because of the installation of Eclipse, this is what I really use to build my small DLLs (JNI wrappers in my case).
You can setup your small and direct makefiles or let Eclipse do it automatically for you and concentrate only on the source files (*.h, *.c).
The best part of using this approach instead other IDE is that you do not need Eclipse to further build the DLL, since the underlying project files generated are standard ones directly usable by integrated dev inside MinGW (or any Unix distro) such as make, configure, automake, and so on.
I'll second the vote for Code::Blocks, it's what I use (despite having VS 2008 installed as well). It is very simple and lightweight but has basically all the features you'd expect out of an IDE. It comes with several predefined project templates for all kinds of C and C++ development, including templates for DLLs.
Download the version that includes MinGW and you get a complete lightweight IDE ready to start compiling. You can also easily configure it to use the Visual Studio compiler instead of gcc if you prefer.
try Open Watcom. A cross-platform product, well-supported by the community, lets you develop in DOS, Windows, OS/2 etc for a lot of platforms. Version 1.8 was released recently. Has a light-weight IDE indeed