Making QB64 work on Linux
#1
Lightbulb 
Hello.  Used QB64 since v0.86 approximately, was on the oldest of the forums for a while and contributed a few programs.  Used v0.98 a lot but turned off by its bugginess and the inability to play ancient tracker modules.  I created a few multimedia apps but not patient enough to do games which is what I want to do the most.  I like creating and listening to electronic music on my computer.

TL;DR

While I have an Internet connection for a short time, after a pause of eight years, decided to test "Phoenix Edition" on various Linux distros.  Tried so far with Fedora (v35 GNOME and v36 MATE and XFCE), Solus (MATE) and Void ("glibc" XFCE).  One will need to do a bit of investigating so it works properly on Solus.  Do not pick "musl" branch for Void because it will not work; it's 64-bit only and might be counterproductive to use a programming system like this.  AV Linux is installed on another external disk but might not last long because I cannot use the touchpad, cannot change a lot of things because I purposely run it live with persistence.  Tried many other distros like Bunsen Labs Lithium, Linux Mint, Mageia, OpenSUSE "Tumbleweed", Salix, usually failed because they insisted being installed only to an internal hard drive.  Also had Ubuntu Studio v22.04 but my computer isn't powerful enough for it.  I have Manjaro installed on hard disk and probably QB64 works there too (and for Arch) but I picked a package for some other BASIC.  That one might be temporary, though, I don't like the desktop environment I chose for it (same as for Ubuntu Studio).

DISCLAIMER: I don't do "VirtualBox" or alike, it doesn't work on my computer.  It might affect what could be done with QB64.

This programming system works without problems on Porteus, at least on my side.  It only requires the download of "05-devel.xzm".

Info about Porteus GNU/Linux here:

https://distrowatch.com/table.php?distribution=porteus

(linked that page because the "standard" site is not "https" and some people are touchy about that)

Note this will not work on Slackware or whatever else is based on it!  Do not try it!!!  I am able to list precisely the shared libraries required for "qb64" and any ELF executable created with this programming system.  Used "readelf" program.

Code: (Select All)
libGL.so.1
libGLU.so.1
libX11.so.6
libc.so.6
libgcc_s.so.1
libm.so.6
libstdc++.so.6

However on eg. Slackware you will also need the header files, at least those that correspond to "Freeglut", "libX11" and the font-handling libraries.  I'm sorry, I don't have any information about that.  I only wanted to report a successful use of QB64 on a distro less known than Fedora, the 'untus and others.

BTW note to the developers.  This is to cause a QB64-created program to be able to report runtime errors.  You should consider changing the "MessageBox" code so on Linux, it searches for "xmessage" and if it doesn't find it, use "zenity" instead.  Some distros don't come with "xmessage" and no easy way to acquire it, Solus is one of them.  On Fedora the "xmessage" dialog might look strange and after that, it complains on terminal about a font missing "charsets".  I made the change to "libqb.cpp" but I'm not going to post the portion with changes unless I'm asked for it.

One more thing, sorry if I keep writing.  A BMP file could be loaded successfully but each time, it errors on the terminal about 16-bit files not supported.  "_DEFLATE" and "_INFLATE" do not work, but "zlib" library seems to exist.  Thank you for implementing "SHELL", this is very helpful and before that I had to write my own routine which was clunky.
Reply
#2
Hey, that is good stuff.  Thanks for taking the time to test those things and write about it!
Reply
#3
Lightbulb 
https://distrowatch.com/table.php?distribution=alt

Currently checking out ALT Linux. Avoided the "standard" ISO because I abhor KDE Plasma, and also stayed away from the "simply" version. Instead picked the "nightly build" option which gives me MATE desktop environment, the one I could tolerate best. With the "standard" package while booting must be quick about pressing [F2] I guess during GRUB; otherwise it fires up in Russian. The live-ISO "nightly build" I have clearly gives a menu option to change the system language and keyboard config out of Russian. This setting is remembered when the system is installed to hard disk or to external USB disk.

QB64 setup script incorrectly detects this distro as "Fedora" at the end because this distro is RPM-based.  ALT Linux is an independent distro that might have been based on one of the original Red Hat's descendants way back in the late 1990's and is run by a Russian company.  There is no "yum" and I have yet to discover what is the terminal-line installer/remover. Although there are utilities to resolve Fedora RPM's for this described OS, it's not recommended to use them especially if the package is available and recent only for ALT. This could be a pain building QB64 or anything else because the root password is separated from the user's, and sometimes the user isn't recognized for very important "sudo" command.

The "nightly build" is called "Sisyphus unstable" which might be unsettling, but this is for people who want cutting edge, as well as for those like me who don't like the "standard" long-term service (LTS) offering.

One more thing: do not attempt to copy from one "ext4" partition to the user's partition for this distro! The user permissions are going to be messed up for the copied files. Copying from Windows partitions should be OK but tested it only from external USB FAT32 partition.

In "Synaptics Package Manager" must select the following:

"gcc", "Dependency package for GNU C compiler"
"gcc-c++","Dependency package for GNU C++ compiler"
"libGLU","mesa libGLU runtime library"
"libGLU-devel","mesa libGLU development package"
"libX11","X11 Library"
"libX11-devel","X11 libraries and header files"
"libfreetype","A free and portable font rendering engine"
"libfreetype-devel","Header files and library for development with Freetype2"
"libalsa-devel","Development environment for Advanced Linux Sound Architecture (ALSA)"

That last one I had to install after C++ compilation failed to find "alsa.o" for B+'s "oh" interpreter. :/

Note "X11" it's a capital "X"!

