Summary: | [qt overlay] dev-qt/qtsql:5 tries to link against already installed version | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Davide Pesavento <pesa> |
Component: | [OLD] Library | Assignee: | Qt Bug Alias <qt> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | losier.cc, uwelk |
Priority: | Highest | Keywords: | UPSTREAM |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugreports.qt-project.org/browse/QTBUG-39216 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 454132 |
Description
Davide Pesavento (RETIRED)
2014-05-22 16:03:14 UTC
So, I haven't updated my qt5 libraries yet, where do you guys think the -L/usr/lib64 entry comes from? (In reply to Losier Blackheath from comment #1) > So, I haven't updated my qt5 libraries yet, where do you guys think the > -L/usr/lib64 entry comes from? In this case it appears to come from mysql_config --libs, so the workaround is to uninstall qtsql then install it, or update it with mysql USE flag disabled. Well, the problem comes from the external libraries, and this is terrible since -L/usr/lib64 entries appear in many pkgconfig files. Maybe we need another patch in qmake to stop introducing this entry to makefile variables in order to solve the issue thoroughly. There is code in place already to strip entries like that, but I believe that it assumes it will be given paths in the form of '/usr/lib64', so it doesn't handle the /usr//lib64 and /usr/lib64/. (In reply to Michael Palimaka (kensington) from comment #4) > There is code in place already to strip entries like that, but I believe > that it assumes it will be given paths in the form of '/usr/lib64', so it > doesn't handle the /usr//lib64 and /usr/lib64/. I have some difficulty understanding the grammar in qmake scripts. But I do believe qmake has a mechanism normalizing the path. And the previous bug, in fact, was solved by fixing the original routine replacing -L/var/tmp/portage... with -L/usr/lib64 in prl files, not by fixing the routine processing libs the building package is going to link to. (You can do a small experiment by adding -L/usr/lib64 into prl files manually, and see whether -L/usr/lib64 would appear in ld arguments) Yeah, see the upstream bug too for more info. |