private/qmetaobject_p.h: No such file or directory

[pierrre]

go get -v -u github.com/niemeyer/qml
github.com/niemeyer/qml (download)
github.com/niemeyer/qml
# github.com/niemeyer/qml
In file included from src/github.com/niemeyer/qml/cpp/capi.cpp:10:0,
                 from src/github.com/niemeyer/qml/all.cpp:2:
src/github.com/niemeyer/qml/cpp/govalue.h:7:35: fatal error: private/qmetaobject_p.h: No such file or directory
 #include <private/qmetaobject_p.h>

OS: Archlinux 64 bits QT version: 5.2.1 (I received an update today. It was ok with the previous version.)

[niemeyer]

This should fix it. Thanks for the heads up.

[pierrre]

It works! Thank you :)

[zoli]

I have the same problem i am on debian 7 wheezy i have installed qt 5.2.1 but its in /opt/Qt5.2.1 What should i do to resolve this problem

[sshikaree]

Here are general rules that I have sketched for separately installed Qt. Assume that it was installed in ~/Qt5.2.1/

1. Add these lines in you ~/.profile

export PKG_CONFIG_PATH=$HOME/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig
export LD_LIBRARY_PATH=$HOME/Qt5.2.1/5.2.1/gcc_64/lib

and re-login.

2. Go to directory with qo-qml package

$ cd $GOPATH/src/gopkg.in/v0/qml

edit bridge.go and add these lines

// #cgo CPPFLAGS: -I<path_to_your_Qt_directory>/Qt5.2.1/5.2.1/Src/qtbase/include/QtCore
// #cgo CPPFLAGS: -I<path_to_your_Qt_directory>/Qt5.2.1/5.2.1/Src/qtbase/include/QtCore/5.2.1/QtCore

// #cgo pkg-config: <path_to_your_Qt_directory>Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/Qt5Core.pc <path_to_your_Qt_directory>/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/Qt5Widgets.pc <path_to_your_Qt_directory>/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/Qt5Quick.pc

Don't forget to change path_to_your_Qt_directory. Then try to run

$ go install

[zoli]

It works, thanks.

[oblitum]

@ZiDoMs @sshikaree I also have done that way just once upon a time, but I learned it was best to set CGO_CPPFLAGS instead of patching, it worked the same. I suggested a pull-request with this more explicit and simpler explanation, the changeset can be checked here, please take a look.

These days I use an alias trick in my ~/.bash_aliases file for setting up my shell with my current Qt, e.g.:

alias setupqt53='export PKG_CONFIG_PATH=/opt/qt/5.3.0/linux/lib/pkgconfig; export CGO_CPPFLAGS="-I/opt/qt/5.3.0/linux/include/QtCore/5.3.0/QtCore"'

So I just have to "run" setupqt53 before doing go get or go get -u (I also have a setupclean to clean up this setup).

[oblitum]

Another thing that I do for linking with Qt 5 for my apps is setting up ldconfig, for example, I have the /etc/ld.so.conf.d/qt.conf file which content is just the library path of my current Qt installation, e.g. /opt/qt/5.3.0/linux/lib. After having set up or changed this file, I run sudo ldconfig and re-login.

[zoli]

@oblitum i agree with you setting the CGO_CPPFLAGS is much better

[oblitum]

@niemeyer Don't you think the README could deserve an improvement in the direction of that old PR/discussion? Maybe putting such instructions in another "general" subsection.

[sshikaree]

Yep, it is better to put everything in environment variables.

[GeertJohan]

I just had the same issue again. #57 fixes that.

[oblitum]

@GeertJohan Have you tried to set the environment as everyone is stating here, it woudn't require a patch.

[GeertJohan]

Yes. export CGO_CPPFLAGS="-I/usr/include/qt5/QtCore/5.0.1/QtCore" does work. But that's not very friendly for anyone else trying to build the pkg. I think adding the compatible versions to the CPPFLAGS in the go source would increase usability of this package.

[oblitum]

@GeertJohan I don't know... I concur it's not friendly but including every point release doesn't seems like a solution either. Personaly, I would just state what should be included, and the user would do so by setting the environment, this would work for everyone, let Qt be installed anywhere in the file system, and wouldn't require frequent patches.

[niemeyer]

Don't you think the README could deserve an improvement in the direction of that old PR/discussion? Maybe putting such instructions in another "general" subsection.

@oblitum We already have an "Everywhere else" section, and we already have sections that mention how to tweak the environment variables. I've added a note there even then. Please feel free to submit an improvement, though.

I don't know... I concur it's not friendly but including every point release doesn't seems like a solution either. Personaly, I would just state what should be included, and the user would do so by setting the environment, this would work for everyone, let Qt be installed anywhere in the file system, and wouldn't require frequent patches.

We can have as many lines as needed to get environments people care about to build out of the box. For the time being, we only need to do this once per release, which will always be trivial on our side compared to the cost of doing the release. In the medium term, I hope to get a patch in the "go" tool that allow us to glob those paths, so we only need them once. #57 is in.

[oblitum]

ZiDoMs: I have the same problem i am on debian 7 wheezy i have installed qt 5.2.1 but its in /opt/Qt5.2.1 What should i do to resolve this problem?

