kubuntu 14.04 strange error of process of installing.. [SOLVED]

[TempodiBasic]

Hi

I downloaded QB64 1-3 -lnx  and I run in console the installing file...
no problem until the last operation that gave me this error... see attachmen
please some suggestions?
  [ You are not allowed to view this attachment ]  

[johnno56]

I'm curious... You are using Kubuntu 14.04... Is there any reason why you are not using the current 19.04 version? Just curious...

J

[TempodiBasic]

Only because the machine is very old and I have a CD with installing of kubuntu.
The same OS has asked me if I want ajourn to 19.04 and at the first time I answered no because I dunno if 3GB of RAM is enough for the new stable release.

I must see if the Fifi's installer is adjourned to QB64 1.3  32bit, because this old machine that I want to franksteinize is a celeron 1GHrtz with 32bit structure. The OEM system that now declares itself as illegal is Windows 7 professional.

However I must see if this equipment is enough for Ubuntu 19.04!

[SMcNeill]

The versions of g++ which newer versions of Linux comes with, have been altered and updated, just as we alter and update QB64.  Newer versions of g++ now have the -pie switch enabled by default, whereas older versions (like the one with your 14.02 OS) don’t.  The -pie switch basically stops programs from executing if you compile them, and then try to double click on them from the file explorer.  You can still run the compiled programs from the terminal, but double clicking them does nothing much...

To fix this, we started packaging QB64 with the -no-pie switch enabled by default — which fixes the issue for up-to-date versions of g++, but tosses errors like the one you got with older versions.

The fix for you is either:
1) Update your g++ compiler.

Or

2) Remove that switch from the compile line with the setup script.  (And probably in internal/c/makeline_lnx.txt, or whatever its exact name might be.)

[SMcNeill]

In the setup script, you’ll see this:

 echo "Building 'QB64'"
  cp -r ./internal/source/* ./internal/temp/
  cd internal/c
  g++ -no-pie -w qbx.cpp libqb/os/lnx/libqb_setup.o parts/video/font/ttf/os/lnx/src.o parts/core/os/lnx/src.a -lGL -lGLU -lX11 -lpthread -ldl -lrt -D FREEGLUT_STATIC -o ../../qb64

Just remove that -no-pie, and you should build fine without it.  (And probably have no issues running anything either, as -pie probably isn’t a switch for your version of g++.)

EDIT:  Don’t forget the same change in internal/c/makeline_lnx.txt as well.

[TempodiBasic]

Thanks Steve
I'll try your suggestion later,
for now I have learnt that minimum requirements for Ubuntu is CPU 2Ghz dual core (my old HP is lower just of 1Ghz :-) ) while for the other characteristics it is ok.

[TempodiBasic]

Hi Steve
you give me the solution.... following your instructions I have had easy path to the goal!
  [ You are not allowed to view this attachment ]  

About running it is ok with double click on the QB64 executable in its folder.

Feedback for developers of installer for Linux

1.
Without no request by me the Kubuntu 14.04 has installed the local version of OS with Italian names of folders of system, so the link in the Kikoff menu running in this OS are missed because the installer has pointed to Development folder while on my machine there is Sviluppo folder!
But this OS is very flexible and clear so doing right click on Menu Button of Kikoff I got the editor(manager) of Kikoff and I add the link to QB64

2.
the file ico for application in this system has no .ICO extension, so I use Gvenview to save a copy as .PGN that is a compatible extention for file of icon of an application

3.
in the default path for Font in the Option/Display menu  put a path like this

///usr/share/fonts/truetype/freefont/FreeSans.ttf

or

///usr/share/fonts/truetype/freefont/FreeSerif.ttf

and remember to pull down  Row height in pixel (default 21)
or use this that fits well

///usr/share/fonts/truetype/freefont/FreeMono.ttf

if it is common for linux systems the path of fonts.

Now I'm going to try compiling some code... naturally taken from the forum
(be quiet I'll not test the windows DLL calling  :-)  )