On sábado, 21 de janeiro de 2017 17:31:34 PST René J. V. Bertin wrote:
> Thiago Macieira wrote:
> >> OK, thanks, I didn't catch that bit from what Google told me. So I would
> >> not have gotten the same error if the symbol were present with another
> >> ELF version?
> >
> > No, you'd have got
Thiago Macieira wrote:
>> OK, thanks, I didn't catch that bit from what Google told me. So I would not
>> have gotten the same error if the symbol were present with another ELF
>> version?
>
> No, you'd have got the same error message...
Hmm, is that useful, not being able to distinguish
On sábado, 21 de janeiro de 2017 09:50:50 PST René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > A red herring. You've focused on the wrong part of the information.
> >
> > The linker told you that it can't find a symbol with a given ELF version.
> > That's because the symbol isn't present at
Thiago Macieira wrote:
> A red herring. You've focused on the wrong part of the information.
>
> The linker told you that it can't find a symbol with a given ELF version.
> That's because the symbol isn't present at all, with any ELF version.
OK, thanks, I didn't catch that bit from what
On sexta-feira, 20 de janeiro de 2017 18:27:31 PST René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > It is used in QtWidgets and possibly other modules. It may have suffered
> > from the problem of loading the wrong library at runtime, but didn't
> > crash because the new uic didn't use any
Thiago Macieira wrote:
> It is used in QtWidgets and possibly other modules. It may have suffered from
> the problem of loading the wrong library at runtime, but didn't crash because
> the new uic didn't use any symbols that are new in 5.8.
That'd be an explanation, but is that what the
On sexta-feira, 20 de janeiro de 2017 10:51:20 PST René J. V. Bertin wrote:
> > But uic should be suffering from this
>
> Too late to check now :)
> Is uic used during the build? If it is it was clearly not "suffering from
> this"!
It is used in QtWidgets and possibly other modules. It may have
Thiago Macieira wrote:
> The tools affected are those that can be bootstrapped but weren't (because
> it's not a cross compilation). Since they weren't bootstrapped, they link to
> the Qt libraries being compiled, which results in the linking problem.
Terminology maybe, but I thought the
On quinta-feira, 19 de janeiro de 2017 22:15:38 PST Oswald Buddenhagen wrote:
> the other solution would be not building host tools at all when doing a
> cross-build, but requiring a native build as a basis.
Long-term we should do that, but we need to support the current way for a
couple of
On Thu, Jan 19, 2017 at 02:31:29PM +0100, René J.V. Bertin wrote:
> Thiago Macieira wrote:
> > It must be the lack of -Wl,--enable-new-dtags: can you confirm qtdiag has it
> > but lrelease doesn't?
>
> Yep. Neither do lupdate and lconvert, but linguist does (they come all from
> the linguist
Thiago Macieira wrote:
> Can you compare the command-lines used to link those two applications? What's
> different?
qtdiag:
g++ -m64 -Wl,--gc-sections -Wl,--enable-new-dtags -Wl,-z,origin
-Wl,-rpath,\$ORIGIN/../lib -Wl,-rpath,/opt/local/lib
-Wl,-rpath,/opt/local/libexec/qt5/lib
On Wed, Jan 18, 2017 at 03:53:20PM -0800, Thiago Macieira wrote:
> Ossi: what was the conclusion of our discussion on --enable-new-dtags?
>
it's now enabled by default. i have no clue why it would be wrong for
lrelease. a more complete survey of the executables in the qt build dir
would be
On quarta-feira, 18 de janeiro de 2017 21:24:45 PST René J. V. Bertin wrote:
> For lrelease:
> RPATH
> $ORIGIN/../lib:/opt/local/lib:/opt/local/libexec/qt5/lib
>
> For qtdiag:
> RUNPATH
> $ORIGIN/../lib:/opt/local/lib:/opt/local/libexec/qt5/lib
>
> R
Can you
Thiago Macieira wrote:
> I see that the QStringList::join(QLatin1String) overload was added in 5.8.
> Does t mean that the installed version is 5.7 or earlier?
Yes, 5.7.1 .
> Ok, so that is the problem. The question is why LD_LIBRARY_PATH was not
> properly set. Or...
During the build
On quarta-feira, 18 de janeiro de 2017 18:46:53 PST René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > Can you confirm whether the problem is
> >
> > a) that _ZN9QtPrivate16QStringList_joinERK11QStringList13QLatin1String
> > isn't>
> > present in QtCore at all; or
>
> The symbol is present
Thiago Macieira wrote:
> Can you confirm whether the problem is
>
> a) that _ZN9QtPrivate16QStringList_joinERK11QStringList13QLatin1String isn't
> present in QtCore at all; or
The symbol is present in the 5.8.0 version in the build tree, but not in the
installed version.
> b) that the
On quarta-feira, 18 de janeiro de 2017 14:51:15 PST René J.V. Bertin wrote:
> symbol _ZN9QtPrivate16QStringList_joinERK11QStringList13QLatin1String,
> version Qt_5 not defined in file libQt5Core.so.5 with link time reference
Can you confirm whether the problem is
a) that
Hello,
On linux I get the following error doing a toplevel style build of most
components in qt-everywhere 5.8 :
make: Entering directory `/path/to/build/qttranslations'
cd translations/ && ( test -e Makefile || /path/to/build/qtbase/bin/qmake -o
Makefile
18 matches
Mail list logo
