qb64 0.8.2 - Compilation problem on Linux.

[Fifi]

Hello,

I don't know if it's the new way to create qb64 (using a make file) but there is kind of a problem on Linux.

Yes, both the qb64 executable itself and the executable it creates can't be started anymore with a double click on their relevant file icon.

You still can launch qb64 with the command "./qb64" (when you're in its folder), but there was not this problem with the 2.0.2 nor with any other previous releases.

Question: just to make a test, is it still possible to compile QB64 Phoenix Edition with the method of the previous 2.0.2 setup_lnx.sh bash script?

If yes, what are the modifications (if any) to make to that previous bash script to successfully compile qb64 0.8.2 ?

Another "glitch": if you place qb64 into a folder with a name containing a space (e.g. "/home/me/qb64 official"), then the run_qb64.sh bash script generated by the setup_lnx.sh bash script will not work.

TIA
Cheers.
Fifi

[DSMan195276]

Yes, both the qb64 executable itself and the executable it creates can't be started anymore with a double click on their relevant file icon.

You still can launch qb64 with the command "./qb64" (when you're in its folder), but there was not this problem with the 2.0.2 nor with any other previous releases.

That's quite odd, I'm not really sure what to make of that. Do you know what the last version this worked in was? In particular did it start appearing in v0.7.0? The only thing I can think of is if the file isn't marked executable, but you shouldn't be able to run it via the command line either if that's the case.

I guess to clarify - by "file icon" do you mean the menu entry, or the icon when viewed in the file browser?

Question: just to make a test, is it still possible to compile QB64 Phoenix Edition with the method of the previous 2.0.2 setup_lnx.sh bash script?

No, all the previous build logic is gone. In v0.8.2 you might be able to get it to work if you put the various old build files back in place, but probably not.

Another "glitch": if you place qb64 into a folder with a name containing a space (e.g. "/home/me/qb64 official"), then the run_qb64.sh bash script generated by the setup_lnx.sh bash script will not work.

Good catch, yeah that's a bug, it looks like it's missing some quotes. Quite strange that you're only finding it now, that's probably a decade old bug

[Coolman]

note that the dolphin file browser displays programs compiled with qb64 version 0.5.0 as executable (which is correct) while those compiled with version 0.8.2 are displayed as shared library. even the program icons are different. this must be the problem.

[SMcNeill]

Add -no-pie to the compile options. That should fix the issue.

[Fifi]

Add  -no-pie to the compile options.  That should fix the issue.

Hi SMcNeill

I'm really not fluent with the new compilation method, even if it's good.

So, may I ask:
Yes, but where should I add this switch?
In the Makefile (I guess)?
Then, in what part?
Should I add the "-no-pie" switch in the section ifeq ($(OS),lnx) right after "CCXFLAGS += -DFREEGLUT_STATIC"?
like this: "CCXFLAGS += -DFREEGLUT_STATIC -no-pie"
or before like this:"CCXFLAGS += -no-pie -DFREEGLUT_STATIC"
or in another better place?

TIA for your help.

Cheers.
Fifi

[DSMan195276]

Yes, but where should I add this switch?
In the Makefile (I guess)?
Then, in what part?
Should I add the "-no-pie" switch in the section ifeq ($(OS),lnx) right after "CCXFLAGS += -DFREEGLUT_STATIC"?
like this: "CCXFLAGS += -DFREEGLUT_STATIC -no-pie"
or before like this:"CCXFLAGS += -no-pie -DFREEGLUT_STATIC"
or in another better place?

This is actually an easy one, using

v0.8.0

or higher you shouldn't need to touch any of the build logic Just open the

C++ Compiler Settings

dialog from the

Options

menu and add

-no-pie

to the Compiler flags. That should do everything you need.

[Fifi]

This is actually an easy one, using

v0.8.0

or higher you shouldn't need to touch any of the build logic Just open the

C++ Compiler Settings

dialog from the

Options

menu and add

-no-pie

to the Compiler flags. That should do everything you need.

OK when using the QB64 IDE to compile your own stuff, but what about the creation of QB64 itself?

When using the current install sheme, the qb64 program itself can't be started with a double click.

Should I recompile QB64 with QB64, witch was possible with the previous original QB64?

And what about using the command line in a terminal session: "qb64 -x /folder_source/prog.bas -o /folder_destination/new_prog" ?

TIA for your help.
Cheers.
Fifi

[DSMan195276]

OK when using the QB64 IDE to compile your own stuff, but what about the creation of QB64 itself?

When using the current install sheme, the qb64 program itself can't be started with a double click.

Should I recompile QB64 with QB64, witch was possible with the previous original QB64?

And what about using the command line in a terminal session: "qb64 -x /folder_source/prog.bas -o /folder_destination/new_prog" ?

All good questions It is possible to pass the same settings to the

Makefile

directly, I wrote some documentation on the settings here. I'm pretty sure we'll make

-no-pie

a default in the future, but for now you can pass it via the

CXXFLAGS_EXTRA

parameter to the Makefile, which is what the

C++ Compiler Flags

text box does.

You can absolutely still compile QB64pe using your existing QB64pe, which is probably easier than calling the Makefile with extra settings.

For the command line you should be able to set the settings in the IDE and then they will be applied when compiling via the command-line. I wanted to add the ability to supply custom flags on the command line but it was going to be a bit too involved so I dropped it for now.

[Coolman]

the code of qb64 is a real mess. i have examined it for a long time. any modification will inevitably lead to later corrections. that's why i'm still using version 0.5.0 based on 2.0.2 while waiting for the higher versions to stabilize...

[mnrvovrfc]

Do you want to make your life easier? Do not use spaces into a filename. On Linux just don't. Programming for "bash" is a royal pain. Must remember how to escape this char or that one with "backslash" or single or double-quotes, because people do stupid things like including control characters into a directory's name. Spaces in a filename worked on WindowsXP, that is, long ago. It's bad enough Unix and anything else closely based on it has case-sensitive file systems that one has to add to the confusion somehow.

If you have the time visit "askubuntu" or "stackoverflow" sites, for questions about stuff refusing to load or refusing to compile because of issues about filenames. Stuff that one could get away with on Windows, cannot do on Linux, on MacOS, on FreeBSD etc. The "setup_lnx.sh" has a "glitch" but it's by design of the OS and the terminal.

Is it too hard to use dashes or underscore instead of spaces? Oh yeah I forgot, the word-wrap of your favorite word processor might not like it. Some people want to move on from MS-DOS eight-dot-three and that's why they use spaces inside a filename. IDK I'm a bit intolerant. When I started using WindowsXP I also put spaces in filenames because I didn't know any better way back then near change of century. Using Linux made me realize I still have a lot of bad habits.