QApplication file not found

[Brendan Tracey]

I'm trying to get started with go-qml. I used go-get to get the code, and downloaded Qt. When trying to build the package, I was getting errors that suggested I add files to the PKG_CONFIG_PATH. I did this, which for me is

brendan:~/Documents/mygo/src$ echo $PKG_CONFIG_PATH
/Users/brendan/software/Qt/5.3/clang_64/lib/pkgconfig

Now when I try to install, I get

brendan:~/Documents/mygo/src$ go install github.com/go-qml/qml/examples/gopher/
# gopkg.in/qml.v0
In file included from gopkg.in/qml.v0/all.cpp:2:
gopkg.in/qml.v0/cpp/capi.cpp:1:10: fatal error: 'QApplication' file not found


I see that there is a qapplication.h deeper in the Qt file structure. Am I supposed to add this as well? Am I doing the wrong thing? Thanks.

[David Marceau]

On 06/01/2014 05:46 PM, Brendan Tracey wrote:
> I'm trying to get started with go-qml. I used go-get to get the code, and
> downloaded Qt. When trying to build the package, I was getting errors that
> suggested I add files to the PKG_CONFIG_PATH. I did this, which for me is
>
> brendan:~/Documents/mygo/src$ echo $PKG_CONFIG_PATH
> /Users/brendan/software/Qt/5.3/clang_64/lib/pkgconfig
>
> Now when I try to install, I get
>
> brendan:~/Documents/mygo/src$ go install
> github.com/go-qml/qml/examples/gopher/
> # gopkg.in/qml.v0
> In file included from gopkg.in/qml.v0/all.cpp:2:

> gopkg.in/qml.v0/cpp/capi.cpp:1:10: fatal error: 'QApplication' file not
> found

This is definitely hinting that you are missing some prerequisite files
on your system. You haven't even built the go-qml infrastructure
successfully yet.

>
> I see that there is a qapplication.h deeper in the Qt file structure. Am I
> supposed to add this as well? Am I doing the wrong thing? Thanks.
>

I don't recall if it works with Qt/5.3. You'll have to ask Mr. Niemayer.

What operating system are you running it on? clang_64 looks like MAC OS
X default stuff. I would first try this stuff in a Linux VM. See it
working there, then for the files you are missing search for them on the
ubuntu file system and then find the similar file in the respective
package that you need to install for MAC OS X.

For it to work on ubuntu desktop:
sudo apt-get install git golang pkg-config golang-go.tools
sudo apt-get install qtbase5-private-dev
sudo apt-get install qtdeclarative5-private-dev
sudo apt-get install libqt5opengl5-dev
sudo apt-get install gccgo gccgo-go
sudo apt-get install g++ g++-multilib

mkdir -p /home/brendan/mygo
export GOPATH=/home/brendan/mygo

Then do this:
go get gopkg.in/qml.v0
That will plunk in lots of files into /home/brendan/mygo.

cd /home/gour/goqmlstuff/src/gopkg.in/qml.v0/examples/customtype
go build

For it to work on ubuntu touch, I found a trick to avoid getting
"storage exceeded" errors when installing the above packages. Do the
following after every apt-get install:
sudo apt-get clean
sudo apt-get autoremove
This explains why I didn't make the apt-get install lines into ONE HUGE
apt-get install command above.

Cheers,
David Marceau
http://adequatech.ca

[Brendan Tracey]

Thank you for the reply. I went through the process again, and I can now compile the program, but I'm getting a runtime panic. I assume this is a problem with $CGO_CPPFLAGS. What do they need to be?

brendan:~/Documents/mygo/src/gopkg.in/qml.v0/examples/gopher$ rm /Users/brendan/Documents/mygo/bin/gopher
rm: /Users/brendan/Documents/mygo/bin/gopher: No such file or directory
brendan:~/Documents/mygo/src/gopkg.in/qml.v0/examples/gopher$ echo $PKG_CONFIG_PATH
/usr/local/opt/qt5/lib/pkgconfig
brendan:~/Documents/mygo/src/gopkg.in/qml.v0/examples/gopher$ echo $CXX
g++-4.8
brendan:~/Documents/mygo/src/gopkg.in/qml.v0/examples/gopher$ echo $CGO_CPPFLAGS
 
