Fix pointer issues and build with mingw64 #26
Conversation
…m module file Our custom module file is still useful. My linux distro does not package the cmake files.
…lable on anything else
…qually-sized integer
|
Looks good! As far as I see it should be possible to apply many of the changes to |
|
I'll look into it. Looks like this repo has no common history with the isle repo. |
|
Yeah, maybe it would make more sense. I wasn't sure if it would be "the right" thing to do since no changes are meant to be merged back into "upstream" from here, and not all commits are meant to be synced into What I've been doing so far is use |
|
@madebr updated master. There was one minor compilation error with regards to the app data type in the MinGW build, but we can fix it here |
| # FIXME: this is wrong. | ||
| if(CMAKE_SIZEOF_VOID_P EQUAL 4) | ||
| set(def "${CMAKE_CURRENT_SOURCE_DIR}/d3dxof32.def") | ||
| else() | ||
| set(def "${CMAKE_CURRENT_SOURCE_DIR}/d3dxof64.def") | ||
| endif() | ||
| set(imp "${CMAKE_CURRENT_BINARY_DIR}/d3dxof.lib") | ||
| set(exp "${CMAKE_CURRENT_BINARY_DIR}/d3dxof.exp") |
There was a problem hiding this comment.
I was able to get everything building and linking with MSVC targeting x64.
There is now an issue with d3drm's dependency on d3dxof: does a 64-bit d3dxof.dll even exist?
Perhaps we need to copy its code from wine as well.
There was a problem hiding this comment.
I think the (initial) easiest solution would be to load DirectXFileCreate dynamically (using LoadLibrary + GetProcAddress).
We might not even need d3dxof.dll library.
There was a problem hiding this comment.
Never mind, looks like it is used to deserialize data.
There was a problem hiding this comment.
I made this an option so you can try by configuring with -DWINE_D3DRM_DYNAMIC_D3DXOF=ON/OFF.
No description provided.