Compilation errors when compiling from source

[deadlocklogic]

I am having trouble compiling from source on Windows using megasource.
I am running:

cmake -G "Visual Studio 17 2022" -A x64 -S . -B build
cmake --build build --target love/love --config Release

I am getting these errors:

error C3861: luaL_checkint

This is easily fixed by replacing the deprecated luaL_checkint/luaL_optint with luaL_checkinteger/luaL_optinteger anyway.
The 2 versions of the same function are even present close to each other, which is quite smelly.

love/src/modules/graphics/wrap_Mesh.cpp

Lines 352 to 355 in 8e6efac

	else
	attachlocation = luaL_optint(L, 5, location);
	int startindex = (int) luaL_optinteger(L, 6, 1) - 1;

error LNK2001/LNK2019: unresolved external symbol

I guess there might be some linking errors caused by symbol name mangling because of missing extern "C".

Might be a little related with #2102.

Any thought about this issue?

[deadlocklogic]

I was able to compile the project after modifying the CMakeLists.txt and reorder the targets.
Why do the library targets get their linked libraries omitted and only link in the final target by transitively.
Like box2d for example: why love_physics_root and love_physics don't link to love_3p_box2d directly, instead they hope getting linked with liblove which is problematic and produces linking errors.
I can provide a PR if someone is willing to assist.

This link explains that this behavior isn't available in CMake especially for static linking: https://gitlab.kitware.com/cmake/cmake/-/issues/18090
Wonder how the library is being build with the current build script.

P.S:

The build script I am talking about is the CMakeLists.txt of the megasource project, but I am not sure if I should open the issue there too.

[slime73]

The current love source code and megasource are building without issues, you can see it working here: https://github.com/love2d/love/actions/runs/11087159289/job/30805542624

It sounds like you probably have local modifications to one of those, or to the build process, which is causing problems for you.

I am getting these errors:
error C3861: luaL_checkint
This is easily fixed by replacing the deprecated luaL_checkint/luaL_optint with luaL_checkinteger/luaL_optinteger anyway.
The 2 versions of the same function are even present close to each other, which is quite smelly.

This means you aren't building with LuaJIT, which love uses by default, so you definitely have modifications somewhere. luaL_checkint is a valid choice to use there when supporting LuaJIT, although we'll eventually want to clean it up to support people using other Lua versions.

[deadlocklogic]

@slime73 I am building the project from source on the main branch of love and megasource.
So my steps are exactly like the one given in the megasource:

$ git clone https://github.com/love2d/megasource megasource
$ cd megasource
$ git clone https://github.com/love2d/love libs/love
$ cmake -G "Visual Studio 17 2022" -A x64 -S . -B build
$ cmake --build build --target love/love --config Release

[slime73]

Something in your environment is causing a non-standard build (do you have any environment variables set, for example)?

You can refer to the Github Actions CI builds for how a clean run will behave - and you can download them too if you just want a build with the latest 12.0 changes.

[deadlocklogic]

I usually use vcpkg to manage my dependencies, but it won't interfere with the build process as long as its toolchain isn't invoked.
The first thing I looked into is the github actions, before even opening this issue and even trying to debug the problem myself, because it simply has all the steps to create a release, which requires building the library successfully.
But this is completely different from the simple steps given in the megasource then, actually it is a different build process itself, the process includes using ANGLE and some other steps.
But seriously, why changing the ordering of the CMake targets resolves the issue? Maybe the issue isn't manifested in the version of CMake used for building.
You can again have a look at https://gitlab.kitware.com/cmake/cmake/-/issues/18090, and see what I am talking about, the behavior used in the build script of megasource isn't standard CMake behavior.

[slime73]

I usually use vcpkg to manage my dependencies, but it won't interfere with the build process as long as its toolchain isn't invoked.

I wouldn't be so sure of that. Even the Github Actions CI stuff has to take steps to prevent someone else's installed project from interfering (Strawberry Perl, which has caused issues for many github projects).

In your previous posts you indicated that the version of Lua being included is not one that's provided by megasource (those support luaL_checkint), so they're coming from somewhere else on your computer.

the process includes using ANGLE and some other steps.

That's just for the test framework that's run after a successful build, you don't need that.

I run the same steps as the megasource readme describes on my own Windows computer and I have no issues. I'm positive you have something in your local environment that's interfering. You may want to post on the forums or discord server for further help, since the issue tracker isn't really a place for troubleshooting.

[deadlocklogic]

Ok, I will close this issue anyway.
I have lua installed globally indeed, which may be interfering with luaL_checkint. Notice that migrating to luaL_checkinteger should be the way to go anyway, instead of using the 2 versions simultaneously.
But for the linking issue of box2d, I am pretty sure that linking targets transitively isn't a CMake standard, and I don't have any box2d binaries installed on my machine.

[deadlocklogic]

Just another argument from the a CMake maintainer himself, https://gitlab.kitware.com/cmake/cmake/-/issues/18724

Dependencies need to be expressed directly on the target that has them, e.g.