Compilation errors

[Gangrenous]

I am trying to update to the current source, but keep my existing changes and I am definitely getting some compilation errors. I have not spent a large amount of time looking for the source of the errors, I want to make sure it is not a compiler problem first. Has anything changed on the Linux requirements? Has the compiler or prerequisites changed? Is Linux currently compiling? I see in the changes where Jabantiz was definitely having some issues with the Linux compilation.

[Gangrenous]

It looks like I am getting hit where you were trying to fix some compiler issues.

Fixed: to_string() is c++11 so had to add a fallback function to support it

Commands/Commands.cpp:3001:86: error: ‘to_string’ was not declared in this scope
string title = string(spawn->GetName()) + "(" + to_string(spawn->GetDatabaseID()) + ")";


And what happened to the code button for formatting? I have like 20 more icons on the editor now but the one I need seems to be missing.

[Jabantiz]

Linux compiles, the eq2emulator server is run on Linux. I did make changes to the makefile, are you using the new one? the .a64 one was never updated as the other one covers both 64 and 32 now. The code does use c++11 now so the to_string shouldn't be the issue and I have removed those fallback functions.

[Gangrenous]

When I used the current Makefile I had way more compilation errors. I will try to see what changed between them and come up with something that works.

[Jabantiz]

Have you tried downloading the svn into a new folder and compiling just the code on svn to see if there is any compile errors?

[tyrbo]

fwiw, I'm on Linux as well and didn't have any issues using the new makefile.

Logs would help.

Also probably gcc version and things like that.

[Gangrenous]

Yeah that is what I was gathering more information. So my last source update was in late 2016, so I have been stagnant. Everything was fine until I got to a major update, r2686 on 11/22/2017. Even though that gave a ton of warnings and errors I never got before, I went all the way to r2695 since I could see where Jabantiz was having a really bad night. This is just a little bit of it.

Linking...
build/release/WorldServer/LuaInterface.o: In function `LuaInterface::RegisterFunctions(lua_State*)':
/home/eq2/src/source/WorldServer/../WorldServer/LuaInterface.cpp:588: undefined reference to `lua_pushcclosure'
/home/eq2/src/source/WorldServer/../WorldServer/LuaInterface.cpp:588: undefined reference to `lua_setglobal'
/home/eq2/src/source/WorldServer/../WorldServer/LuaInterface.cpp:589: undefined reference to `lua_pushcclosure'
/home/eq2/src/source/WorldServer/../WorldServer/LuaInterface.cpp:589: undefined reference to `lua_setglobal'
/home/eq2/src/source/WorldServer/../WorldServer/LuaInterface.cpp:590: undefined reference to `lua_pushcclosure'
/home/eq2/src/source/WorldServer/../WorldServer/LuaInterface.cpp:590: undefined reference to `lua_setglobal'
/home/eq2/src/source/WorldServer/../WorldServer/LuaInterface.cpp:591: undefined reference to `lua_pushcclosure'
/home/eq2/src/source/WorldServer/../WorldServer/LuaInterface.cpp:591: undefined reference to `lua_setglobal'
/home/eq2/src/source/WorldServer/../WorldServer/LuaInterface.cpp:592: undefined reference to `lua_pushcclosure'

Should I be going to a new compiler, is my LUA out of date? I can definitely update my Debian, but I want to do a snapshot just in case things go to shit.

Other warnings I see that definitely were not there before.

../common/MiscFunctions.cpp:742:88: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 5 has type ‘size_t {aka long unsigned int}’ [-Wformat=]
fprintf(stderr, "%s: %u: Unable to allocate %u bytes\n", __FUNCTION__, __LINE__, size);


../WorldServer/Commands/ConsoleCommands.cpp:311:59: warning: format ‘%i’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=]
printf("> Locking zone ID %i...\n", atoul(sep->arg[2]));

[Gangrenous]

I think I figured it out. I looked at the Makefile and noticed the Lua was spelled without all caps, I am guessing later on the Makefile was changed. After I made that change it did compile.

Question though, I could had sworn that make clean used to clean out all of the *.o files, now it does not?

Also there seems to be references to VGOEMU

#setup:
# @test ! -e volumes.phys && ln -s $(Conf_Dir)/volumes.phys . || /bin/true
# @test ! -e vgemu-structs.xml && ln -s $(Conf_Dir)/vgemu-structs.xml . || /bin/true
# @$(foreach folder,$(wildcard $(Content_Dir)/scripts/*),test -d $(Content_Dir)/scripts && test ! -e $(notdir $(folder)) && ln -s $(folder) . || /bin/true)
# @echo "Symlinks have been created."
# @cp -n $(Conf_Dir)/vgemu-world.xml .
# @echo "You need to edit your config file: vgemu-world.xml"

[tyrbo]

You might be looking for make cleanall now.

[John Adams]

Also there seems to be references to VGOEMU

What the devil?

[Jabantiz]

Yea the makefile was from vgo as theirs was a lot better then what we had, no longer have to add every single new file to it as it will find it on its own. The lua .o aren't cleaned up as there should really be no changes to them ever, unless we update to newer versions. Basically just saves some compile time but tyrbo is correct cleanall will delete them if needed.

[Gangrenous]

Yes, but I keep my own SVN and would rather not have the *.o files make it to the submit. I can do an exclusion on those though.

[Gangrenous]

It may help to have a mention of the table changes in the commit. There will be people that keep their own database. I am digging in SVN and getting some structure changes, but it will help others if there is an alter table in the commit.