[SOLVED] Debian 9 QT Program Compile

djme

Hi,
I just installed Debian 9 64 bit and installed QT using the commands below:

sudo apt-get install build-essential
sudo apt-get install qtcreator qt5-default

When I create a test Qt Widgets Application in Qt Creator I can build it and the program launches fine from within Qtcreator. However, when I navigate to the associated "debug" or release "directory", I cannot see an application/executable file like I could with Qt4 in Debian 8. Below is a screenshot of the release directory. In Debian 8, my executable file used to be in here.

My test project is simply called "TEST" and the TEST file below, appears to be a shared library (application/x-sharedlib) according to the file manager. Do I need to do anything else to turn this into an application/executable?

Am I missing an install component or must I configure something in Qtcreator to achieve this?
Appreciate if anyone can offer any help and apologies if I am overlooking something simple.

koahnig

@djme

Hi and welcome to devnet forum.

I am not sure how it looks under Debian, but in creator you have a button on the left side saying "Projects" click on this. You should see something like Build &run on the left creator pane. Under "Build&Run" you see the actual tool kit used (compiler and Qt version used for compilation).
There is an entry for build and another for "Run". Under "Run" you shall see the location on the large the "Run settings". There it tells you where the executable is located.

Note: Description based on windows version, but AFAIK it should be same for all OS.

SGaist

Hi and welcome to devnet,

Can you share your .pro file ?

djme

Hi @koahnig,

Please see below for my Run Settings. It looks like my executable file is set to save to where I expect it to be i.e. /home/dme/build-TEST-Desktop-Release

The trouble is, there is no executable file in this directory. In QT4 with Debian 8, the executable would always be in the debug or release directory when I completed a build with Qtcreator.

When Qtcreator lauches the program, where could it be launching it from? It still seems weird to me that I end up with a shared library file. I think Qt is building that instead of an executable even though I chose QT Widgets Application at the start.

djme

Hi @SGaist,

Here is the contents of my .pro file:

#-------------------------------------------------
#
# Project created by QtCreator 2017-06-26T19:23:52
#
#-------------------------------------------------

QT       += core gui

greaterThan(QT_MAJOR_VERSION, 4): QT += widgets

TARGET = TEST
TEMPLATE = app

# The following define makes your compiler emit warnings if you use
# any feature of Qt which as been marked as deprecated (the exact warnings
# depend on your compiler). Please consult the documentation of the
# deprecated API in order to know how to port your code away from it.
DEFINES += QT_DEPRECATED_WARNINGS

# You can also make your code fail to compile if you use deprecated APIs.
# In order to do so, uncomment the following line.
# You can also select to disable deprecated APIs only up to a certain version of Qt.
#DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000    # disables all the APIs deprecated before Qt 6.0.0


SOURCES += main.cpp\
        mainwindow.cpp

HEADERS  += mainwindow.h

FORMS    += mainwindow.ui

