UOX3 Linux Building

[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.

[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.

[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.

[Mindless Automaton]

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

[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.

[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# 

[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

Edit: Could you also try to update your versions of gcc/g++/make/automake, and see if that makes a difference?

[Mindless Automaton]

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

[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

[Mindless Automaton]

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.

[Xuri]

Ouch! ^^;

[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.

[Mindless Automaton]

Ouch! ^^;

Because that wasn't enough of a kick in the sack, one of the HDs appears to have failed also.

[Mindless Automaton]

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.