Compiling proquake on Debian Jessie 8 64 bit?

[Baker]

If it runs in Quakespasm, it would run in ProQuake.

[SpecialBomb]

If it runs in Quakespasm, it would run in ProQuake.

True, but I still really want to compile it.

[Baker]

True, but I still really want to compile it.

Spike told you about the difficult and time consuming road to doing that.

All you have to do is get started.

[vibok]

Try asking on debian forums too.

Error message would be helpful, yes. Post it.

There is a way to run 32bit programs on 64bit linux, though it's not as easy as on windows. Try googling it. Maybe 32bit version will compile successfully. Running 32bit version should be much easier than to port the whole program to 64bit.

[SpecialBomb]

The source does come precompiled with the executable ELF files, and when I run glquake_glx:

./glquake_glx: error while loading shared libraries: libXxf86dga.so.1: cannot open shared object file: No such file or directory

I have no idea what libraries this thing needs, so any info would help.

[Baker]

libXxf86dga.so.1

I'm not a Linux expert ...

But it looks very much like it is an X Windows library.

Although, I don't know that this information is going to help very much, but it appears you've gotten it to compile, so congrats!

(Sadly, unlike Quakeworld, original NetQuake has no client-server separation. A pure Quakeworld server wouldn't the window systeming interface library.)

[SpecialBomb]

Baker.

So, the "ELF files" in my previous post are the same thing as executibles for windows, but for unix/linux. They are compiled applications with library links.

The "libXxf86dga.so.1" library is referencing X, which is a window manager server for unix that is on almost any unix distro with a GUI on it.

When I downloaded the source from proquake, I got the version for linux, as explicitly stated on the download link here on the main page. It comes with precompiled ELF files, meaning that they are the actual programs I run to start proquake. However, since I am missing many 32 bit libraries, it doesn't want to work.

This has nothing to do with Microsoft Windows, thankfully.

So, in short, I didn't compile it, and a free very basic unix lesson.

[Baker]

My bad. I didn't read your whole post. I saw an error message and focused like a laser on that and it dominated my attention.

Linux is its own special kind of ... well it's a cluster-fuck compared to other operating systems ... your best chance of success is following Spike's post and compiling yourself.

You are then assured of having the correct dependencies/versions/etc.

I hate Microsoft Windows, by the way. But if you were using Windows, your life would be easy ... it has a "Windows On Windows" subsystem that runs 32-bit apps in 64-bit. The Mac can run 32-bit on 64-bit and like Windows it is just a double-click.

Hating Windows doesn't make Linux a decent operating system --- believe me I know. I would love Linux to not fucking suck balls, I'd switch immediately. Except Linux sucks balls. My Mac, meanwhile, has all the advantages of Unix and none of the Linux horseshit problems because it "just works".

https://itvision.altervista.org/why....p.current.html

I'm not trying to crap on Linux, I'm not real fond of Apple either. Windows is the best operating system, and I don't want it to be but it is. Windows > times better than a Mac all things considered. A Mac > 20 times better than Linux in a landslide. On a Mac everything works, it's all painless and using the Unix terminal you never have any surprises, but can do anything you could do on Linux. Plus the file manager system is 1000 times better and the operating system curb stomps Linux very, very badly.

/I'm just providing information.

Anyway, eventually you'll know the right thing to do. It's the obvious one. You will probably WINE about it, but you won't have to pull your hair out to make it work.

[SpecialBomb]

Keep in mind, I don't hate Windows, I just don't enjoy using it, and find it fairly tedious when it comes to development. That, and it also takes forever to boot despite having only a few standard programs and few extra background processes. Linux doesn't do this becuase it is much more barebones and doesn't need to load a million things.

To counter your argument over OSX, OSX is highly specific to a company that has high standards, which generally means that programs made for OSX will work on OSX, because there is only one OSX. The linux kernel is used in thousands of distributions, and it is obvious that not everything will work out in the end. That is a sacrifice you have to make, that not everything will work. I find it worth this sacrifice.

Yes, there are many issues wrong with the current desktop experience with linux. That is unavoidable, but if you can keep things stable, it's pretty stable. Fuck, the laptop experience is even worse. I have a friend that uses Linux on his laptop, which I can understand, but there have been tons of issues he has asked me about. No brightness control, cooling fan won't work, cursor won't appear, a million other things. It's not perfect, however, the laptop issues have to do more with proprietary control drivers that are only available in Windows, and no one has ported them to the linux kernel yet.

Also, I discovered that it's because I am simply missing some 32 bit libraries, which are easily obtained, I am just too lazy to figure it out (plus I can't anyway, because I suck).