brendan:~/Documents/mygo/src/gopkg.in/qml.v0/examples/gopher$ go install
brendan:~/Documents/mygo/src/gopkg.in/qml.v0/examples/gopher$ gopher
SIGSEGV: segmentation violation
PC=0x7fff88be7774
signal arrived during cgo execution

runtime.cgocall(0x4002580, 0x63afde8)
    /Users/brendan/gover/go_1_2_1/src/pkg/runtime/cgocall.c:149 +0x11b fp=0x63afdd0
gopkg.in/qml%2ev0._Cfunc_objectIsComponent(0x6425270, 0xc210000250)
    gopkg.in/qml.v0/_obj/_cgo_defun.c:420 +0x31 fp=0x63afde8
gopkg.in/qml%2ev0.(*Common).CreateWindow(0xc21000ab10, 0x0, 0xa)
    /Users/brendan/Documents/mygo/src/gopkg.in/qml.v0/qml.go:721 +0x6b fp=0x63afe30
main.run(0x4151bb0, 0xa, 0x405668d, 0x427e7d8)
    /Users/brendan/Documents/mygo/src/gopkg.in/qml.v0/examples/gopher/gopher.go:42 +0x1d3 fp=0x63afea8
main.main()
    /Users/brendan/Documents/mygo/src/gopkg.in/qml.v0/examples/gopher/gopher.go:15 +0x69 fp=0x63aff48
runtime.main()
    /Users/brendan/gover/go_1_2_1/src/pkg/runtime/proc.c:220 +0x11f fp=0x63affa0
runtime.goexit()
    /Users/brendan/gover/go_1_2_1/src/pkg/runtime/proc.c:1394 fp=0x63affa8

goroutine 3 [syscall]:
runtime.goexit()
    /Users/brendan/gover/go_1_2_1/src/pkg/runtime/proc.c:1394

goroutine 4 [runnable]:
gopkg.in/qml%2ev0.hookIdleTimer()
    /Users/brendan/Documents/mygo/src/gopkg.in/qml.v0/bridge.go:179 +0x8c
gopkg.in/qml%2ev0._Cfunc_applicationExec(0x429d078)
    gopkg.in/qml.v0/_obj/_cgo_defun.c:69 +0x31
gopkg.in/qml%2ev0.guiLoop()
    /Users/brendan/Documents/mygo/src/gopkg.in/qml.v0/bridge.go:43 +0x132
created by gopkg.in/qml%2ev0.Init
    /Users/brendan/Documents/mygo/src/gopkg.in/qml.v0/qml.go:44 +0xa0

rax     0x7fff7206cd60
rbx     0x6425270
rcx     0x588bd90
rdx     0x6
rdi     0x588bd90
rsi     0x0
rbp     0x588bd90
rsp     0xb04abda8
r8      0x6425270
r9      0x60305e0
r10     0x44ae720
r11     0x43c2eb0
r12     0x60305e0
r13     0x0
r14     0x13763521462c7600
r15     0x637ee80
rip     0x7fff88be7774
rflags  0x10202
cs      0x2b
fs      0x0
gs      0x72060000

[Brendan Tracey]

I just upgraded to 1.2.2 and observe the same behavior.

[Brendan Tracey]

This also happens on the master branch of github.com/go-qml/qml

[Bernard Sufrin]

I have exactly the same problem as Brendan reports here -- as it happens while moving functioning go-qml applications from an Ubuntu to

this OS/X Mavericks machine.

The Qt sources are all present (and I have built several Qt applications on this machine)

Here's the transcript:

633 $ export PKG_CONFIG_PATH=/Users/sufrin/Local/Qt/5.3/clang_64/lib/pkgconfig

