Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I have a very old C++ project using OpenGl and now I want to recompile then upgrade it. But I lost my old OpenGL SDK and so far it hasn't been found yet. I think "glu.h" is outdated and it seems like doesn't appear in newer versions of OpenGL, and I've tried many times but no luck. Could anyone tell me where to get the old package of OpenGL that contains glu.h, in order to help me compile & upgrade my old project properly?
GLU is not part of OpenGL and never got updated beyond the old version that's shipped with practically all Windows compiler suites.
But I lost my old OpenGL SDK
How can you loose that if there's no such thing? Like I already wrote practically every compiler suite for Windows ships with OpenGL headers and libraries for OpenGL-1.1 (that's what the Windows opengl32.dll ABI natively supports) and GLU.
For anything beyond OpenGL-1.1 you must use the extension mechanism to post-load further functions.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am trying to build jpeg_gpu, and the current Visual Studio error is "Cannot open 'GL/glcorearb.h' ".
I can find the file 'glcorearb.h' online at khronos.org, but I'm not entirely sure if I am supposed to just fetch this one file, or if it's supposed to be installed as part of some other library. It doesn't seem to come as part of GLFW or GLEW.
What is the most sensible way to obtain glcorearb.h? On its own, or as part of a larger library?
If it should be downloaded on its own, where is the most sensible place for it to live on a Windows machine for Visual Studio to find?
Khronos is the official group for OpenGL matters. They publish the headers.
People at GLFW, GLEW, VS, or whatever, download the headers and incorporate in their code. Sometimes they do some small changes, mainly for 32/64 bit types or compiler adjustments.
If you compare glext.h and glcorearb.h you will see that the later doesn't include any stuff for OGL before 3.2, while the glext.h contains all. So, general libs (like GLEW) will provide and use glext.h instead of glcorearb.h.
If your code requires glcorearb.h then just fetch it from Khronos and put it in the same folder where glext.h is.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I'm working on a paper for school and I was wondering which compilers are supported by which operating systems.
I know Mac supports C and C++ (I know they're not that different but to me they are 2 different languages)
I was wondering which compilers/languages are supported by windows, which by Ubuntu and which by Mac.
Sorry for asking a straight question but i think there's people who know this straight away.
thanks
"Support" is a relative term here. At one extreme, I think if you have a computer with just about any version of Linux installed (Ubuntu is just one variety), if that version of the O/S isn't too stripped-down you will already have a compiler for C and C++ . If you just installed Windows, however (or got a new Windows computer from the factory), you almost certainly have no C or C++ compiler there and must obtain and install one. (There are various choices.) So Windows does not "support" C and C++ as well as Linux does, in that sense.
At the other extreme, just about any compilable language can be compiled on any of those three platforms ... if you are willing and able to write your own compiler.
In between those two extremes, you would have to ask whether someone anywhere has already written a compiler for that language on that platform, and whether you can obtain a copy of that compiler. Most of these are "third-party" software packages, so knowing which ones exist is partly a function of how well the compilers have been advertised. Even the Wikipedia page on this topic says its list may be incomplete. On the other hand, it's likely you have never heard of most of the languages that are listed there.
Wikipedia has a list of compilers and OS support here: https://en.wikipedia.org/wiki/List_of_compilers
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
Willing to harness Tango library along with the very last release of DMD 1 compiler (v1.076), I searched the net in vain for the bundle.
How that can that be built?
Solved:
I've managed to build a DMD 1 v1.076 with Tango. See here my answer.
Why do you need a bundle, specifically?
Here is the official bundle download:
http://dsource.org/projects/tango/wiki/TopicInstallTangoDmd
You could also download a newer compiler separately, but Tango may not work with the latest compiler out-of-the-box - you may need to update the code in a few places to get it to build.
Tango is no longer maintained by its creators, which is why the downloads haven't been updated in a while. Some volunteers may be maintaining forks of Tango which work with the latest D versions. For example, here is a D2 fork: https://github.com/SiegeLord/Tango-D2
To share my findings:
I finally end up building with success a DMD 1.076 with Tango as Library (Win32) Bundle.
I followed the detailed steps mentioned in the Tango's website regarding Win32 platform.
It works with DMD 1.071 version onward.
I had to fix one issue by just changing a private extern (Windows) line of code to protected extern (Windows) in one module.
I noticed that the Tango Library has undergone some changes since bundle I used before (DMD1.056/Tango 0.99.9).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
May be I'm missing something (Surely I do) but I don't understand a thing :
Each brand new version of Visual Studio is shipped with a particular msvcrtxx (msvcr100.dll, msvrct.dll, ...)
Right.
Except the fact it leads, often, to the famous "dll hell", I still don't understand why the "Windows Driver Kit" continues to produce binaries linked against the old MSVCRT.DLL !?
Windows always ships with an old, barebones version of MSVCRT, specifically so that drivers can have some basic runtime support without having to ship their own copies of the library. It's appropriate for drivers but no for higher level user-mode applications.
Each version of VS C++ ships with newer versions of the runtime libraries because the library standards (and support for the standards) is evolving. Sometimes these evolve in a way that's not backward compatible, so you can't guarantee that an older program, compiled against an older version of the DLL will work with a newer version of the DLL. By making the files explicitly versioned, much of the so-called DLL Hell problem is avoided. (DLL Hell is really only a problem if you make bad assumptions and design bad installers, especially nowadays with side-by-side versioning, merge modules, etc.)
Apps have to redistribute copies of whichever version they require, as there is no guarantee that the libraries they depend upon will exist on the computer.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm toying with the idea of building a Cocoa app that uses OpenCV. I could take the easy route and just use MacPorts or some such tool to get OpenCV quickly. Unfortunately, sooner or later, I'd still have to tackle the issue of deployment so I decided to get that out of the way immediately.
My Question is:
What is the best strategy for deploying apps that rely upon libraries that do not ship with OS X?? Especially with regard to guaranteeing backward compatibility to OS X 10.5 or even 10.4?
The way I see it these are the options:
I could compile OpenCV from source as dynamic libraries and install
them on the customer's computer using an installer.
I could compile OpenCV statically and embed the static libraries in
the application bundle.
Then there is the option of creating a Private Framework but nobody seems to
have a clue about how to do that.
I'm leaning towards option 2 since I like the idea of distributing the app in a *.dmg image since that reduces installation to simply draging-and-dropping the app bundle to the 'Applications' folder.
I think Option 2 is Apple's recommended choice.