Compiling from Linux for Windows

[BielBdeLuna]

I might be in a position where I might have to compile OTE for windows, for a team that wants to do some mod for Doom3, now I don't have access to a Windows machine. I wonder can code be compiled following the compilation in the readme from within Wine? is there any option for a cross operating system compile solution, in Dhewm3 there was "mingw-w64" but I never used it, and I guess it was a cross operating system compiler?

[BielBdeLuna]

I've tried the first step, and Wine stops with an error, I guess I'm better off searching a windows machine to compile it.

[BielBdeLuna]

I tried calling the mingw inspired on the bat file that tries to call it. but it has been unsuccessfully, now I asked about it in RobertBeckebans/RBDOOM-3-BFG#340 to see if they knew anything about it... any idea ?

[damiel]

Well mingw is useful for two cases, first to compile on windows using gcc and second to compile binaries that target windows on linux aka cross-compilling.

The dhewm 3 readme gives you a good hint what you have to do:

Cross compiling

For cross compiling a CMake Toolchain file is required.

For the mingw-w64 toolchain "i686-w64-mingw32" on Ubuntu precise it looks like:

set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_SYSTEM_PROCESSOR i686)

set(CMAKE_C_COMPILER i686-w64-mingw32-gcc)
set(CMAKE_CXX_COMPILER i686-w64-mingw32-g++)
set(CMAKE_RC_COMPILER i686-w64-mingw32-windres)

set(CMAKE_FIND_ROOT_PATH /usr/i686-w64-mingw32)

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
Then point CMake at your Toolchain file: cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/Toolchain.cmake -DDHEWM3LIBS=/path/to/dhewm3-libs/i686-w64-mingw32 /path/to/repository/neo

Ofc, you have to adapt stuff as we dont have ddhewm3libs(omit that switch) with a mingw compiler in it, on ubuntu you can install a mingw compiler with the package mingw-w64.

[BielBdeLuna]

yes I've seen this, but where do I set all those "sets", can we make a "generator" that appears on the list of generators for the script to call it? where are those "generators" defined?

[damiel]

You create a file called Toolchain.cmake or MyMagicUnicorn.cmake and put the settings in it, then you point to it with the -DCMAKE_TOOLCHAIN_FILE=/path/to/Toolchain.cmake switch to it. The generators are defined by cmake itself, in theory you should be able to call the mingw generator once you have mingw installed. (probably have to close and reopen your shell once you installed mingw)

[BielBdeLuna]

ok so the *.sh file would read like something like this:

cd ..
rm -rf build
mkdir build
cd build
cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/Toolchain.cmake -DCMAKE_BUILD_TYPE=Release ../neo

isn't it? and where should I save this prude "MyMagicUnicorn.cmake" file, alongside the scripts, or is there a more appropriate place?

[damiel]

Placing the file is up to you, id probably place it alongside with the other cmake files inside of the neo directory and add -DCMAKE_TOOLCHAIN_FILE=../neo/Toolchain.cmake

[BielBdeLuna]

oh, now I see that OTE has already the mingw32.toolchain.cmake and the cmake-eclipse-mingw-debug.sh files! RBDoom3BFG lacks the toolchain, If the sh works I'll do a pull request so they have this also!

[BielBdeLuna]

oh snap! I don't have DirectX! :)

$ ./cmake-eclipse-linux-x86_64mingw-release.sh 
-- The C compiler identification is GNU 5.3.1
-- The CXX compiler identification is GNU 5.3.1
-- Could not determine Eclipse version, assuming at least 3.6 (Helios). Adjust CMAKE_ECLIPSE_VERSION if this is wrong.
-- Check for working C compiler: /usr/bin/x86_64-w64-mingw32-gcc
-- Check for working C compiler: /usr/bin/x86_64-w64-mingw32-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/x86_64-w64-mingw32-c++
-- Check for working CXX compiler: /usr/bin/x86_64-w64-mingw32-c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMAKE_BUILD_TYPE:Debug
CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
  Could NOT find DirectX (missing: DirectX_XINPUT_LIBRARY)