might also have to select this:
"gcc-common"
"gcc-c++-common"

Might want to change the repository servers to a location away from Russia and near you...

EDIT: I was on ALT Linux but when I first tried to edit this Firefox hung which sucked and it's the first thing that happened to me! Sadly the choices of web browser are poor. This was v103 the latest of that program I'd rather not use.
Reply
#4
Lightbulb 
I just installed Debian Bullseye v11. Might want to make a change to "setup_lnx.sh" script to check if "make" utility is installed, because I had to "apt-get" that program manually.
Reply
#5
well i am not sure what kind of complications you have with all
this distros ..i have it too and that sucks 
so i install Q4OS Trinity gemini 4.8 64bit.. and work but is not very fast ...
dual boot with win7 64bit
LXLE is better..at least on my computer
Reply
#6
(08-08-2022, 07:48 AM)mnrvovrfc Wrote: I just installed Debian Bullseye v11. Might want to make a change to "setup_lnx.sh" script to check if "make" utility is installed, because I had to "apt-get" that program manually.

There's a bug card for this, sadly the script does check for "make" but the logic accepts packages with "make" in the middle of the name, so it thinks it's installed when it actually found some other package. Either way, it's on my list of things to do, it's not at the top though. The biggest problem is doing the testing after I fix it, that's a very slow process.

Maybe I can automate some of the testing via using containers for these distros, we only really support 4 options and all of them except Void Linux definitely have official container images (we're currently using Ubuntu for the automated pipeline, so that's actually already tested). I'll have to look into that, that would be pretty nice.

As for Alt Linux or any other distros, generally speaking the more obscure you get the more you're on your own.
setup_lnx.sh
basically supports a few of the most popular distros and I think it's probably best that way. We could consider adding one or two more if they are quite popular, but generally I'd rather not since testing and maintaining it is hard.
Reply
#7
Just installed (again) Manjaro KDE, but from the "August 2022" ISO available on their website at the time of this writing. Annoying that one as well as Debian leave out "make" utility! Meanwhile "freeglut" and other things need not be acquired. In my case since I install Wine as one of the first things after full system update...

Update about ALT Linux "unstable" (with MATE desktop environment at my end): updating it really sucked, didn't really wreck my system but it starts for over five minutes, doesn't enable "swap" partition. Tried updating kernel but told me I already had the "latest" one, tried to force it telling it where was the "swap". The same thing, over five minutes from boot to log-in prompt which is unacceptable. They'd be in trouble if that happened also with the "standard" ISO with KDE Plasma and Russian language...
Reply
#8
install Q4OS Trinity gemini 4.8 64bit..

maybe is ugly ..but work and wine work well
Reply
#9
Lightbulb 
https://www.devuan.org/

Devuan - this is like Debian but a bit lame. They make a big deal about not carrying "systemd". If you're not sure, especially if your wireless connection could work on a 10-year-old PC then don't try it!

I created a 64GB partition on the slow-as-heck HDD of my ageing computer for it. I chose the "desktop" ISO which is almost 4GB in size. It might not be different in "net-install" or "live-desktop" mode. I do not recommend "server" mode unless you hate XFCE desktop environment. If you want the Windows-like KDE Plasma then the big ISO is the only way to go.

Like the rest of the Debian/Ubuntu family, Devuan lags far behind fierce competitors like Fedora and Manjaro (but with "systemd") with "cutting edge" Linux kernel. I updated Fedora XFCE a short time ago and got v5.19 of the kernel, while Devuan is still on v5.10. The latest Debian release was supposed to up the ante to a release which stopped being the latest this month. :/

One thing that sucks is that if you choose to give a "root" password, this OS could refuse to allow a "regular" user to use "sudo". Must add a text file (become superuser and use "nano" terminal app) into "/etc/sudoers.d" to fix it. Moreover, this distro might keep trying to get files from a "cdrom" or "dvd" which doesn't exist. To fix this, as superuser edit "/etc/apt/sources.list" and delete whatever line has "cdrom" or "dvd" on it.

For this OS, to install QB64 must first put in "g++" and "make", then make a change to "setup_lnx.sh" file to force "DISTRO=debian" after it checked incorrectly for which distro, and before the "if" statements controlling the installation of packages. EDIT: noticed inside "setup_lnx.sh" that "make" is accounted for.

Definitely it's much easier to install on Ubuntu than on this other garbage.
Reply
#10
Exclamation 
I strongly recommend downloading the latest version of QB64PE only from the standard place which is:

https://staging.qb64phoenix.com/forumdisplay.php?fid=47

Only from there! In the past wacky things were done to help confuse others especially the ones hopping Linux distros. For example there is an AUR package for the "dot-rip" version from late last year, the last release never updated! It's not going to have the few commands added or being added to QB64PE.

Packages for a given Linux distro work OK for Freebasic, for example because it works well for the Freebasic team at one end, and for the users at the other end caring about it. It could be difficult to build and/or to hunt down the dependencies if the ordinary "tarball" were taken. No problem for Windows, just unpack to a directory not protected by M$ and start right away, just like QB64PE.

Somebody might have the crazy idea of packaging QB64PE into a DEB or RPM or something like that. Then it becomes his/her responsibility to update that package, because nobody else is going to volunteer for it! I might be wrong, but a "standard distro package" is just not a good idea. QB64PE was meant to work on any Linux distro but it's more complicated than it seems. All distros are supposed to have "gcc" installed but it doesn't mean the C++ compiler is included, which is a shame. The user has to be prepared for rare events like I've went through with Solus (don't use this particular distro anymore).
Reply




Users browsing this thread: 5 Guest(s)