634 $ go install gopkg.in/qml.v1

# gopkg.in/qml.v1

In file included from src/gopkg.in/qml.v1/all.cpp:2:

src/gopkg.in/qml.v1/cpp/capi.cpp:1:10: fatal error: 'QApplication' file not found

The headers are in /Users/sufrin/Local/Qt/5.3/clang_64/lib/QtWidgets.framework/Versions/5/Headers

635 $ cat /Users/sufrin/Local/Qt/5.3/clang_64/lib/QtWidgets.framework/Versions/5/Headers/QApplication

#include "qapplication.h"

636 $ ls -l /Users/sufrin/Local/Qt/5.3/clang_64/lib/QtWidgets.framework/Versions/5/Headers/qapplication.h

-rw-r--r--  1 sufrin  staff  8323 19 Jun 16:23 /Users/sufrin/Local/Qt/5.3/clang_64/lib/QtWidgets.framework/Versions/5/Headers/qapplication.h

[Gustavo Niemeyer]

The problem is clearly that these headers are not in the location
expected by the compiler, and the way that the qml package influences
that path is by using the following pkg-config configuration:

#cgo pkg-config: Qt5Core Qt5Widgets Qt5Quick

This will cause go build to run pkg-config with both --libs and
--cflags for each of those, and include in the build path. So, to
debug the issue I'd recommend:

1. Run go build with the -x flag, and find out what actual commands
are being run, with which flags

2. Find out what pkg-config with the described flags and options
reports (e.g. pkg-config --cflags Qt5Widgets)

3. See if that's present in the build, and why the relevant directory
is not part of it

> --
> You received this message because you are subscribed to the Google Groups
> "go-qml" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to go-qml+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--

gustavo @ http://niemeyer.net

[Bernard Sufrin]

On Monday, 15 September 2014 16:02:33 UTC+1, Gustavo Niemeyer wrote:

The problem is clearly that these headers are not in the location
expected by the compiler

Without saying that the following is the only way to get around this problem, I have found that on OS/X (Mavericks and earlier) the problem is that the structure of the appropriate Qt5  include and lib directories are somewhat different on OS/X from Linux. In the former, the include directory is sparse, and the lib directory includes framework structures.

596 $ ls include/
QtOpenGLExtensions/ QtPlatformSupport/  QtUiTools/
597 $ find lib -path "*.framework*Headers"
lib/Enginio.framework/Headers
lib/Enginio.framework/Versions/1/Headers
lib/QtBluetooth.framework/Headers
lib/QtBluetooth.framework/Versions/5/Headers
lib/QtCLucene.framework/Headers
... etc etc ...

It is the framework/.../Headers  directories that hold the actual header files

My brute-force solution was to symbolic-link the actual header files into the include file.

Here's a bash script that generates a script that does the business. You will need write-access to the include directory.

if [ -x "$QT_LIBRARY_PATH" ]
then 
  echo Qt Library path is $QT_LIBRARY_PATH
else 
  echo You need to set QT_LIBRARY_PATH to make framework header linking script
  exit 1
fi


# translate the path of a library framework $1 into a command to symbolically link the framework into include
function genframeworklink {
sed -e "s,\(lib/\([A-Za-z_]*\)[.]framework/.*/Headers\),ln -sF ../\1 include/\2," <<END
$1
END
}

cd $QT_LIBRARY_PATH/..
SCRIPT=$PWD/linkframeworkheaders.sh
echo Making script to make symlinks for framework headers in $SCRIPT
echo "cd $PWD" > $SCRIPT
for f in $(find lib -path "*.framework/*/Headers")
do
  echo echo $f; genframeworklink $f
done >> $SCRIPT

---

After running this (and then the generated script) I was able to compile/install the go-qml package on my Mavericks machine, and to compile
and run a (sommewhat edited version of) the distributed samegame.

I adjusted the ''what language" compilation flag  in the distributed bridge.go file to -std=c++11 (IIRC the distributed file said something like -std=c++0x).