Call Stack (most recent call first):
  /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)
  cmake/FindDirectX.cmake:36 (find_package_handle_standard_args)
  CMakeLists.txt:90 (find_package)


-- Configuring incomplete, errors occurred!
See also "/usr/local/share/d3bfg/src/RBDOOM-3-BFG/build/CMakeFiles/CMakeOutput.log".

we might have to create a "if(unix)" section in FindDirectX.cmake ?

[damiel]

My bad, completly missed those files. This one might be worth a try : http://stackoverflow.com/a/3817763

[BielBdeLuna]

but Directx from 2007 isn't too old for BFG? is directx needed for the sound on Windows? if so can't we use OpenAl for Windows?

[damiel]

Well you can always try to install newer versions of directx on wine, not
sure if its going to work. I am not 100% sure for what directx is used, i
know we have xaudio2 for windows for sound buts thats about what i know on
this topic.

2016-08-07 1:58 GMT+02:00 Biel Bestué de Luna notifications@github.com:

but Directx from 2007 isn't too old for BFG? is directx needed for the
sound on Windows? if so can't we use OpenAl for Windows?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#45 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFBC-C2ezwxkJTg8rCRKBknBsOymHcoiks5qdR-6gaJpZM4JeU4S
.

[BielBdeLuna]

a quick search in the code for the term "DirectX" reveals:

directx is for ffmpeg and xaudio, can we pass without them as a testbed? deactivate them so no more DirectX for the moment? and see if it compiles

[damiel]

Ffmpeg is disabled by default if i am not mistaken and xaudio is used for sound on windows only but i think you can turn it off and make the engine use openal instead ( not sure how well tested that is). Just give it a shot, we might aswell learn something from it :)

[BielBdeLuna]

I deactivated FFmpeg and forced OpenAL in CMakeLists.txt:

(...)
option(SDL2
        "Use SDL2 instead of SDL1.2" ON)

option(OPENAL
        "Use OpenAL soft instead of XAudio2" ON)

option(FFMPEG
        "Use FMPEG to render Bink videos" OFF)
(...)

and in linux it compiles fine, audio works (as usually) and the videos no longer play

but attempting to compile with mingw it keeps stoppping because the need for DirectX.