Also below is a screen shot of the program when it launches. This is just a quick dummy form I created to see if I could successfully create a standalone application/executable but for some reason Qtcreator will not do this :-(

koahnig

@dme
As noted before my description is based on my windows experience.

The pane basically sais that there is an executable "/home/dme/build-TEST-Desktop-Release/TEST"

In windows it would have the extension .exe added of course. That should be in my understanding the executable which is actually started in creator. When I could not in past because of AV killed my executable before starting creator exactly the file referenced was gone.

@djme said in Debian 9 QT Program Compile:

When Qtcreator lauches the program, where could it be launching it from? It still seems weird to me that I end up with a shared library file. I think Qt is building that instead of an executable even though I chose QT Widgets Application at the start.

What do you mean here? You see something like dynamic link library?
That sounds strange.
Anyway I fear I cannot help you.

Possibly @SGaist can help.

djme

@koahnig said in Debian 9 QT Program Compile:

What do you mean here? You see something like dynamic link library?
That sounds strange.
Anyway I fear I cannot help you.

No worries koahnig. Thanks for trying to help.

When I click on the TEST file in my release directory, I see the following message:

If I right click on the TEST file and check the properties, I see the following:

This might be an issue with the default program that the file manager uses to open such files since I tried to run it through the terminal and it actually launched fine!

So I think that the application/executable file is being generated, but my Debian system does not seem to recognize it as a stand alone application and does not execute it when I click on it. I'll have to figure out how to configure the Debian 9 file manager to launch the application by itself when I click on it. If I do, I will update this post.

Thanks for the replies!!

SGaist

Go to the command line and run ldd TEST

djme

Hi @SGaist

Here is the output of "ldd TEST".

	linux-vdso.so.1 (0x00007fff823b2000)
	libQt5Widgets.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 (0x00007f4342b05000)
	libQt5Gui.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 (0x00007f43425cc000)
	libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 (0x00007f43420fd000)
	libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f4341e8b000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4341c6e000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f43418ea000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f43415e6000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f43413cf000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4341030000)
	libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f4340d9b000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4340b81000)
	libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f434094c000)
	libicui18n.so.57 => /usr/lib/x86_64-linux-gnu/libicui18n.so.57 (0x00007f43404d2000)
	libicuuc.so.57 => /usr/lib/x86_64-linux-gnu/libicuuc.so.57 (0x00007f434012a000)
	libpcre16.so.3 => /usr/lib/x86_64-linux-gnu/libpcre16.so.3 (0x00007f433fec1000)
	libdouble-conversion.so.1 => /usr/lib/x86_64-linux-gnu/libdouble-conversion.so.1 (0x00007f433fcb0000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f433faac000)
	libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f433f796000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f433f58e000)
	/lib64/ld-linux-x86-64.so.2 (0x0000561999426000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f433f364000)
	libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007f433f161000)
	libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0 (0x00007f433ef5e000)
	libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007f433ed57000)
	libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1 (0x00007f433eb53000)
	libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007f433e924000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f433e712000)
	libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f433e50f000)
	libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f433e309000)
	libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f433e107000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f433ddc5000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f433db9d000)
	libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007f433d982000)
	libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007f433d77d000)
	libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f433d577000)
	libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f433d367000)
	libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f433d0b6000)
	libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f433ce89000)
	libicudata.so.57 => /usr/lib/x86_64-linux-gnu/libicudata.so.57 (0x00007f433b40c000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f433b199000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f433af95000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f433ad8d000)
	libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f433ab77000)

SGaist

And what about file TEST ?

Mark.Roth

I was having this same issue after updating to Stretch. It isn't QtCreator doing it but a default setting of GCC6. I would get the so from a simple command line compiled program. To fix this you need to add the switch -no-pie to the gcc settings.
I did this by making the small change to my .pro file.

QMAKE_LFLAGS += -no-pie

After that I got the executable I used to get. Hopefully you were having the same issue.

djme

@Mark.Roth said in Debian 9 QT Program Compile:

QMAKE_LFLAGS += -no-pie

Thank you Mark Roth!!!! It is now fixed :)

Many thanks for your helpful suggestion.

Mark.Roth

@djme I'm glad it worked out. I know it was driving me mad until I figured out why. Just another check mark on the after upgrade list. :)

SGaist

@Mark-Roth Is this something you notified the Qt Project about ?

Mark.Roth

@SGaist I don't see how the Qt Project is responsible. It is to do with GCC6. Debian 8 (Jessie) was using gcc 4.6 I think (strike that 4.9 https://packages.debian.org/jessie/gcc) so it was a huge jump in Stretch. This problem occurs even compiling a simple program (non-qt) from the command line.
I did a little digging but can't find out when the -pie (and I suppose the compiler flag pairs) became the default. I supposed it could have been in GCC5. Using Debian does have it's down-sides.
https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#index-no-pie

I'll have to see if using one of the compiler side switches creates a binary that can be run normally. Like I said, I only just ran into this when I upgraded to Stretch this past week.

SGaist

I didn't wrote they were responsible. I was just asking you whether you shared that information with them so that they can act accordingly with e.g. documentation update etc.

Mark.Roth

@SGaist Ah, then I should have just said, "No I haven't."

What I was getting at is that this may have been around for quite some time. Some of the hits I found while searching were from over 2 years ago. The only people this sort of thing may be new to are those who have been using an old version of GCC. Or perhaps it is Debian specific with the way it associates files. I'm just a hobbiest hack that created an account here to help out the OP.
If you think it should be passed along, by all means do so. :)

SGaist

It's very nice of you and highly appreciated :)

Thank you !