On Monday, 24 July 2017 16:26:10 PDT Thiago Macieira wrote:
> This can also happen intra-Qt too, if you're doing split builds. Suppose
> you're building qtmultimedia again but it's already installed. You need to
> link to qtbase libraries, so the -L for the install dir is provided. That
> means
On Monday, 24 July 2017 15:20:07 PDT Allan Sandfeld Jensen wrote:
> It is a work-around, but it is an issue that pops up frequently and can take
> a while until solved. I do have development files of the system Qt
> installed, and it usually works just fine. When it does pop up it is
> however
On Sonntag, 23. Juli 2017 22:49:11 CEST Martin Koller wrote:
> On Sonntag, 23. Juli 2017 18:54:41 CEST Thiago Macieira wrote:
> > On Sunday, 23 July 2017 01:50:10 PDT Martin Koller wrote:
> > > I found this symbol to be in the qgsttools_p lib but I fear the linker
> > > takes the lib from a wrong
On Monday, 24 July 2017 13:30:24 PDT Martin Koller wrote:
> On Montag, 24. Juli 2017 16:52:05 CEST Thiago Macieira wrote:
> > On Monday, 24 July 2017 04:26:55 PDT Martin Koller wrote:
> > > Why does my Qt build use the system installed
> > > /usr/lib64/libqgsttools_p.prl
> > > file and not the one
On Montag, 24. Juli 2017 16:52:05 CEST Thiago Macieira wrote:
> On Monday, 24 July 2017 04:26:55 PDT Martin Koller wrote:
> > Why does my Qt build use the system installed /usr/lib64/libqgsttools_p.prl
> > file and not the one from the build dir
>
> "Because it was found".
Then the solution is
On Montag, 24. Juli 2017 08:34:56 CEST Thiago Macieira wrote:
> On Sunday, 23 July 2017 23:03:04 PDT Kevin Kofler wrote:
> > Thiago Macieira wrote:
> > > This is the root of your problem. Something that this plugin or
> > > qgsttools_p needs to link to said that its libraries are in /usr/lib64.
>
On Montag, 24. Juli 2017 08:32:23 CEST Thiago Macieira wrote:
> On Sunday, 23 July 2017 22:58:02 PDT Martin Koller wrote:
> > So the bug in fact is that qt does not give a correct name for
> > libQt5MultimediaGstTools.prl ?
>
> I don't know if that's a bug. I've never felt a problem with the .prl
On Mon, Jul 24, 2017 at 07:58:30AM +0200, Kevin Kofler wrote:
> Thiago Macieira wrote:
> > No, this is the solution, unless you want to build in a chroot'ed build
> > root. In the environment where you're going to build a given software, you
> > must not have the development packages of that
On Sunday, 23 July 2017 23:03:04 PDT Kevin Kofler wrote:
> Thiago Macieira wrote:
> > This is the root of your problem. Something that this plugin or
> > qgsttools_p needs to link to said that its libraries are in /usr/lib64.
> > qmake has some code to remove system paths, but it that won't work
On Sunday, 23 July 2017 22:58:02 PDT Martin Koller wrote:
> So the bug in fact is that qt does not give a correct name for
> libQt5MultimediaGstTools.prl ?
I don't know if that's a bug. I've never felt a problem with the .prl being
named like that.
> In fact it does use the infix for the other
On Sunday, 23 July 2017 22:58:30 PDT Kevin Kofler wrote:
> Thiago Macieira wrote:
> > No, this is the solution, unless you want to build in a chroot'ed build
> > root. In the environment where you're going to build a given software, you
> > must not have the development packages of that software
Martin Koller wrote:
> So the bug in fact is that qt does not give a correct name for
> libQt5MultimediaGstTools.prl ?
The bug is that something tries to use -L/usr/lib64. That directory is in
the default linker search path, it makes no sense to -L it, and doing it
anyway messes up the search
Thiago Macieira wrote:
> This is the root of your problem. Something that this plugin or
> qgsttools_p needs to link to said that its libraries are in /usr/lib64.
> qmake has some code to remove system paths, but it that won't work if the
> path being requested is both:
> a) not system
> b)
Thiago Macieira wrote:
> No, this is the solution, unless you want to build in a chroot'ed build
> root. In the environment where you're going to build a given software, you
> must not have the development packages of that software already installed.
That is utter nonsense. Any package that picks
On Sonntag, 23. Juli 2017 23:40:30 CEST Thiago Macieira wrote:
> > -) -lQt5MultimediaWidgets and others: why are they used here instead of the
> > namespaced/infixed versions, which are also given>
> >but later in the line ?
>
> Same reason: the system-wide qgsttools_p.prl file was found.
>
On Sunday, 23 July 2017 01:50:10 PDT Martin Koller wrote:
> -) why is -L/usr/lib64 there (should be a std. path, no?)
This is the root of your problem. Something that this plugin or qgsttools_p
needs to link to said that its libraries are in /usr/lib64. qmake has some
code to remove system
On Sunday, 23 July 2017 14:22:03 PDT Thiago Macieira wrote:
> > (I need Qt devel system files when compiling KDE, but I need to build my
> > own Qt for company project)
>
> You must install and uninstall the development packages as needed then. Or
> set up a build root for building one or the
On Sunday, 23 July 2017 13:49:11 PDT Martin Koller wrote:
> On Sonntag, 23. Juli 2017 18:54:41 CEST Thiago Macieira wrote:
> > On Sunday, 23 July 2017 01:50:10 PDT Martin Koller wrote:
> > > I found this symbol to be in the qgsttools_p lib but I fear the linker
> > > takes the lib from a wrong
On Sonntag, 23. Juli 2017 18:54:41 CEST Thiago Macieira wrote:
> On Sunday, 23 July 2017 01:50:10 PDT Martin Koller wrote:
> > I found this symbol to be in the qgsttools_p lib but I fear the linker takes
> > the lib from a wrong path.
>
> If you already have Qt installed system-wide, please
On Sunday, 23 July 2017 01:50:10 PDT Martin Koller wrote:
> I found this symbol to be in the qgsttools_p lib but I fear the linker takes
> the lib from a wrong path.
If you already have Qt installed system-wide, please remove the development
files. You said you're on OpenSUSE, so just remove the
20 matches
Mail list logo