could it be that DirectX is also used for input instead of SDL2 (it doesn't seem to be that way in the code but the fact that it attempts to search for a: "DirectX_XINPUT_LIBRARY", is this "xinput library" maybe a part of DirectX that handles mouse, keyboard and joystick/gamepad inputs?

now apparently I'm also forcing SDL2, but maybe this gets ignored if we compile for Windows?

[BielBdeLuna]

yes examining CMakeLists.txt deeper. I see there are any SDL reference in MSVC (that I guess it's Windows) and there are references to DirectX, I wonder what would happen if I force SDL there in replacing any DirectX for SDL...

[kortemik]

See https://travis-ci.org/OpenTechEngine/OpenTechBFG/jobs/147780640

On Mon, Aug 8, 2016 at 6:50 PM, Biel Bestué de Luna <
notifications@github.com> wrote:

yes examining CMakeLists.txt deeper. I see there are any SDL reference in
MSVC (that I guess it's Windows) and there are references to DirectX, I
wonder what would happen if I force SDL there in replacing any DirectX for
SDL...

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#45 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA19OiMlx6I2-zhuB1NXGKjtrogUM_3Bks5qd1AogaJpZM4JeU4S
.

[BielBdeLuna]

this is exactly how I have the the script that calls cmake

[damiel]

I did some searching for your problem and found a interesting comment in our main cmake file:

if(NOT MSVC)

on other platforms we must use openal because they don't have xaudio - and mingw is missing XAudio2.h

FIXME: can we somehow have it default to OFF on windows and ON everywhere else?

set(OPENAL TRUE)
endif()

Maybe you can try getting the XAudio2.h from somewhere and place it in the appropriate place to make it compile?

Also from what i could find, xinput seems to be replacement api for DirectInput.

[BielBdeLuna]

I'll try, I'm also attempting a cross-compiling on Dhewm3 which I'm facing with some additional problems. It's possible that we would need the binaries for SDL and even for Directx just like we have them for Dhewm3. in dhewm3 in the binaries pack more that having the complete code for OpenAL we have the c++ connection to OpenAL (just like how Doom3SDK had the c++ connection to the renderer)

I wonder if so much reference to xinput means in Windows we're using directx for inptut instead of SDL2, I wish we could force SDL2.

I wonder also if we can "set(OPENAL TRUE)" on MSVC (it doesn't seem to work though!)

[kortemik]

I don't quite understand the problem? OTE compiles with mingw on linux to windows just fine as seen on CI and we have releases automated from CI with tagged commits

[BielBdeLuna]

Yes, I was trying it with RBDoom3BFG trying to port the process to RBdoom3BFG, as I thought RBDoom3BFG would be far easier as it uses less external libraries, well I was completely wrong.

Now I've seen there's a sh file: cmake-eclipse-mingw-debug.sh

compiled fine, and triying in windows in needs all the dll generated from cegui

it generated an OpenAL.dll which I copied too

and when I try to enter it it needs a file named: "libgcc_s_seh-1.dll"
It seems that file and some others it might ask for afterwards come with Mingw for windows, but I've been reading some posts and it seems that they can be included ( statically linked? ) within the *.exe file. how can we do this? the idea would be that the end user wouldn't have to install Mingw in order to use the engine.

[kortemik]

Those files are gcc runtime dlls which you can find under mingw bin
directory if i recall.

On Sun, Aug 14, 2016 at 8:29 PM, Biel Bestué de Luna <
notifications@github.com> wrote:

Yes, I was trying it with RBDoom3BFG trying to port the process to
RBdoom3BFG, as I thought RBDoom3BFG would be far easier as it uses less
external libraries, well I was completely wrong.

Now I've seen there's a sh file: cmake-eclipse-mingw-debug.sh

compiled fine, and triying in windows in needs all the dll generated from
cegui

it generated an OpenAL.dll which I copied too

and when I try to enter it it needs a file named: "libgcc_s_seh-1.dll"
It seems that file and some others it might ask for afterwards come with
Mingw for windows, but I've been reading and it seems that they can be
included ( statically linked? ) within the *.exe file. how can we do this?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#45 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA19Oj48Tl711lTJTd12dMpWTMKn-4Rdks5qf1BmgaJpZM4JeU4S
.

[BielBdeLuna]

OpenTechEngine.exe expects:

libgcc_s_seh-1.dll
libstdc++-6.dll

I couldn't find the first on the Mingw folder so I downloaded from the net

but now OpenTechEngine.exe fails with what I guess it's a segfault for windows
"The application couldn't be initiated correctly(0x000007b)"

Is there a way to see the same content from a Linux console in Windows7?

[kortemik]

at least running in gdb shows the shell output, i'd expect the same from
mingw/cygwin prompt

On Sun, Aug 14, 2016 at 10:13 PM, Biel Bestué de Luna <
notifications@github.com> wrote:

OpenTechEngine.exe expects:

libgcc_s_seh-1.dll
libstdc++-6.dll

I couldn't find the first on the Mingw folder so I downloaded from the net

but now OpenTechEngine.exe fails with what I guess it's a segfault for
windows
"The application couldn't be initiated correctly(0x000007b)"

Is there a way to see the same content from a Linux console in Windows7?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#45 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA19OiWICBY0Vd5vXvdA5tDEOu4XqYedks5qf2j3gaJpZM4JeU4S
.

[BielBdeLuna]

what is gdb?

[damiel]

The Gnu Project Debugger: https://www.gnu.org/software/gdb/

2016-08-14 23:36 GMT+02:00 Biel Bestué de Luna notifications@github.com:

what is gdb?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#45 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFBC-E0C-Re7AIyJChqQWcB_81RocHKWks5qf4pugaJpZM4JeU4S
.