Workflow in windows

[chriscamacho]

My daily driver is (Void) Linux, and I never appreciated the various issues involved in Windows that in Linux you just never seem to come across...

I have a project using Raylib, Chipmunk, libtmx (this pulls in libxml2, zlib etc)

I had to use msys2 to compile chipmunk and libtmx as both require cmake which isn't in w64devkit, but joy of joys it looks like the compilers aren't compatible.

I did try compiling Raylib with msys2 but then the resulting executable that glfw complains it can't open a display on a null platform.

Can anyone suggest a workflow where I can compile Raylib, Chipmunk and libtmx (ideally all statically) into a single executable...

[orcmid]

@chriscamacho Do you mean this Chipmunk?

It looks like you should be able to build static Chipmunk files just like you can do the same (and recommended) for raylib, and then let the (Visual Studio VC/C++ or maybe gcc) linker optimize what actually must be included into your executable.

The wrinkle in Chipmunk is that it expects any program that uses it must be compiled as C++ even though the API bindings are extern "C" (no name mangling). The peculiarity of the C++ condition is that operator overloading is relied on, and maybe other features. This is potentially messy with regard to runtimes and malloc dependencies. :).

There are also Win32 and Visual Studio dependencies that have not been kept current since VS 2017.

Having said all of that, I think you can just build all of the Chipmunk modules without CMake, cache the results and have those intermediates drawn into the linking. I never do anything but x64 builds using Visual Studio build tools (now at 17.5.x) that way, so this advice may not be helpful for you. (You want compiling to be into modes where link-time optimization does not include anything that your code does not depend on, directly or indirectly. Makes for tidy executables.)

[orcmid]

@chriscamacho The dependency on libtmx is more difficult. It is specifically and only written for use in C++ programs (depending on C++11). There's no mention of Visual Studio or VC/C++ so the odds on building Windows executables may be doubtful. I would suspect malloc weirdness across the 3 dependencies. You may discover all the places where malloc's return NULL and things go haywire.

Compiling raylib modules as C code is fine. You need to compile the others as C++ code, and link the *.obj files from all of them (or *.a) in a big pot along with your own C++ code. Then build a statically-linked code of yours, drawing in the others for inclusion of whatever is needed. You do need a linker that doesn't just include an entire file because some external entry into it is used.

I am ignoring the dependency of libtmx on libxml2, zlib, etc. This may just be an unhappy coalition of the unwilling.

PS: I assume you create a workflow in which the three dependencies (and their dependencies) have their modules compiled only once and kept sitting in a cache of compiled objects that you reference when linking compilations of your own code. You don't need to refresh the cache unless there is an update (i.e., a new raylib release you want to rely on).

[chriscamacho]

largely speaking the language is not an issue where the library has a C API... by preference I'd rather use a static library .a (or .lib depending on compiler) so all dependencies are part of the executable, the compiler is more than capable of dropping code that can't be reached... (optimisation) I'd rather compile with pre-compiled static libraries as I have no need to modify the code. I've had more issues from libtmx (only on Windows) as it drags in libxml2 which in turn drags in other stuff... I've also had issues with compiling Raylib too (which I haven't encountered before when compiling on Windows) specifically the GLFW null platform issue.

…

On Sun, 23 Apr 2023 at 16:56, Dennis E. Hamilton ***@***.***> wrote: @chriscamacho <https://github.com/chriscamacho> Do you mean this Chipmunk <https://github.com/slembcke/Chipmunk2D>? It looks like you should be able to build static Chipmunk files just like you can do the same (and recommended) for raylib, and then let the (Visual Studio VC/C++ or maybe gcc) linker optimize what actually must be included into your executable. The wrinkle in Chipmunk is that it expects any program that uses it must be compiled as C++ even though the API bindings are extern "C" (no name mangling). The peculiarity of the C++ condition is that operator overloading is relied on, and maybe other features. This is potentially messy with regard to runtimes and malloc dependencies. :). There are also Win32 and Visual Studio dependencies that have not been kept current since VS 2017. Having said all of that, I think you can just build all of the Chipmunk modules without CMake, cache the results and have those intermediates drawn into the linking. I never do anything but x64 builds using Visual Studio build tools (now at 17.5.x) that way, so this advice may not be helpful for you. (You want compiling to be into modes where link-time optimization does not include anything that your code does not depend on, directly or indirectly. Makes for tidy executables.) — Reply to this email directly, view it on GitHub <#3025 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFO4SMINXNXDJ62QGX4K3DXCVGMLANCNFSM6AAAAAAXILYMEA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- blog bedroomcoders.co.uk <http://bedroomcoders.co.uk> Free source code and tutorials! Disclaimer: By sending an email to ANY of my addresses you are agreeing that: 1. I am by definition, "the intended recipient" 2. All information in the email is mine to do with as I see fit and make such financial profit, political mileage, or good joke as it lends itself to. In particular, I may quote it where I please. 3. I may take the contents as representing the views of your company. 4. This overrides any disclaimer or statement of confidentiality that may be included on your message.

[orcmid]

You can just include *.obj files in the link/compile command and they are treated like single file *.lib code. No need to bundle them. When I link with a cache of raylib files in cache\, I just include cache\*.obj along with my app\*.obj and the system libraries I need to make a Windows .exe. It all works as you expect.

I think you must compile your code in C++ to have libtmx work though. I take their word for it.

[chriscamacho]

In linux I used repo dev packages for Chipmunk and compiled libtmx with cmake (so their build process), from both I used a static lib (.a) and it all works fine, no stress, so far I've had nothing but grief trying to do anything with Windows, guess I'm spoilt...

[orcmid]

@chriscamacho If you precompile them yourself, you can pretty much count on their being compatible across the different compiling variations that can otherwise creep in (e.g., over padding of structs, platform optimizations, other things). You also get to see any significant warnings that you might otherwise not know about.

So long as the compiling options are the same ones with your own code, the linking should always work. This will also ensure that the headers used will match the code of the implementations. This is the same as static-library linking but more fine-grained.

I agree it seems to be trickier on/for Windows, mostly because I think some open-source projects aren't diligent about such cases. I think some of the #ifdef variations for platform differences are made without adequate verification. I have seen that creep into raylib, for one example.

[chriscamacho]

well.... I ended up in visual studion 2022... got most of the way and hit a big block with linxml2 which I just couldn't get to compile... I'm going to leave it for a little while 'cause I'm thoroughly hacked off with Windows...

[chriscamacho]

well I'm a lot closer this try....

1>raylib.lib(rcore.obj) : error LNK2019: unresolved external symbol timeBeginPeriod referenced in function InitTimer
1>raylib.lib(rcore.obj) : error LNK2019: unresolved external symbol timeEndPeriod referenced in function CloseWindow

despite having winmm.lib as an additional dependency

this is linking to raylib compiled with the vc2022 solution in the raylib project folder - the examples compile and work....

[raysan5]

Afair, WinMM could be avoided but the timers resolution will be quite bad (ms). Also, make sure winmm.lib is linked after raylib.