QB64 and new Mint install (on a Virtual Machine, not bare metal)

[SMcNeill]

To showcase the issues with QB64 on a fresh version of Mint 19:

The first picture is what we get when we run setup_lnx.sh.  If you look at the TYPE of executable we generate, it's designated as Unknown and not a Program.  We can click on it all day long and it does nothing.  It's a good paperweight eating up space on the drive.

So, we go in and edit the setup script to include the -no-pie switch as others have indicated.  We run it, rebuild qb64, and lo and behold -- it's now actually a program! 

But...

It still doesn't work.  Click it -- nothing.  Double click -- nothing.  Run from terminal -- nothing...

The only way it works is if we run it from the console with command line switches.

*******************

So, to test it out, I write a little PRINT "Hello World" program.  Compile from terminal (./qb64 -x test.bas) -- and once again, it produces an unknown type that might as well be a paperweight.

So into internal/c and change makeline_lnx so that it no includes -no-pie.

Back to terminal.  Recompile test.bas.   Try it out...

NOTHING.  It's still a paperweight.

So change the code, save it again:

Code: QB64: [Select]

1. $CONSOLE:ONLY
2. _DEST _CONSOLE
3. PRINT "Hello World"

Compile. 

Try to double click -- does nothing.

Run it from terminal: It now says, "Hello World".


I don't guess we could REALLY call it broken, since it does work after we alter the code as packaged twice, and while only using the console for our programs...

[STxAxTIC]

For what it's worth, the computer I keep... off site... (fine! its at my parents' house!) Has been running Linux Mint 18.3 for a few months, compiling QB64 stuff day in, day out. It's hosting MegaBot this minute at #qb64. What's so dinged up about V 19?

[SMcNeill]

Part of the problem is with gcc doing an update for newer systems which sets -pie as default.  The guy here does a good explaination of the issue:  https://stackoverflow.com/questions/41398444/gcc-creates-mime-type-application-x-sharedlib-instead-of-application-x-applicati

By default, gcc/ld will produce binaries which set e_type to ET_EXEC, which get detected as application/x-executable. When the command-line option -pie is used, a position-independent executable is created, which may, like shared libraries, be loaded at different addresses and still work. Because this works so much like a shared library, to avoid too many changes to the loader, such binaries get marked as ET_DYN, even though they can be executed directly.

If it is ET_DYN, then mimetype will treat it as a shared library. 

Which explains why it becomes "unknown type" instead of "program type", but I have no idea why the graphic modes are completely broken. 

[SMcNeill]

So as to not pollute the other topic, I'll ask here, in response to Tempodibasic:

...while on my VirtualMachine on my Toshiba notebook I have many trouble to install QB64 on it also following all your good tips... it lasts me to get direct help online from experts like Fifi.
But for now it is a must!
All that I have reached is to get QB64 into Programming folder, but it doesn't run in any way I call it.

What OS are you trying to install QB64 under?  What does the QB64 executable look like when you view properties?  Does it identify itself as a program, a library, or unknown?  Does it work as a command-line compiler from the terminal?

It sounds like your experience with QB64 and Linux closely matches my own.

[luke]

I installed Mint 19 (the Cinnamon version) to test this out. I had no problems installing or running QB64 or the programs it generates, with the exception that the file manager prompted me each time I ran the binaries. Selecting "Make executable and run" works fine. Using the command line to launch things (or F5 inside the IDE) was no trouble at all. I did not modify any of the compiler flags.

The only bug I'm seeing here is with the file manager not correctly recognising an executable binary.

[SMcNeill]

I installed Mint 19 (the Cinnamon version) to test this out. I had no problems installing or running QB64 or the programs it generates, with the exception that the file manager prompted me each time I ran the binaries. Selecting "Make executable and run" works fine. Using the command line to launch things (or F5 inside the IDE) was no trouble at all. I did not modify any of the compiler flags.

The only bug I'm seeing here is with the file manager not correctly recognising an executable binary.

Well, that'll make sorting the glitch out a PITA.  Apparently it works fine on some systems and not hardly at all on others.  I'm thinking it must be a video driver issue of some sort which is keeping OpenGL from working on all systems.  I'll keep digging tomorrow and see what I can uncover.

(And, I imagine if you set the -no-pie flag, it'd produce programs which would run without needing the command line.)

[SMcNeill]

I found the solution to my issue -- maybe this will help somebody else as well:

Virtualbox was popping up a message saying, "running in software mode", at startup.  OpenGL and QB64 doesn't like the software mode, thus shutting down any graphical programs (even the IDE), before they could start.

Digging around the web, I found this solution: https://forums.virtualbox.org/viewtopic.php?t=79486


Solution:  Uninstall Guest Additions that are packaged with the guest

Code: QB64: [Select]

1. sudo apt-get remove virtualbox-guest-utils

Reboot, then install the Guest Additions provided with VirtualBox by clicking Devices > Insert Guest Additions CD Image...

NOTE -- I had to unmount all other drives first, before it'd actually load the image.

Once loaded, I never had to type in anything like the other guy says; auto run popped up to install and I let it do its thing.

And when finished, I rebooted the virtualbox...

Startup this time no longer ran in software mode and QB64 launched the IDE as it should.

-no-pie should still be added to the compiler make lines to produce executables instead of shared libraries (they're even smaller in compile size).

[rcamp48]

what about older systems like the Acer Aspire One NAV450? Is there a problem with them too ??? (Still installing the updates on a 64 bit system). Russ

[FellippeHeitor]

You should be fine with the stable build depending on the distro you've chosen to install. All of the above refers to the beta development version on a virtual machine, so it doesn't apply in general.

[SMcNeill]

You should be fine with the stable build depending on the distro you've chosen to install. All of the above refers to the beta development version on a virtual machine, so it doesn't apply in general.

All the above applied to both the stable and development build for me in a virtual machine.  OpenGL simply doesn't work properly at all, unless it's running with hardware drivers.  If your VM runs in software mode, you're stuck with console only programs.

And regardless of build, it doesn't produce executables with the latest versions of g++ unless -no-pie is added to the makeline.  You can run the compiled programs from terminal, but not by clicking on them, as they're registered as a shared library and not an executable.

[FellippeHeitor]

No alarm. Developers are on to it.

[Fifi]

Hi SMcNeil,

Please give a try to my multi lingual installation bash script that installs QB64 and both InForm and vWATCH all together and solves the problem of the gcc setting (the -no-pie option) accordingly to the newest Linux distribution settings.

It works both on baremetal and VMs (I mainly use the VMware Fusion product on my iMac 27 but also VirtualBox and Parallels).

My script displays its messages accordingly to your language desktop setting (by default in English, as well as in French, German, Italian, Russian and, thanx to Fellippe Heitor in Portuguese) and is usable on many different Linux distros (Arch, Bridge, CentOS, Chakra, Debian, Eos, Fedora, LMDE, Manjaro, Mint, Neon, Q4OS, Ubuntu and its derivatives such as Lubuntu and Kubuntu, Zorin, etc.).

Further, the script creates convenient starters icons on your desktop as well as capabilities to start QB64 like any de facto standard compiler (e.g gcc) from any terminal session whitout being obliged to be inside the folder where it's installed using a command line like this:

Code: QB64: [Select]

1. qb64 -x /mysourcefolder/myprogram.bas -o /mydestinationfolder/myprogram

Furher, the script allows to also cleany uninstall QB64, Inform and vWATCH.

You can download this script on my dedicated QB64 web page: http://www.as2.com.

Hope this helps.

Best regards.
Fifi