|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>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Davide Pesavento 2014-05-22 16:03:14 UTC
From bug #451456 comment #66: x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--as-needed -Wl,--no-undefined -shared -o libqsqlmysql.so .obj/main.o .obj/qsql_mysql.o .obj/moc_qsql_mysql_p.o -L/usr/lib64/mysql -Wl,-O1 -Wl,--as-needed -m64 -rdynamic -lmysqlclient_r -L/usr//lib64 -lz -lcrypt -lnsl -lm -L/usr/lib64/ -lssl -lcrypto -L/var/tmp/portage/dev-qt/qtsql-5.3.0_rc/work/qtbase-opensource-src-5.3.0-RC/lib -lQt5Sql -lQt5Core -lpthread .obj/qsql_mysql.o: In function `QMYSQLDriver::QMYSQLDriver(QObject*)': qsql_mysql.cpp:(.text+0x34c1): undefined reference to `QSqlError::QSqlError(QString const&, QString const&, QSqlError::ErrorType, QString const&)' From bug #451456 comment #70: It appears to be caused by mysql, and looks like QT_LFLAGS_MYSQL is populated by mysql_config --libs which outputs here -Wl,--hash-style=gnu -Wl,-O1 -Wl,--as-needed -rdynamic -L/usr/lib64/mysql -lmysqlclient -L/usr//lib64 -lz -lcrypt -lnsl -lm -L/usr/lib64/ -lssl -lcrypto So it looks like filterLibraryOptions in configure isn't working as expected.
Comment 1 Losier Blackheath 2014-05-26 03:39:12 UTC
So, I haven't updated my qt5 libraries yet, where do you guys think the -L/usr/lib64 entry comes from?
Comment 2 Michael Palimaka (kensington) 2014-05-26 06:54:41 UTC
(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.
Comment 3 Losier Blackheath 2014-05-26 08:33:34 UTC
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.
Comment 4 Michael Palimaka (kensington) 2014-05-26 08:36:04 UTC
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/.
Comment 5 Losier Blackheath 2014-05-26 09:20:27 UTC
(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)
Comment 6 Michael Palimaka (kensington) 2014-05-26 09:22:02 UTC
Yeah, see the upstream bug too for more info.
Comment 7 Michael Palimaka (kensington) 2014-07-16 10:32:41 UTC