Current automated linux installer ...

[ghettopia]

Is there a current linux installer for the latest version? I found the RPM for 97.06 and though it seems to run fine I can't get the default world file to work in it.

On my windows machine (running 98-2.8h) I just dumped the world file into the shared directory and it worked great. On the linux machine I did the same and though it appears to load it flies right past "Loading world" and starts up with no doors or decorations in place. Am I missing something? I'm also getting a lot of this stuff when I start uox3 on the linux machine:

| WARNING: Dictionary Reference 1118 not found in "/usr/share/uox3/dictionaries/dictionary.ZRO"
| WARNING: Dictionary Reference 1117 not found in "/usr/share/uox3/dictionaries/dictionary.ZRO"

Any ideas?

[Xuri]

97.06 is unfortunately horribly out of date, and no, there is no linux installer for the current verrsion :/ So if you want a current linux version you'll have to download the source from cvs and compile it manually.

[Fresshness]

Alternativly, you could install vmware for linux and run UOX3 for windows on your LINUX

however, I wouldn't recommend it. As I'm too going to (attempt to) switch to UOX3 for linux in a near future, I would like to see a up-to-date linux distribution of UOX3.

[Fish]

UOX3 0.98-3.0b can not be compiled under Linux (and other Unix-Like systems) without many modifications in the code.
Recent versions use Windows specific includes (like winsock2.h) that work differently than POSIX equivalents.
Some parts of the code should be completely rewrited.

Moreover, UOX3 miss a file called "configure.in" to successfully run autoconf/automake to write the Makefile needed for Linux compilation (with autogen.sh).
This required file can be found in the old UOX3 CVS in the uox3 directory.

[giwo]

UOX3 Can be compiled under linux.

It has been done, and I am sure it will be done again in the future. If I used Linux, I'd do it myself.

I currently have a fully working make script for mingw32 (the Win32 version of GCC).

As far as networking (Winsock2). There's been no major changes to the networking code in over a year now. And Winsock2 is only used on the Windows compile, not under a Linux evironment (for obvious reasons).

Any configure.in out there for UOX3 would be out of date. Thus one would have to do what I had to do for the mingw32 makefile, and that is write it yourself.

[Fish]

I tried some days ago. Look at the log.

This log is about UOX3 0.98-3.0b with the missing configure.in, GCC 3.3, and Mozilla 1.7.8 for JavaScript.
I am no longer using Linux, so it is Mac OS X 10.3 (with XCode 1.5), but it work the same.

[giwo]

Open socket_interface.h line 24, change

Code: Select all

#if defined(__unix__)

to

Code: Select all

#if UOX_PLATFORM != PLATFORM_WIN32

As for malloc.h, no clue what the linux version of it is, or if linux even uses that, so you'd need to see what is required to get that to include.

The CConsole errors could take some more work to fix.

[Fish]

Code: Select all

helium:~/Desktop/uox David$ make
source='ai.cpp' object='ai.o' libtool=no \
depfile='.deps/ai.Po' tmpdepfile='.deps/ai.TPo' \
depmode=gcc3 /bin/sh ./depcomp \
g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"uox3\" -DVERSION=\"0.97\"  -I. -I.     -O2 -I./mozilla/js/src -c -o ai.o `test -f 'ai.cpp' || echo './'`ai.cpp
In file included from Platform.h:130,
                 from Prerequisites.h:9,
                 from uox3.h:29,
                 from ai.cpp:18:
uoxlinux.h:4:20: malloc.h: No such file or directory
In file included from UOXStdHeaders.h:95,
                 from Prerequisites.h:59,
                 from uox3.h:29,
                 from ai.cpp:18:
socket_interface.h:8:1: unterminated #ifndef
In file included from uox3.h:58,
                 from ai.cpp:18:
cConsole.h:46: error: `UOX::CConsole& UOX::CConsole::operator<<(const size_t&)' 
   and `UOX::CConsole& UOX::CConsole::operator<<(const UI32&)' cannot be 
   overloaded
make: *** [ai.o] Error 1
helium:~/Desktop/uox David$

[giwo]

Unterminated #ifndef means you either 1) Added an extra #if, rather than replacing that one, or 2) Removed an #endif.