Sadly, the Lion (OS/X 10.7) variant of the XCode tools accepts neither -std=c++11or -std=c++0x, and leaving the language standard undeclared, or declared to be the latest standard listed in the documentation, leads to a complaint about the types of some declared integers. I didn't investigate this amy further.

---

It would be great to have a more portable, less brute-force, variant of the go-qml distribution; but I'm in no position to make one.

[Gustavo Niemeyer]

Hey Bernard,

I'm sorry you're still having trouble with this.

On Fri, Sep 26, 2014 at 1:20 PM, Bernard Sufrin
<sufrin....@gmail.com> wrote:
> On Monday, 15 September 2014 16:02:33 UTC+1, Gustavo Niemeyer wrote:
>>
>> The problem is clearly that these headers are not in the location
>> expected by the compiler
>
> Without saying that the following is the only way to get around this
> problem, I have found that on OS/X (Mavericks and earlier) the problem is
> that the structure of the appropriate Qt5 include and lib directories are
> somewhat different on OS/X from Linux. In the former, the include directory
> is sparse, and the lib directory includes framework structures.

If that's indeed the case, it would be a bug in the distribution of
Qt. The structure under the main include path is determined by the
upstream project, not by any Linux distribution. If you download the
files provided at the project website, it will match the paths
expected by the qml package as well.

That said, I haven't found much in the following examples that
demonstrate such divergences, so I'm not entirely sure about what
you're reporting.

For example:

> 596 $ ls include/
> QtOpenGLExtensions/ QtPlatformSupport/ QtUiTools/

This looks like the main include path. I can find both
QtOpenGLExtensions and QtPlatformSupport under /usr/include/qt5, and I
expect you'll be able to find QApplication under
include/QtWidgets/QApplication as well.

> 597 $ find lib -path "*.framework*Headers"
> lib/Enginio.framework/Headers
> lib/Enginio.framework/Versions/1/Headers
> lib/QtBluetooth.framework/Headers
> lib/QtBluetooth.framework/Versions/5/Headers
> lib/QtCLucene.framework/Headers
> ... etc etc ...

I don't have any of these, with or without the ".framework" suffix.

> It would be great to have a more portable, less brute-force, variant of the
> go-qml distribution; but I'm in no position to make one.

I would love that as well, and we have been working in that direction
for a while. That said, I'm not a Mac OS user, so I cannot tell what
"portable" would mean for you. I know, for example, that a number of
people have had an easier time getting it setup lately, after v1 is
out, and no one reported the kind of hackery you describe. So it
sounds like there's already a better way to do that.


gustavo @ http://niemeyer.net

[Carlos Castillo]

Frameworks automatically map "Qt5Core/*.h" to "Qt5Core.framework/Headers/*.h" in official OSX compilers, as long as the compiler can find the framework, and the -F option is the command line option to tell the compiler where to search (eg: like -L and -I). So, one option instead of symlinking would be to ensure the compiler sees the -F argument that is also sent to the linker, eg: run pkg-config --libs Qt5Core, and pass it's -F option in either the CGO_CPPFLAGS or CGO_CFLAGS environment variables when running go get.

Alternatively you could modify the pkg-config files yourself to include the -F argument in the compiler arguments as well.

Finally you could just use the actual install instructions in the qml.v1 README, and use the homebrew version of qt5 instead. Oddly enough, it actually does the symlink hackery itself for you, but the end result is that you need to do nothing special to run the go get command.

[Carlos Castillo]

Ok there's no Qt5Core framework (that's just the name of the pkg-config file) but the advice still stands.

I attempted to build the following using just the compiler (no qmake, ie: "c++ -c foo.cpp"):

#include <QtCore/qmath.h>

int main (void) {

return 0;

}

With no symlinking tomfoolery this fails. But by passing an -F option to g++ (in my case: -F/usr/local/Cellar/qt5/5.3.2/lib), it does work. It can then find the QtCore framework, and from there evaluate <QtCore/qmath.h> properly.