So, if @ZiDoMs's installation on Debian was a standard one, I mean, without changing installation path on purpose, all /usr/... paths being listed now should be replicated as /opt/...? I think it may be the case since /opt vs /usr for some stuff is a long time battle in *nix systems/users.

Also, I think the notice in the README is still at the same state as that of the time of that old PR. I think I have provided enough information in that discussion, from my point of view at last, on why a simpler and clearer explanation regarding the environment settings could help.

[niemeyer]

So, if @ZiDoMs's installation on Debian was a standard one, I mean, without changing installation path on purpose, all /usr/... paths being listed now should be replicated as /opt/...? I think it may be the case since /opt vs /usr for some stuff is a long time battle in *nix systems/users.

There's no battle about this. /opt is part of well known standards.

That said, there's something not quite right. Debian would not install something on /opt out of the box, so how has Qt landed there? Is that where the upstream packages from the Qt project are being deployed? Can someone with these packages send us the output of these two commands:

find /opt -name qmetaobject_p.h
dpkg -S $(find /opt -name qmetaobject_p.h)

Also, I think the notice in the README is at the same state as that of the time of that old PR. I think have provided enough information in that discussion, from my point of view at last, on why a simpler and clearer explanation regarding the environment settings could help.

Can you please submit a pull request then?

[oblitum]

Can you please submit a pull request then?

What I have provided in that one, would be the same content of a new one... I don't know which section such information would fit better for you. As the owner I would just accept the PR, or use it as a basis for a commit, but editing and putting the info where I feel it fits better.

[zoli]

So, if @ZiDoMs's installation on Debian was a standard one, I mean, without changing installation path on purpose, all /usr/... paths being listed now should be replicated as /opt/...? I think it may be the case since /opt vs /usr for some stuff is a long time battle in *nix systems/users.

By that time i was installing qt5 i didn't feel good about installing qt5 in /usr so i changed it to /opt but Maybe you're right i should have installed qt in default installation path

find /opt -name qmetaobject_p.h result:
/opt/Qt5.2.1/5.2.1/android_armv7/include/QtCore/5.2.1/QtCore/private/qmetaobject_p.h
/opt/Qt5.2.1/5.2.1/android_armv5/include/QtCore/5.2.1/QtCore/private/qmetaobject_p.h
/opt/Qt5.2.1/5.2.1/Src/qtbase/include/QtCore/5.2.1/QtCore/private/qmetaobject_p.h
/opt/Qt5.2.1/5.2.1/Src/qtbase/src/corelib/kernel/qmetaobject_p.h
/opt/Qt5.2.1/5.2.1/gcc_64/include/QtCore/5.2.1/QtCore/private/qmetaobject_p.h
/opt/Qt5.2.1/5.2.1/android_x86/include/QtCore/5.2.1/QtCore/private/qmetaobject_p.h

dpkg -S $(find /opt -name qmetaobject_p.h) result:
dpkg-query: no path found matching pattern /opt/Qt5.2.1/5.2.1/android_armv7/include/QtCore/5.2.1/QtCore/private/qmetaobject_p.h
dpkg-query: no path found matching pattern /opt/Qt5.2.1/5.2.1/android_armv5/include/QtCore/5.2.1/QtCore/private/qmetaobject_p.h
dpkg-query: no path found matching pattern /opt/Qt5.2.1/5.2.1/Src/qtbase/include/QtCore/5.2.1/QtCore/private/qmetaobject_p.h
dpkg-query: no path found matching pattern /opt/Qt5.2.1/5.2.1/Src/qtbase/src/corelib/kernel/qmetaobject_p.h
dpkg-query: no path found matching pattern /opt/Qt5.2.1/5.2.1/gcc_64/include/QtCore/5.2.1/QtCore/private/qmetaobject_p.h
dpkg-query: no path found matching pattern /opt/Qt5.2.1/5.2.1/android_x86/include/QtCore/5.2.1/QtCore/private/qmetaobject_p.h

[niemeyer]

@ZiDoMs That doesn't come from Debian, so /opt is probably a good choice. Where did you get that content from?

[oblitum]

@ZiDoMs I still don't feel right about installing from sources straight to /usr/local because I have done so already and installation spread some new files/directories right into /usr/local/ and I don't know where, I don't like this for "uninstallation". I prefer stick to putting versioned Qt's under /opt/...

[zoli]

@niemeyer I run them in my terminal as you asked

Can someone with these packages send us the output of these two commands

[oblitum]

So, if @ZiDoMs's installation on Debian was a standard one, I mean, without changing installation path on purpose, all /usr/... paths being listed now should be replicated as /opt/...? I think it may be the case since /opt vs /usr for some stuff is a long time battle in *nix systems/users.

There's no battle about this. /opt is part of well known standards.

Ah, I think the battle I was recalling regards /usr/local vs /opt for non-system installs.

[niemeyer]

@niemeyer I run them in my terminal as you asked

@ZiDoMs By content I meant the Qt files installed in /opt.

[zoli]

Oh sorry from qt project Qt 5.2.1 for Android (Linux 64-bit, 846 MB)

[niemeyer]

Alright, the change submitted with ef43d86 should sort out this issue definitively. We don't need to maintain the include paths for individual Qt releases anymore.

[oblitum]

Nice. My docs request is dropped for good.