Page 1 of 1
UOX3 Linux Building
Posted: Sun Jul 26, 2020 6:59 pm
by Mindless Automaton
Ok so just for fun I built on Linux Mint 64bit system and everything seemed to go well.
However when I run the server, I get:
Code: Select all
| /UOX3/data/muldata/map0.mul(/) [Failed]
| /UOX3/data/muldata/statics0.mul [done]
| /UOX3/data/muldata/staidx0.mul [done]
| /UOX3/data/muldata/mapdif0.mul [not found]
| /UOX3/data/muldata/stadif0.mul [done]
| /UOX3/data/muldata/mapdifl0.mul [not found]
| /UOX3/data/muldata/stadifi0.mul [done]
| /UOX3/data/muldata/stadifl0.mul [done]
| /UOX3/data/muldata/map0.mul(/) [Failed]
| /UOX3/data/muldata/statics0.mul [done]
I think that 2nd map0 is supposed to be map1 since farther down the list map2 is loaded ok, etc.
map5 has this note with it but loads ok.
Code: Select all
| /UOX3/data/muldata/map5.mul(/map5LegacyMUL.uop) [done]
The MULs were converted with UOFiddler 4.91 and loaded fine on the Windows build.
And finally caching Multis..
Code: Select all
| Caching Multis....
Program received signal SIGSEGV, Segmentation fault.
0x00005555556a5949 in UOX::CMulHandler::LoadMultis(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
I was reading on Discord or old posts here about issues with 64bit, so I will mess around and see what 32bit says for me if I can figure out how to do that.
Re: UOX3 Linux Building
Posted: Sun Jul 26, 2020 7:15 pm
by punt
If you are running 64 bit, one thing that might be a problem is the use of "long". int and long on windows 64 bit are both 32 bit numbers. Windows has one do a long long to get 64 bit.
On Linux (and macOS), in the 64 bit model, int is 32 bit, long and long long are 64 bit.
So if long is used, just recognize that is 64 bit on linux 64. If that is used as an alignment or sizing, that could cause a problem.
So for example, in typedefs.h, there is this:
(on line 31/22)
Code: Select all
typedef unsigned long int UI32;
typedef signed long int SI32;
At a minimum this should be changed to (to make that 32 really be 32 on both linux and windows 64 bit, as well as 32 bit versions))
Code: Select all
typedef unsigned int UI32;
typedef signed int SI32;
I noticed that a lot of places they use ustring.toLong(). Don't know if they really wanted ustring.toInt(), but not sure.
Re: UOX3 Linux Building
Posted: Thu Aug 13, 2020 11:15 am
by Xuri
Btw, after searching through old threads in the forum for a bit... it seems like the reason UOX3 fails to load map0.mul is because it looks in the wrong file for the information about the size of the map! For some reason, on Linux, it grabs that info from maps.4xclients.old instead of maps.dfn in dfndata/maps/. Delete the file, and loading map0.mul works again.
Re: UOX3 Linux Building
Posted: Sat Aug 15, 2020 5:58 am
by Mindless Automaton
Xuri wrote:Btw, after searching through old threads in the forum for a bit... it seems like the reason UOX3 fails to load map0.mul is because it looks in the wrong file for the information about the size of the map! For some reason, on Linux, it grabs that info from maps.4xclients.old instead of maps.dfn in dfndata/maps/. Delete the file, and loading map0.mul works again.
Ok, that clears up the map loading issue but I still seg fault when for caching multis.
Code: Select all
| Caching Multis....
Program received signal SIGSEGV, Segmentation fault.
0x00005555556a5949 in UOX::CMulHandler::LoadMultis(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
(gdb) bt full
#0 0x00005555556a5949 in UOX::CMulHandler::LoadMultis(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
No symbol table info available.
#1 0x00005555556a75d9 in UOX::CMulHandler::Load() ()
No symbol table info available.
#2 0x000055555572c6fe in main ()
No symbol table info available.
(gdb)
So if we open mapstuff.cpp, I can see I'm not a cpp programmer but lets say like punt said, it has to do with the Linux long and long long and Windows being short and short short.
Thanks!
Mindless Automaton
Re: UOX3 Linux Building
Posted: Sat Aug 15, 2020 8:20 am
by Xuri
Yeah, I actually committed an update to the "develop" branch on GitHub to try to address some of those issues (including the map0.mul loading). If you have the chance to grab the source from that branch, compile and see if it makes a difference, that would be great - because I've been unable to reproduce the segfault when caching multis on both 32bit and 64bit Ubuntu myself. As of yesterday, I was able to compile, run and load everything that ought to be loaded on both those platforms using that branch.
Re: UOX3 Linux Building
Posted: Sat Aug 15, 2020 5:13 pm
by Mindless Automaton
Ok, my first build (Jul 28), I just followed the instructions here for building 32 bit even though I am on 64 bit:
viewtopic.php?f=6&t=457
So I didnt do anything different really, downloaded the dev branch, overwrote the old one, make clean, autogen.sh, configure --enable-debug, make -d ..
Code: Select all
Finished prerequisites of target file 'cServerDefinitions.o'.
Must remake target 'cServerDefinitions.o'.
g++ -DHAVE_CONFIG_H -I. -I../spidermonkey --std=c++17 -g -MT cServerDefinitions.o -MD -MP -MF .deps/cServerDefinitions.Tpo -c -o cServerDefinitions.o cServerDefinitions.cpp
Putting child 0x5647bfdcdcd0 (cServerDefinitions.o) PID 13813 on the chain.
Live child 0x5647bfdcdcd0 (cServerDefinitions.o) PID 13813
cServerDefinitions.cpp:5:10: fatal error: filesystem: No such file or directory
#include <filesystem>
^~~~~~~~~~~~
compilation terminated.
Reaping losing child 0x5647bfdcdcd0 PID 13813
Makefile:564: recipe for target 'cServerDefinitions.o' failed
make[1]: *** [cServerDefinitions.o] Error 1
Removing child 0x5647bfdcdcd0 PID 13813 from chain.
make[1]: Leaving directory '/UOX3/source'
Reaping losing child 0x5587f2d81820 PID 13694
Makefile:383: recipe for target 'all' failed
make: *** [all] Error 2
Removing child 0x5587f2d81820 PID 13694 from chain.
root@Eldritch:/UOX3/source#
for which you can do something like #include <experimental/filesystem> & return std::experimental::filesystem::current_path().string(); to get past but then it all blows up again at the end:
Code: Select all
cServerDefinitions.o: In function `std::experimental::filesystem::v1::__cxx11::path::path<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::experimental::filesystem::v1::__cxx11::path>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
/usr/include/c++/7/experimental/bits/fs_path.h:199: undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
collect2: error: ld returned 1 exit status
Reaping losing child 0x557c5bc9df80 PID 20568
Makefile:479: recipe for target 'uox3' failed
make[1]: *** [uox3] Error 1
Removing child 0x557c5bc9df80 PID 20568 from chain.
make[1]: Leaving directory '/UOX3/source'
Reaping losing child 0x5560c17dddc0 PID 20558
Makefile:383: recipe for target 'all' failed
make: *** [all] Error 2
Removing child 0x5560c17dddc0 PID 20558 from chain.
root@Eldritch:/UOX3/source#
Re: UOX3 Linux Building
Posted: Sat Aug 15, 2020 5:41 pm
by Xuri
When you say you followed the steps for 32 bit on 64 bit, you mean you tried the config command under "UOX3 and 64-bit Linux", or you just followed these steps?
Code: Select all
chmod +x autogen.sh
./autogen.sh
make
Could you also try to update your versions of gcc/g++/make/automake, and see if that makes a difference?
Re: UOX3 Linux Building
Posted: Sat Aug 15, 2020 6:12 pm
by Mindless Automaton
Xuri wrote:When you say you followed the steps for 32 bit on 64 bit, you mean you tried the config command under "UOX3 and 64-bit Linux", or you just followed these steps?
Code: Select all
chmod +x autogen.sh
./autogen.sh
make
Yeah pretty much:
Code: Select all
chmod +x autogen.sh
./autogen.sh
./configure --enable-debug
make -d
Re: UOX3 Linux Building
Posted: Sat Aug 15, 2020 6:42 pm
by Xuri
What version of the various tools are you using? According to
https://gcc.gnu.org/onlinedocs/libstdc+ ... s.iso.2017: "GCC 8.x requires linking with -lstdc++fs"
For reference, this is my version info for the tools I used to compile that dev branch on 64 bit Ubuntu 20.04 LTS:
Code: Select all
automake --version
automake (GNU automake) 1.16.1
make --version
GNU Make 4.2.1
gcc --version
gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
g++ --version
g++ (Ubuntu 9.3.0-10ubuntu2) 9.3.0
Re: UOX3 Linux Building
Posted: Tue Aug 18, 2020 3:26 am
by Mindless Automaton
Xuri wrote:What version of the various tools are you using? According to
https://gcc.gnu.org/onlinedocs/libstdc+ ... s.iso.2017: "GCC 8.x requires linking with -lstdc++fs"
For reference, this is my version info for the tools I used to compile that dev branch on 64 bit Ubuntu 20.04 LTS:
Code: Select all
automake --version
automake (GNU automake) 1.16.1
make --version
GNU Make 4.2.1
gcc --version
gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
g++ --version
g++ (Ubuntu 9.3.0-10ubuntu2) 9.3.0
Yeah, I think all my stuff was older than that. I managed to blow up my linux install trying to upgrade so I will have to continue after I reinstall.
Re: UOX3 Linux Building
Posted: Tue Aug 18, 2020 3:41 am
by Xuri
Ouch! ^^;
Re: UOX3 Linux Building
Posted: Sun Sep 06, 2020 3:10 pm
by punt
Just so you know, there was an error in UOX3, that would result in segfaults on 64 bit systems. That has been corrected and will be incorporated in an upcoming update. There also was a linux error for how dictionary lookups where being done, that resulted in some segfaults as well. That also has been corrected and will be included in an upcoming update.
Re: UOX3 Linux Building
Posted: Thu Sep 10, 2020 3:15 am
by Mindless Automaton
Xuri wrote:Ouch! ^^;
Because that wasn't enough of a kick in the sack, one of the HDs appears to have failed also.
Re: UOX3 Linux Building
Posted: Fri Oct 30, 2020 2:24 am
by Mindless Automaton
Mindless Automaton wrote: ↑Thu Sep 10, 2020 3:15 am
Xuri wrote:Ouch! ^^;
Because that wasn't enough of a kick in the sack, one of the HDs appears to have failed also.
Got a linux machine rolling again. Problem is Mint 20 doesn't offer DOSEmu in Synaptic anymore, not that it has anything to do with UOX3.
Anyways, when I get a chance, I will see if I can build UOX3 again.
