Ya that's right, on sparc haha. I got the latest git and compiled mvdsv without any issues, put the pak files in, extracted ktx etc.

I couldn't find out how to compile a ktx qwprogs.so maybe because they don't want you to but I found the .qvm here: http://build.qw-dev.net/ktx/os_independent/latest/

Updated the ktx/mvdsv.cfg accordingly to use the .qvm but when I run the server this is what happens:

$ ./port1
Added packfile ./id1/pak0.pak (339 files)
Added packfile ./id1/pak1.pak (85 files)
Port: 28001
IP address 127.0.1.1:28001
UDP Initialized
Initialized default mod messages.
Total: 60 messages.
32.0 megabyte heap
MVDSV 0.30-SVN, build 1013 (l)
Build date: May 19 2011, 13:01:12

MVDSV Project home page: http://mvdsv.qw-dev.net

======== QuakeWorld Initialized ========
execing server.cfg
execing mvdsv.cfg
execing ktx.cfg
execing pwd.cfg
execing vip_ip.cfg
execing listip.cfg
Logging rcon to ./rcon_28001_0000.log
Logging players to ./player_28001_0000.log
execing port1.cfg
VM_Load: "qwprogs"
Bus error

Also I tried using mvdsv_0.29-sources.zip with the same error.

I wouldn't be surprised if none of the developers even have a sparc machine so the fact that it compiled in the first place was amazing. With that said, any ideas on what is wrong or how to fix it? Thanks a bunch.

What's wrong so far is the QVM.
I've just realized that my q3asm is not compiling it properly. I will try to fix that soon.

If it's a server and you can install buildbot on it, we could add it to the supported OSes

Oh, and to compile ktx:

./configure
make dl

done

Once my internet connection is up and running fully again and after I mod the CPU and case fans to be silent ones instead of the default teleco grade I would gladly put buildbot on it

As for compiling ktx... woops I never did! I just got the mvdsv_0.29-ktx_1.36-server_pack-glibc_2.3.5.tgz and compiled my own mvdsv heh. I'll try compiling ktx right now :p

Well I compiled a qwprogs.so but I still got the same error so it's likely a code portability issue relating to sparc

$ file ktx/qwprogs.so
ktx/qwprogs.so: ELF 32-bit MSB shared object, SPARC32PLUS, V8+ Required, version 1 (SYSV), dynamically linked, not stripped

I tried doing 'make vm' but it errored out after complaining that "DQ3_VM" is missing.

Actually I just noticed the output is slightly different as it gets just alittle bit closer to starting:

./mvdsv -mem 64 -game ktx
Added packfile ./id1/pak0.pak (339 files)
Added packfile ./id1/pak1.pak (85 files)
IP address 127.0.1.1:27500
UDP Initialized
Initialized default mod messages.
Total: 60 messages.
64.0 megabyte heap
MVDSV 0.30-SVN, build 1013 (l)
Build date: May 19 2011, 13:01:12

MVDSV Project home page: http://mvdsv.qw-dev.net

======== QuakeWorld Initialized ========
execing server.cfg
execing mvdsv.cfg
execing ktx.cfg
execing pwd.cfg
execing vip_ip.cfg
execing listip.cfg
VM_Load: "qwprogs"
4 on 4 settings enabled
execing configs/usermodes/default.cfg
execing configs/usermodes/4on4/default.cfg

VM_Load: "qwprogs"
Bus error

I haven't looked at the code really, but first thought is endianness problem?
Deurk/qqshka??

I don't think the problem is going to be solved by guessing here, some serverside developer is going to need to have access to sparc system and debug the problem there. Unfortunately qqshka's been gone for over a month now, I'm sure he would know what to do, if anything.

Also, why is this issue reported here instead of the proper place, the KTX and/or MVDSV issues tracker?

I don't see how your post would help in any way at all though. Of course qqshka is one of the most likely to know since he is the main developer behind ktx/mvdsv. I gave a hint of something that might be (one of) the problem(s) since sparc is mostly big endian..

My post was not meant to help, I have no solution for the "bus error" problem. What I'm trying to say, if you want problems fixed, report them at the proper place, which in this case is the tracker over at KTX or MVDSV project site. You don't even have to register to do so.

EDIT: Oh and in this case, provide the devs the access to a sparc system too.

EDIT2: Like so http://qw-dev.net/issues/396, continue providing more info there.

23:20:46 @VVD | mvdsv + ktx compiled as native never work
23:21:19 @VVD | I made port for sparc32/64 and only .qvm ktx work on it

So with that said, anyone have a working .qvm since the one I linked to and tried was broken according to deurk

Noone uses .qvm because it makes the CPU usage of the MVDSV multiplied by a few times, that's also the reason we haven't released any builds with .qvm either.

As for the broken .qvm on qw-dev, deurk said he is trying to fix it at some point so I'd wait for that. At some point (few years earlier) I was able to build .qvms but my main shell got changed to a considerably better one and DQ3_VM (and some other shit) was lost in the process, so I am not able to compile .qvms at the moment.

Alright I will wait patiently

Not to necro this hard but I have a much better internet connection now. If any of you are still interested in this (should be a fun programming challenge I bet) then let me know. I can put debian or freebsd on it so whichever you prefer to work in. You can contact me on quakenet as user venim in #sta

Ah.
U are use Linux on Sparc, not SunOS...

Do u want to run mvdsv with native ktx (*.so) on it?

A bit of thread necromancy here.

I see the same issue (terminate on bus error) with mvdsv+ktx running under Raspbian on a Raspberry Pi model B.

mvdsv works fine with the original qwprogs.dat, or the one from the excoop mod. So this is an issue either with the ktx progs specifically, or with natively compiled progs in general. Is there some other mod that I could easily compile Raspbian/ARM-native progs for to check it out?

I'll post an issue to qw-dev if that's a good thing to do, but it seems like the ktx issue tracker is abandoned and colonized by spammers.

I see that this issue was previously rejected from the mvdsv tracker, but maybe it's not an mvdsv issue? (And maybe the Pi is slightly more interesting for server-building folks than SPARC?)


Anyway... yeah. FWIW.