x64 Development

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
I committed a while ago a set of CMake files to create a solid Project files for Visual Studio without the debug/release problem. I haven't tried how they work with the Ninja yet. I haven't have much luck with it. I also updated my VS2015 to VS2019 and haven't noticed and major issues.

CMake Update
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,214
Reaction score
1,560
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
I just checked that, and while the build folder does have the Debug/Release subdirectory problems, my install folder is ok and does produce a working Orbiter setup. And if I build the D3D9Client in the install folder that seems to work too.

The only thing I usually change is the default install prefix, which CMake sets to C:\Program Files\Orbiter.

Just to be clear, by "install" I mean the target that CMake builds with the "CMakePredefinedTargets | INSTALL" project. Do you know what the problem is with your installation folder? Are there any files missing?

Thanks for the information! The key point I was missing was needing to run the CMakePredefinedTargets -> INSTALL project instead of just "Rebuild All". To sum up, I was successfully able to build a working Orbiter installation without using (the buggy) Ninja CMake in the latest VS 2019 patch (version 16.11.1) now!

In case anyone else runs into the same problems I did, here is how I built a working Orbiter installation. From a Command Prompt:

Code:
@rem initialize the VS 2019 build environment
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars32.bat"

@REM to build x64, set '-A x64' instead of '-A Win32' below, and pick different paths for -B and -D settings.
@REM see here for more information: https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2016%202019.html
cmake -G "Visual Studio 16 2019" -A Win32 -D IRRKLANG_DIR=D:\irrKlang -D "CMAKE_CONFIGURATION_TYPES=Debug;Release" -D "CMAKE_INSTALL_PREFIX:PATH=D:\Orbiter_out" -S D:\GitHub\orbiter_cleanfetch_testing\orbiter -B D:\Orbiter_cmake_out

@rem Then open VS 2019 and open the generated solution D:\Orbiter_cmake_out\Orbiter.sln.
@rem Click Build -> Rebuild All.  (This finished with "========== Rebuild All: 103 succeeded, 1 failed, 3 skipped ==========")
@rem Then build the Orbiter install folder by expanding the solution folder CMakePredefinedTarget -> right-click INSTALL -> Build (this finished with " ========== Build: 29 succeeded, 0 failed, 76 up-to-date, 0 skipped ==========")

@rem Now you are ready to bring up Orbiter from the install folder you just created:
CD /D D:\Orbiter_out\Orbiter
Orbiter.exe
@rem Now you can set video parameters, activate the XRSound module, and load up a DG scenario to test it

Thanks again for the information! Now I can set up a new output folder and build Orbiter without using (the buggy) Ninja CMake. (y)

One more question -- does anyone know how to configure CMake to generate both Win32 ( x86) and x64 platform targets in the same, single Orbiter.sln? From experimenting with the CMake settings, it seems like CMake only generates one set of platforms (x86 or x64) per solution. Not a big deal, just not quite as convenient.
 

DarkWanderer

Active member
Orbiter Contributor
Donator
Joined
Apr 27, 2008
Messages
213
Reaction score
83
Points
43
Location
Moscow
One more question -- does anyone know how to configure CMake to generate both Win32 ( x86) and x64 platform targets in the same, single Orbiter.sln? From experimenting with the CMake settings, it seems like CMake only generates one set of platforms (x86 or x64) per solution. Not a big deal, just not quite as convenient.

CMake just doesn't suppport this directly: https://discourse.cmake.org/t/how-to-make-a-visual-studio-solution-with-x64-x86-support/880
Only way to switch within same VS instance is to use CMakeSettings/CMakePresets (which is why I am pushing for it). Otherwise, having separate build directories seems like the only option
 
Last edited:

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
@rem Then open VS 2019 and open the generated solution D:\Orbiter_cmake_out\Orbiter.sln.
@rem Click Build -> Rebuild All. (This finished with "========== Rebuild All: 103 succeeded, 1 failed, 3 skipped ==========")
Do you know which of the projects is failing? Is it something I should look into?
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,214
Reaction score
1,560
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
Do you know which of the projects is failing? Is it something I should look into?

I found the relevant parts of the build log and spliced them back together:

Code:
31>------ Rebuild All started: Project: XRSound_dll, Configuration: Debug x64 ------
31>Building Custom Rule D:/GitHub/orbiter/Sound/XRSound/XRSound/src/XRSoundDLL/CMakeLists.txt
31>DefaultSoundGroupPreSteps.cpp
31>ModuleXRSoundEngine.cpp
31>SoundPreSteps.cpp
31>VesselXRSoundEngine.cpp
31>XRSoundConfigFileParser.cpp
31>XRSoundDLL.cpp
31>XRSoundEngine.cpp
31>ConfigFileParser.cpp
31>FileList.cpp
31>Generating Code…
31>LINK : fatal error LNK1104: cannot open file '..\..\..\..\..\Src\Orbiter\Debug\Orbiter.lib'
31>Done building project "XRSound_dll.vcxproj" -- FAILED.