Note that there is no difference between the functionality of windows being able to run 32 bit programs on a 64 bit system than on linux. .DLL files are essentially the same things a libraries, but they are for windows. There are many cases where a precompiled program on windows, whether it is 64 or 32 bit, does not work because it does not have the .DLL files with it. Mac has it easier however, as a lot of the libraries there are standardized. So, essentially, windows saying it can't find a dll file is the same thing as linux saying it can't find a library file, it's just a bit different.

[vibok]

If you have gui in your debian, you should have X window system installed too. Try finding where all your .so libraries are stored, and try searching for a file named simularly to "libXxf86dga.so.1". Maybe try digging into your package manager, name for X metapackage is "xorg", see what you have installed. After you find the current name, maybe you can just create a soft or hard link, and maybe it'll just magically work.

glquake_glx was built in 2008, if data on the file itself doesn't lie. A lot could have changed since then.

Have you tried recompiling yet? Also, when you recompile, you'll have to delete all .o files first, just in case. Those are object files, they are like temporary file during compilation. You should be able to do that by typing "make clean".

You probably should start compiling all the way from "autoconf" to "./configure" to "make", or whatever you have there, read INSTALL file. Read all uppercase files, those are documentation.

Tell if anything goes wrong or anything goes right. All error messages.

[SpecialBomb]

Okay, so I got everything, compiled, no more library issues, and I get this:

glquake_glx-sys_dosa.o: In function `Sys_LowFPPrecision':
/home/quentin/Documents/pqsrc-modified/pqsrc-modified/sys_dosa.s:49: multiple definition of `Sys_LowFPPrecision'
glquake_glx-sys_linux.o:/home/quentin/Documents/pqsrc-modified/pqsrc-modified/sys_linux.c:409: first defined here
glquake_glx-sys_dosa.o: In function `Sys_HighFPPrecision':
/home/quentin/Documents/pqsrc-modified/pqsrc-modified/sys_dosa.s:55: multiple definition of `Sys_HighFPPrecision'
glquake_glx-sys_linux.o:/home/quentin/Documents/pqsrc-modified/pqsrc-modified/sys_linux.c:405: first defined here

Sounds weird, duplicated function maybe? I have not developed on C yet, but that's my best guess.

[vibok]

More like "tried to compile" than "compiled".

Why the hell sys_dosa.s is active, it's for dos. Your version is sys_linux.c. Maybe it's shared though, dunno.

Try temporarily moving all .s away? Shouldn't work, but who knows.

What exactly you do to compile? Maybe you should do "make linux" or something instead of just "make". Or do "./configure --something" instead of "./configure".

Try deleting Sys_LowFPPrecision and Sys_HighFPPrecision in sys_linux.c, they're empty anyway.

[SpecialBomb]

How can I find the different make targets? for some reason, the INSTALL file doesn't specify.

Also, refuses to compile without sys_dosa.s. I don't know why.

EDIT

Found what targets I can make, glquake_glx, quake_x11, and unixded. Nothing works except unixded, since it doesn't need all of those fancy graphics libraries to compile.

I looked at both of the sys_dosa.s and sys_linux.c and found these:

THESE ARE NOT THE FULL FILES

sys_linux.c

#if !id386
void Sys_HighFPPrecision (void)
{
}

void Sys_LowFPPrecision (void)
{
}
#endif

sys_dosa.s

.globl C(Sys_LowFPPrecision)
C(Sys_LowFPPrecision):
        fldcw   single_cw

        ret

.globl C(Sys_HighFPPrecision)
C(Sys_HighFPPrecision):
        fldcw   full_cw

        ret

Now, what confuses me is the purpose of sys_dosa.s, as it says it references DOS routines, meaning that it would have no reason to really be here. However, I may be wrong since I don't know what I am doing.

[vibok]

>How can I find the different make targets? for some reason, the INSTALL file doesn't specify.
I just open them and search for ".PHONY". They are probably mostly useless, so don't care too much.

> Also, refuses to compile without sys_dosa.s. I don't know why.
okay, it was just a guess.

Try temporarily removing Sys_LowFPPrecision and Sys_HighFPPrecision in sys_linux.c , I'm curious what it will complain about next.

You really should ask it on some linux or debian forums. I'm on windows, so I can't really try myself.

[SpecialBomb]

I don't know at this point, I think I may just give up.