Comments (9)
These resource files should be autogenerated by CMake in build directory, one possible issue could be missing or malfunctional corrade-rc
utility from Corrade. How exactly are you building it?
from magnum.
I'm performing an out of source build on corrade then pointing Magnum to Corrade's install directory
gcc -v gives the following
PS C:\Users\Denis\Development\corrade-master\build> gcc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.1/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../src/configure --enable-languages=c,c++ --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target
=x86_64-w64-mingw32 --disable-multilib --prefix=/c/temp/gcc/dest --with-sysroot=/c/temp/gcc/dest --disable-libstdcxx-pch
--disable-lto --disable-nls --disable-shared --disable-win32-registry --enable-checking=release --with-tune=core-avx-i
Thread model: win32
gcc version 4.8.1 (GCC)
I've tried an in-source and out of source build but same result.
Trying corrade-rc.exe --help gives nothing
from magnum.
It looks to me like an problem with PATH
-- do you have the dirs where all MinGW and Corrade's DLLs are installed (e.g. C:/MinGW/bin
and C:/MinGW/lib
) added to it? If you run corrade-rc
by just double-cliking on it and an error dialog about libCorradeUtility.dll
missing (or something similar) pops out, then it is exactly that problem.
What looks weird to me is that corrade-rc
doesn't return with error code, but behaves like everything is working correctly and thus compilation fails later on non-existent generated files.
Just to be sure, I tried building Magnum on Windows machine right now and didn't encounter any problem.
from magnum.
Thanks for the help. That seems to have fixed most issues however corrade-rc.exe is causing a stack crash now.
from magnum.
The following stack crash is what occurs when i try running it;
Problem signature:
Problem Event Name: APPCRASH
Application Name: corrade-rc.exe
Application Version: 0.0.0.0
Application Timestamp: 5232f307
Fault Module Name: StackHash_34a2
Fault Module Version: 6.1.7601.17725
Fault Module Timestamp: 4ec4aa8e
Exception Code: c0000374
Exception Offset: 00000000000c40f2
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 3081
Additional Information 1: 34a2
Additional Information 2: 34a2d6df0c419ea313861bb8da25538a
Additional Information 3: 68bc
Additional Information 4: 68bcb87929897add14261087cf821b30
from magnum.
As usual, the Windows crash output is plainly useless :-)
Again this might be an issue with conflicting DLLs (probably from another version of GCC or MinGW), check if there isn't another version of the same DLL installed somewhere else on the PATH
(e.g. mingwm32.dll
, libstdc++-6.dll
etc. from older MinGW installed in C:/Windows/system32
). Also check PATH
for suspicious directories which might contain conflicting DLLs.
Or this might be an issue with MinGW's GCC 4.8.1, on 4.7.2 everything works flawlessly. I had to remove support for std::u32string
from Windows builds becase some bug in MinGW caused memory corruption :-)
from magnum.
That seems to work (With TDM GCC 4.7.1 [included with Codeblocks 12.11]). Awesome. So at this point in time GCC 4.8.1 is extremely broken on windows. Just have to get the rest of the targets compiled.
FYI, At the moment the default install path of Corrade (C:\Program Files (x86)/Corrade) causes the magnum makefiles to die.
Really appreciate the help. Looking forward to digging in.
from magnum.
Yeah, paths with spaces :-) I'll look into that, thanks.
from magnum.
I came here from https://github.com/mosra/corrade/wiki/Windows-troubleshooting with the issue that MinGW 4.8.1 builds a corrade-rc.exe that crashes for no reason. I was building corrade with Nuwen MinGW, but I figured out through trial and error that if I built with a MinGW 32-bit 4.8.1 instead and then in my Nuwen MinGW created a fake corrade-rc.exe that calls the 32-bit one, it works! This was what I had to do:
- Build corrade as usual with nuwen MinGW
- disable corrade-rc.exe (just added a dash to the end of the filename)
- Switch to 32-bit MinGW and build corrade there
- Switch back to nuwen MinGW and make a forwarding program in corrade-rc.exe's place that calls the 32-bit one in its place
I failed to make the forwarder program work for some reason so instead I just had it print the command line to a file and I called the 32-bit corrade-rc manually each time cmake failed (the most hacky way possible) and then re-ran make so it continued where it left off but with the file it was previously missing.
After all that effort I managed to get it to compile and install successfully! Hopefully the Nuwen MinGW 4.8.1 crash can be solved to make people's lives easier. Maybe it's a 64-bit portability issue as nuwen MinGW is 64-bit native.
EDIT: In the end I just decided to use 32-bit MinGW 4.8.1, as using 64-bit with nuwen renders most of the library crashtastic. I'm having success with 32-bit 4.8.1
from magnum.
Related Issues (20)
- 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
- Apply MAGNUM_BUILD_STATIC_UNIQUE_GLOBALS for the flextGL globals as well HOT 4
- EmscriptenApplication keyboard handler doesn't send key event corresponding to text input events HOT 2
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.