From digging into it a bit, it appears to be a build dependency issue, because when I then click Build -> Build Solution again, it links fine (because Orbiter.lib was already built at that point by the first build pass). So I suspect that the XRSoundDLL/CMakeLists.txt makefile just needs to set a dependency on Orbiter.lib, although I haven't messed with CMake enough to dig into that further. :) The reason the install must have worked for me last night is because when I then built the INSTALL project, it linked XRSound.dll in that build step, right before copying the DLL to Modules\Plugin.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
From digging into it a bit, it appears to be a build dependency issue, because when I then click Build -> Build Solution again, it links fine (because Orbiter.lib was already built at that point by the first build pass). So I suspect that the XRSoundDLL/CMakeLists.txt makefile just needs to set a dependency on Orbiter.lib, although I haven't messed with CMake enough to dig into that further. :) The reason the install must have worked for me last night is because when I then built the INSTALL project, it linked XRSound.dll in that build step, right before copying the DLL to Modules\Plugin.
Yes, it looks like I missed to add the dependencies. Must have been just lucky that I didn't run into that problem myself.
I have added the dependencies now and created a pull request. Could you check if this is working for you (you may have to start from a clean build directory to give it a chance to fail, and even then a success might not prove anything - but at least it shouldn't fail). If it works for you, please merge the pull request.
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,214
Reaction score
1,560
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
I have added the dependencies now and created a pull request. Could you check if this is working for you (you may have to start from a clean build directory to give it a chance to fail, and even then a success might not prove anything - but at least it shouldn't fail). If it works for you, please merge the pull request.

Code:
========== Rebuild All: 104 succeeded, 0 failed, 3 skipped ==========

Looks good (and it was failing consistently for me before). Thanks for the quick fix! Pull request merged. (y)
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,877
Reaction score
2,870
Points
188
Website
github.com
I have the latest code from the trunk building successfully (BTW all, be sure you re-run the VS 2019 setup program and install the latest MFC build package if you didn't already select that when you installed your VS 2019), but when I load a scenario, all the vessel loads fail with errors like this:



From debugging it, the LoadLibrary call is failing here:

Code:
bool Vessel::RegisterModule (const char *dllname)
{
    char cbuf[256];
    sprintf (cbuf, "Modules\\%s.dll", dllname); <<< also fails if I hardcode the full path here as "D:\\Orbiter_x64\\orbiter\\out\\build\\x64-Debug\\Modules"
    hMod = LoadLibrary (cbuf);
    if (!hMod)
        return false;
    ...
}
I decided to get a x64 version going (to actually see the Skybolt client running), but I'm having the same issue as above loading vessel modules only, all the planetary modules before load well.
VS2017 projects, created from CMake (I only have to remove the html lib from the main project). Same process works for x86 and it runs as advertised. Comparing a vessel project with a planet project, they seem to link to the same system and Orbiter libs, and both have the same settings.
In terms of dependencies, nothing obvious seems to be missing.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,877
Reaction score
2,870
Points
188
Website
github.com
After much digging it turns out I was missing the x64 version of this: https://www.microsoft.com/en-us/download/details.aspx?id=26999
The theory is that lua51.lib needs that, and I'm 99.999999% sure I had the x86 version installed (it runs Orbiter x86, duh) but didn't have the x64 version.
Maybe this should be noted somewhere so more people don't fall into the same hole...
 

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
222
Reaction score
258
Points
78
Location
On my chair
After much digging it turns out I was missing the x64 version of this: https://www.microsoft.com/en-us/download/details.aspx?id=26999
The theory is that lua51.lib needs that, and I'm 99.999999% sure I had the x86 version installed (it runs Orbiter x86, duh) but didn't have the x64 version.
Maybe this should be noted somewhere so more people don't fall into the same hole...
lua being so small, why not compile it ourselves at the same time as Orbiter and get rid of this kind of issues? I'm using a slightly modified version of this cmake file to build it on my linux branch, maybe it'll work on windows too...
 

Sword7

Member
Joined
Mar 23, 2008
Messages
140
Reaction score
16
Points
18
Location
Gaithersburg, MD
I have VS 2022 here. Is this Orbiter x64 development compatible with VS 2022?

Update: I tried to build all but message showed that it tried to find Visual Studio 2019. I installed Visual Studio 2019 and it made through...

It complaint about afxwin.h not found. I checked it and have to install MFC package in Visual Studio Installer. It now made through...

It now complaint about missing ODT to PDF compiler. I did installed LibreOffice but Orbiter's compile instructions did not mention about ODT to PDF compiler setup.

Does anyone know which tool program for ODT to PDF compiler in LibreOffice?

Thanks,
Tim
 
Last edited:

supersonic71

Member
Joined
Sep 20, 2021
Messages
59
Reaction score
86
Points
18
Location
Asia Pac
Website
github.com
Update: I tried to build all but message showed that it tried to find Visual Studio 2019. I installed Visual Studio 2019 and it made through...
Yeah I too ended up using vs2019. But for anyone trying to build in vs2022 in the future, maybe this could help (saw this later) :
CaptainSwag101 : Hello, I had the same issue, you can fix this by editing Utils/CMakeLists.txt and changing the text "Visual Studio 16 2019" to "Visual Studio 17 2022", and then deleting and regenerating the CMake Cache via Visual Studio, performing Clean All, and then your build should work properly.
 
Top