I'm trying to recompile an older unix OpenGL program on the mac. I came to the moment when most of dependencies are fulfilled. However, now I'm stuck on mUI extension of GLUT. I checked on my linux machine and there is a whole directory lib/mui with sources and include/mui with headers in glut-3.7. After compiling on linux I ended up with library files libglut.so.3.7 and libmui.a. The later one I linked to my program. I have found no trace of mui in GLUT.framework (OSX 10.9, Xcode 6.2; gcc/gfortran 5.0). Has anybody idea how to deal with this problem. I'm a bit afraid to compile glut myself, as I have no idea what will happen to my build if two different GLUTs exist. Should I just compile glut3.7 and statically link my code to this library?
In the end I have compiled the libmui.a file using sources from glut-3.7.
I adapted the make file for linux. The main change was replacing OpenGL and Glut libraries to frameworks:
LIBRARIES = -framework glui -framework glut -framework OpenGL -lXmu -lXext -lX11 -lm
In *.C files I have replaced call to GLUT with:
#ifdef __APPLE__
#include <GLUT/glut.h>
#elif
#include <GL/glut.h>
#endif
That was. I linked the libmui.a to my elderly application and it worked without any trouble.
Related
I am new to MacOS, I've always written code on Linux. I was used to compiling C files with gcc, simply like
gcc -o file file.c -lm -lgsl
where here I assumed the code to contain among its includes
#include <math.h>
#include <gsl/gsl_rng.h>
Of course the library gsl is correctly installed on my Mac via homebrew, and so are pkg-config and "Command line tools", but still when I try to compile file.c I get an error message,
fatal error: 'gsl/gsl_rng.h' file not found
#include <gsl/gsl_rng.h>
^~~~~~~~~~~~~~~
The problem is not specific to gsl (I tried for instance with the library fftw3 and got the same result).
I've seen tons of people with the same kind of problems on new M1 Macs; I've read that gcc on Mac is really "clang", and different rules apply. A ton of mocking answers were suggesting to add the correct library paths to the makefile or the like. But actually I've never before felt the need for a makefile on Linux, and surely I don't want to start adding cflags and paths whenever I compile a code (I'm working on several machines with different operating systems, with my code stored on Cloud servers, so I assume I should write a makefile for each of them? Really?).
Has anyone found a proper fix?
I'm trying to do a cmake project with opengl and qt.
this is the cmake where I include opengl:
# opengl
set(QT_USE_QTOPENGL TRUE)
find_package(OpenGL REQUIRED)
find_package(GLUT REQUIRED)
include_directories( ${OPENGL_INCLUDE_DIRS} ${GLUT_INCLUDE_DIRS} )
set(OPENGL_LIBS ${OPENGL_LIBRARIES} ${GLUT_LIBRARY})
And it found them, this is a part of cmake output:
-- Found OpenGL: /System/Library/Frameworks/OpenGL.framework
-- Found GLUT: -framework GLUT
And I can include OpenGL with this:
#include <QtOpenGL>
with this it finds correctly gl* glGetString(GL_VENDOR) or glGetString(GL_VERSION) and they works.
BUT I'm not able to include GLUT includes.
I'm on Mac OSX 10.8.4, Qt 4.8, QtCreator 2.7.1 and Opengl 2.1
Please note that the same cmake file under Ubuntu 12.04 let me include GL/gl.h and GL/glut.h correctly.
BUT I'm not able to include GLUT includes.
Why would you want to use GLUT when you're already using Qt?
GLUT is a framework for window creation and event loop processing.
Qt is a framework for window creation and event loop processing.
You can't (well, should not) have two framework within the same program doing the exact same thing (unless you're interested in seeing them fighting some battle over the same resources).
On OSX you need to include GLUT/glut.h, so write something like that in your code:
#ifdef __APPLE__
#include <GLUT/glut.h>
#else
#include <GL/glut.h>
#endif
OS X 10.6.8, XCode 3.2.6, Base SDK 10.5, Intel Compiler 11.1
I am getting a weird message when I try to compile that says:
catastrophic error: could not open source file "stdarg.h"
I am using a PCH, I did find: Xcode Intel compiler icc cannot find #include <algorithm>
which is a similar issue and I think that the source file type is set to .c.c instead of .c
From what I can see stdarg.h is:
/* This file is public domain. */
/* GCC uses its own copy of this header */
#if defined(__GNUC__)
#include_next <stdarg.h>
#elif defined(__MWERKS__)
#include "mw_stdarg.h"
#else
#error "This header only supports __MWERKS__."
#endif
so must be GNUC is defined, obviously.
Can anyone help me figure out how to better compile since this works without changes in GCC 4.0? Is there a global way one might have XCode re-evaluate the source file type to not be .c.c or .cpp.cpp I am not even sure how this would happen.
Also, is there a #define that I can check to see if the Intel compilers are being used to make special cases if I need to?
I looked at a few of the files referenced in the build results and looking at the source file type in XCode it says source.c.c and I think if I change that to source.c that compiler error goes away.
I'm trying to compile an application that utilizes cstdint. Since Apple deprecated the gcc, I wanted to try compiling it with clang, but i get the error:
fatal error: 'cstdint' file not found
I know that the gcc 4.6.2 version has the option for -std=c++0x, to include the library, but since the os x version is 4.2 that's not much of an option here. Any suggestions on how I can move forward? I have tried to install 4.6.2, but ran into a variety of issues when compiling some of the needed libraries before building gcc.
Presumably, you have the source code to this application, so you can modify the headers to include the correct cstdint header, as Clang 3.0 (which Lion's tools come with) does have the header.
Quick Solution
The header is under the tr1 directory, so you will want to do either of these includes:
#include <tr1/cstdint>
Or
#include <stdint.h> // which will use the C99 header
Longer, boring explanation
After doing some additional reading since I remember you can do this without the tr1 directory:
By default, you are going to be including C++ headers from /usr/include/c++/4.2.1, which are the GNU GCC headers. /usr/include/c++/4.2.1/tr1 includes the TR1 header files, like cstdint.
The alternative method is to compile using the Clang++ frontend and passing the -stdlib=libc++ flag, which will use the headers from /usr/include/c++/v1, which are Clang's C++ header implementations. It has cstdint.
Example:
// file called example.cxx
#include <tr1/cstdint>
int main() {
// whatever...
}
Compile this with:
g++ example.cxx
or
clang++ example.cxx
And it will do what you want.
If you don't want to use the tr1 version (which is roughly the same, if not exactly):
// file called example.cxx
#include <cstdint>
int main() {
// stuff
}
This is compiled like this:
clang++ -stdlib=libc++ example.cxx
Though if you use -stdlib=libc++, it means you're linking to Clang's C++ library libc++, rather than GCC's libstdc++.
I have been trying to produce a statically linked "single binary" version of my game for windows. I want to link with sdl, sdl_image and sdl_mixer which in turn pull in a few support libraries. Unfortunately I haven't found a way to get them all to compile and link using cygwin/mingw/gcc. As far as I can tell all existing public versions are only shared libraries / dlls.
Please note that I'm not talking about licencing here. The source will be open thus the GPL/LGPLness of sdl is not relevant.
When compiling your project, you need to make just a couple changes to your makefile.
Instead of sdl-config --libs, use sdl-config --static-libs
Surround the use of the above-mentioned sdl-config --static-libs with -Wl,-Bstatic and -Wl,-Bdynamic. This tells GCC to force static linking, but only for the libraries specified between them.
If your makefile currently looks like:
SDLLIBS=`sdl-config --libs`
Change it to:
SDLLIBS=-Wl,-Bstatic `sdl-config --static-libs` -Wl,-Bdynamic
These are actually the same things you should do on Unix-like systems, but it usually doesn't cause as many errors on Unix-likes if you use the simpler -static flag to GCC, like it does on Windows.
Via this SDL mailing list post it seems that the sdl development tools ship with a sdl-config script that you can use with the --static-libs flag to determine what linker flags you need to use.
Environment: VMWare Virtual Machine with Windows 7 x64 and Equipment we Dev c + + build 7.4.2.569, complilador g+ + (tdm-1) 4.6.1
Once, SDL2-2.0.3 API installed as configuration Dev c ++ is not very clear what I've done as tradition requires command line.
The first problem is that Windows 7 appears to have changed the methodology and they go to his ball. Inventory. Ref. https://stackoverflow.com/users/464581/cheers-and-hth-alf
After the first hurdle, SDL_platform.h is that bad, it's down another, I do not remember where I downloaded, but the next does not work in the indicated version.
We must put SDL2.h ls in the directory of the executable.
D:\prg_desa\zsdl2>g++ bar.cpp main.cpp -o pepe1 -ID:\SDL2-2.0.3\i686-w64-mingw32\include\SDL2 -LD:\SDL2-2.0.3\i686-w64-mingw32\lib -lmingw32 -lSDL2main -lSDL2 -mwindow
I've finally compiled and works SDL2 testing.
That's because the SDL libs are under the LGPL-license.
If you want to static link the libs (you can do that if your recompile them. It needs some hacking into the makefiles though) you have to place your game under some compatible open source license as well.
The SDL-libs come as shared libraries because most programs that use them are closed source. The binary distribution comes in a form that most people need.
On my system (Ubuntu) I have to use the following flags:
-Wl,Bstatic -lSDL_image `sdl-config --libs` -lpng12 -lz -ltiff -ljpeg -lasound -laudio -lesd -Wl,-Bdynamic `directfb-config --libs` -lpulse-simple -lcaca -laa -ldl
That links SDL, SDL_image, and many of their dependencies as static. libdl you never want static, so making a fully-static binary that uses SDL_image is a poor idea. pulse,caca,aa, and directfb can probably be made static. I haven't got far enough to figure them out yet.