Comments (12)
Thank you very much for the detailed report. I actually don't have access to any machine with OS X, so I might not able to trace or fix the exact issue.
- You are right, the OpenAL finding routine is part of CMake itself. However it seems that the OpenAL library you found is somehow part of XCode, which explains the horrifically long include path. The official
FindOpenAL.cmake
tries to find it in/Library/Frameworks
, thus I assume there must be some standalone version of OpenAL which is not bundled with XCode. - With SDL, isn't it possible that you have SDL 1.2 installed too? It would explain the missing header (
SDL_scancode.h
is available only in SDL2, in SDL 1.2 it was namedSDL_keysym.h
) -- it seems that CMake mistakenly found the SDL 1.2 include dir, although it did found SDL2 library properly. Sadly CMake doesn't yet provide a well-tested finding routine for SDL2 in default installation, so I must ship my own (buggy) version with Magnum. Weirdly enough, the finding routine inmodules/FindSDL2.cmake
seems to be already checking forSDL_scancode.h
presence, thus it should in theory work flawlessly.
from magnum.
There's a version of OpenAL that comes with Mac OS X in /System/Library/Frameworks
(none in /Library/Frameworks
, for me at least), however it doesn't include the headers. The only way to get the one with the headers as far as I can tell is to use the one in the SDK, and I guess these are located inside Xcode.app, for some reason.
And yes, I do have SDL 1.2 installed, and that's probably what it was trying to use. I just did some investigating and it seems that unless I manually override SDL2_INCLUDE_DIR
, it settles on /Library/Frameworks/SDL.framework/Headers
, which is the SDL 1.2 header directory (it should be /Library/Frameworks/SDL2.framework/Headers
). It does find SDL2_LIBRARY
correctly, as /Library/Frameworks/SDL2.framework
, so maybe something involving just the include path? Not sure if that helps you, but at least its clear what's happening.
from magnum.
I have built the library to attempt to reproduce your issue, there were no issues on my end
I am using osx 10.9
cmake version 2.8.10.2 "darwin ports version"
clang 5.0 5000.2.79 llvm 3.3. svn
I installed the SDL2 framework to /Library/Frameworks/
I am going try installing SDL1.2 and see the result.
from magnum.
-- The C compiler identification is Clang 5.0.0
-- The CXX compiler identification is Clang 5.0.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found Corrade: /usr/lib/libCorradeUtility.dylib
-- Found OpenGL: /System/Library/Frameworks/OpenGL.framework
-- LIB_SUFFIX variable is not defined. It will be autodetected now.
-- You can set it manually with -DLIB_SUFFIX= (64 for example)
-- LIB_SUFFIX autodetected as '', libraries will be installed into /Developer/libs/lib
-- Could NOT find SDL2 (missing: SDL2_LIBRARY)
CMake Error at src/Platform/CMakeLists.txt:61 (message):
SDL2 library, required by Sdl2Application, was not found. Set
WITH_SDL2APPLICATION to OFF to skip building it.
This is when I removed SDL2 from framework/Headers.
That does not appear to be the case it does not try and settle SDL.framework/Headers what version of cmake are you running?
EDIT:
It appears that I was wrong. I was trying to rebuild from scratch and ran into this issue.
When SDL.framework and SDL2.framework libraries included in frameworks it causes a build problem.
This build problem causes inconsistent errors to arise.
The resolution is to use SDL2 and remove SDL.framework from /Library/Frameworks.
To solve the build problem, now for the actual cmake script I perhaps we can issue a warning since we are not supporting SDL anyways? thoughts?
To reproduce.
Download SDL.framework and SDL2.framework install in /Library/Frameworks
using the usr prefix as the installation directory.
Build Install Corrade
Generate cmake files,
run make on Magnum
at around 40 Magnum will not build correctly
Scanning dependencies of target MagnumGLLoadGenObjects
[ 1%] Building C object external/OpenGL/GL/CMakeFiles/MagnumGLLoadGenObjects.dir/gl_magnum.c.o
[ 1%] Built target MagnumGLLoadGenObjects
Scanning dependencies of target MagnumObjects
[ 2%] Building CXX object src/CMakeFiles/MagnumObjects.dir/AbstractFramebuffer.cpp.o
[ 3%] Building CXX object src/CMakeFiles/MagnumObjects.dir/AbstractImage.cpp.o
[ 4%] Building CXX object src/CMakeFiles/MagnumObjects.dir/AbstractObject.cpp.o
[ 5%] Building CXX object src/CMakeFiles/MagnumObjects.dir/AbstractTexture.cpp.o
[ 6%] Building CXX object src/CMakeFiles/MagnumObjects.dir/AbstractShaderProgram.cpp.o
[ 6%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Buffer.cpp.o
[ 7%] Building CXX object src/CMakeFiles/MagnumObjects.dir/ColorFormat.cpp.o
[ 8%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Context.cpp.o
[ 9%] Building CXX object src/CMakeFiles/MagnumObjects.dir/DebugMessage.cpp.o
[ 10%] Building CXX object src/CMakeFiles/MagnumObjects.dir/DefaultFramebuffer.cpp.o
[ 11%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Framebuffer.cpp.o
[ 12%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Image.cpp.o
[ 13%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Mesh.cpp.o
[ 14%] Building CXX object src/CMakeFiles/MagnumObjects.dir/MeshView.cpp.o
[ 15%] Building CXX object src/CMakeFiles/MagnumObjects.dir/OpenGL.cpp.o
[ 16%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Query.cpp.o
[ 17%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Renderbuffer.cpp.o
[ 18%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Renderer.cpp.o
[ 18%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Resource.cpp.o
[ 19%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Sampler.cpp.o
[ 20%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Shader.cpp.o
[ 21%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Timeline.cpp.o
[ 22%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Implementation/BufferState.cpp.o
[ 23%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Implementation/DebugState.cpp.o
[ 24%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Implementation/State.cpp.o
[ 25%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Implementation/TextureState.cpp.o
[ 26%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/AbstractImageConverter.cpp.o
[ 27%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/AbstractImporter.cpp.o
[ 28%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/AbstractMaterialData.cpp.o
[ 29%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/MeshData2D.cpp.o
[ 30%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/MeshData3D.cpp.o
[ 31%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/MeshObjectData2D.cpp.o
[ 31%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/MeshObjectData3D.cpp.o
[ 32%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/ObjectData2D.cpp.o
[ 33%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/ObjectData3D.cpp.o
[ 34%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/PhongMaterialData.cpp.o
[ 35%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/SceneData.cpp.o
[ 36%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/TextureData.cpp.o
[ 37%] Building CXX object src/CMakeFiles/MagnumObjects.dir/BufferTexture.cpp.o
[ 38%] Building CXX object src/CMakeFiles/MagnumObjects.dir/BufferImage.cpp.o
[ 38%] Built target MagnumObjects
Scanning dependencies of target MagnumMathObjects
[ 39%] Building CXX object src/CMakeFiles/MagnumMathObjects.dir/Math/Functions.cpp.o
[ 40%] Building CXX object src/CMakeFiles/MagnumMathObjects.dir/Math/instantiation.cpp.o
[ 40%] Built target MagnumMathObjects
Scanning dependencies of target Magnum
Linking CXX shared library libMagnum.dylib
[ 40%] Built target Magnum
Scanning dependencies of target MagnumSdl2Application
[ 41%] Building CXX object src/Platform/CMakeFiles/MagnumSdl2Application.dir/Sdl2Application.cpp.o
In file included from /Users/michaelchung/CodeWorkSpaces/XCodeWorkSpace/Projects/magnum/src/Platform/Sdl2Application.cpp:25:
/Users/michaelchung/CodeWorkSpaces/XCodeWorkSpace/Projects/magnum/src/Platform/Sdl2Application.h:41:10: fatal error: 'SDL_scancode.h' file not found
#include <SDL_scancode.h>
^
1 error generated.
make[2]: *** [src/Platform/CMakeFiles/MagnumSdl2Application.dir/Sdl2Application.cpp.o] Error 1
make[1]: *** [src/Platform/CMakeFiles/MagnumSdl2Application.dir/all] Error 2
Remove SDL.framework builds just fine.
from magnum.
Fails in the same way for me. Requiring that SDL1.x not be installed on mac isn't a very good solution, if you ask me. Why isn't a qualified path to the SDL2 headers used, e.g. <SDL2/SDL_scancode.h>
?
from magnum.
Good point let me try that out.
from magnum.
Hmm okay so I was looking at the code, I think the library developer did not consider the fact there would be library conflicts since it would be assumed that a developer would be using 2.0 SDL as stated on the main page. I am not sure why SDL 1.2 would be used is there a specific reason? but yeah the cmake script should be fixed to allow provide the direct path to the SDL 2.0 library in case of an issue where two libraries exist.
from magnum.
I don't have much of a reason for keeping SDL1.x around other than that I have some old projects that depend on it that I'm fond of, but other users might have a more compelling reason to do so. I'd be surprised if there weren't people working on projects that used SDL1, because upgrading to SDL2 is not seamless. Not to mention any of the other reasons people might be required to use outdated libraries (School, work, etc).
Anyway, as I see it, the problem is that the build system fails to detect a configuration error on mac if SDL1.x and SDL2 are both installed. I think the easiest and best solution to this is to modify the build system to allow #include <SDL2/SDL_blah.h>
to work on all platforms, and then use that everywhere. I guess you could also detect that SDL1.x is installed an issue an error, but that's pretty weak IMO.
This is assuming there isn't a reason that the fully qualified paths weren't used in the first place, maybe there are other platforms that prevent it (in which case the code will likely need lots of ifdef __APPLE__
and the config files will need to only change the path on mac, which is obviously the worst solution). But my guess is that it was a stylistic choice (path names in include files don't seem to be common in this library).
from magnum.
Related.
from magnum.
I think the easiest and best solution to this is to modify the build system to allow
#include <SDL2/SDL_blah.h>
to work on all platforms, and then use that everywhere.
[...]
This is assuming there isn't a reason that the fully qualified paths weren't used in the first place, maybe there are other platforms that prevent it.
This was exactly the reason for using #include <SDL_blah.h>
instead of #include <SDL2/SDL_blah.h>
. In SDL 1.x times some platforms had <SDL/SDL_blah.h>
, some <SDL12/SDL_blah.h>
, some <SDL-1.2/SDL_blah.h>
etc., so detecting the directory in CMake, adding it to include path and then including only <SDL_blah.h>
was the least annoying solution. Thus for me this seemed to be some kind of future-proof solution also for SDL2.
Anyway, the real problem is that the FindSDL2.cmake
module isn't able to disambiguate between SDL1 and SDL2. I have an idea for a fix, but can't test it. Could you change the following line https://github.com/mosra/magnum/blob/master/modules/FindSDL2.cmake#L46 to list only SDL_scancode.h
(i.e. remove SDL.h
) and try clean build again? This should force CMake to find the right path and not mistake it with SDL1 one.
from magnum.
It passed the simple tests.
from magnum.
Solved with the mentioned fix in pull request #38.
from magnum.
Related Issues (20)
- Update vcpkg packages to include EmscriptenApplication on Emscripten HOT 2
- Failing to link Magnum::Math? HOT 3
- few compile warnings HOT 1
- How to point to a local installation of `corrade` without using the bootstrap project? HOT 3
- undefined symbol: flextGLInit HOT 4
- Image rendered in gray since 1847c72 HOT 18
- Emscripten 3.1.21+ crashes EmscriptenApplication: "AsciiToString is not defined" HOT 4
- How to build from source on MSYS2 MINGW64? HOT 1
- keyReleaseEvent not triggered after printscreen on OSX HOT 6
- Conversion from CubicHermite to Bezier is wrong
- Mixing with raw openGL calls and Context::current().resetState() HOT 3
- C Bindings HOT 5
- WebGPU backend HOT 2
- Parallel rendering with glb files HOT 5
- Conflict with near and far Macros When Including WinSock2.h After Matrix4.h HOT 2
- emsdk compile error: typedef redefinition with different types HOT 4
- Memory leak when destroying GL::Mesh HOT 3
- Linking in Emscripten >= 3.1.52 doesn't work HOT 4
- Some trouble with LineGL3D shader when camera is close HOT 1
- Segmentation fault with nullptr instruction in AbstractShaderProgram at Cross-Compile HOT 21
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from magnum.