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.
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.
Fixed in git.