It compiles just fine here, and an unterminated #ifndef wouldn't compile even on Win32.

[giwo]

I checked some standard Linux setups, and you should have malloc.h, since you don't seem to, try the subdirectories <linux/malloc.h>

[giwo]

As another thought, you might try gcc 3.4+, as the mingw I used to compile it runs gcc core 3.4.2

[Fish]

I removed the entire if, but I forgotten a thing. This is not an important problem.

This time, I remplaced "malloc.h" by " stdlib.h".

Code: Select all

helium:~/Desktop/uox David$ make
source='ai.cpp' object='ai.o' libtool=no \
depfile='.deps/ai.Po' tmpdepfile='.deps/ai.TPo' \
depmode=gcc3 /bin/sh ./depcomp \
g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"uox3\" -DVERSION=\"0.97\"  -I. -I.     -O2 -I./mozilla/js/src -c -o ai.o `test -f 'ai.cpp' || echo './'`ai.cpp
In file included from UOXStdHeaders.h:95,
                 from Prerequisites.h:59,
                 from uox3.h:29,
                 from ai.cpp:18:
socket_interface.h:8:1: unterminated #ifndef
In file included from uox3.h:58,
                 from ai.cpp:18:
cConsole.h:46: error: `UOX::CConsole& UOX::CConsole::operator<<(const size_t&)' 
   and `UOX::CConsole& UOX::CConsole::operator<<(const UI32&)' cannot be 
   overloaded
make: *** [ai.o] Error 1
helium:~/Desktop/uox David$ 

I can not update GCC manually with Mac OS X, Apple use a custom GCC version. But I will upgrade my version to the new Mac OS X 10.4 with GCC 4.0 (XCode 2.0).
I have Solaris 9 and NetBSD 2.0.2 with newer GCC version, but they are installed on slower computers (SPARCstation 4 & 5).

[xir]

The uoxlinux.h file should really be removed. The malloc.h file has long been deprecated. ANSI C defines malloc within the stdlib.h header so one should include <cstdlib> instead. I doubt that malloc is even used in the whole project. Also string.h should be replaced with the proper C++ <cstdlib> so it belongs in the proper namespace.
I got uox3 compiled in linux just this morning so it def works (on gentoo anyway)

[giwo]

Hey there xir.

Good to have someone who actually knows 2 bits about linux around.

[giwo]

Just running on a Mac platform you are likely to have a few issues.

This is due to some of our old #ifdefs only looking for unix or not unix, they don't bother to see if it's apple or not. Some of the more recent updates make use of a check to see if it's an apple platform, and thus why you don't have too many issues.

I would wager a guess that by fixing the rest of the unix checks, we would by default fix the CConsole problem as well.

[Fish]

Mac OS X 10.3 use an unmodified FreeBSD 4.8 system, so it is normaly recognized as an UNIX, like NetBSD, OpenBSD, FreeBSD, Solaris, Linux...
All POSIX programs works without any problem.

[giwo]

*shrug*

All I can say is it wasn't using the standard __unix__ define, else the winsock problem wouldn't have shown up at all.

Regardless, I would be interested in hearing how it works if/when you get it up and running, as well as what troubles you run into with gcc 4.0.

[Sydius]

Wouldn’t the little/big endian thing pose an issue on Macs?

I am probably just making myself sound stupid, but I think there might be a few issues with it, especially in loading files and perhaps networking.

[lingo]

Yes, you are absolutely right. endian and 64 bits (G5) is going to be a problem, both file loading and networking.

The endian issue on the network part is easy, There are host-to-network order and network-to-host order conversion functions in Winsocks and BSD sockets, You just have to apply it everywhere for short and long integer. byte and ieee floating point just works.

I find a library, actually just 2 files, http://www.poshlib.org. It tackles endian, 64 bits, and file reading/writing issues. uox3's 'UI32' type does not really works, unsigned long integer won't be 32 bits in 64 bits architecture. I think it a assumption from x286 days, with those 'far' 'near' pointer types.

[giwo]

Quite right.... I completely forgot about the processor difference between Macs and PC's *shrug*

Happily that problem will soon be a thing of the past.