When sqlite is built with the "threadsafe" use flag enabled, qt-sql fails to build with the following error: SQLite auto-detection... () x86_64-pc-linux-gnu-g++ -c -pipe -O2 -Wall -W -I../../../mkspecs/linux-g++ -I. -I/usr/include/mysql -I/usr/include/postgresql/pgsql -I/usr/include/freetype2 -o sqlite.o sqlite.cpp x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,-rpath,/usr/lib64/qt4 -o sqlite sqlite.o -lsqlite3 -L/usr/lib64 -L/usr/lib64/mysql /usr/lib64/libsqlite3.so: undefined reference to `pthread_mutex_trylock' /usr/lib64/libsqlite3.so: undefined reference to `pthread_mutexattr_settype' /usr/lib64/libsqlite3.so: undefined reference to `pthread_mutexattr_destroy' /usr/lib64/libsqlite3.so: undefined reference to `pthread_create' /usr/lib64/libsqlite3.so: undefined reference to `pthread_mutexattr_init' /usr/lib64/libsqlite3.so: undefined reference to `pthread_join' collect2: ld returned 1 exit status gmake: *** [sqlite] Error 1 qt-sql-4.6.3 sqlite-3.6.23.1 Reproducible: Always
In that case, lets go one level deeper: see if rebuilding sqlite helps, if not, attach its build log.
In both cases, attach the build.log and environment files of the failed qt-sql emerge.
Tracked down the source of the problem. I'm testing to see what advantages can be gained for SMP CPUs with OpenMP. Apparently when building with the -fopenmp compiler flag set, some packages fail to properly link against pthreads. If I build sqlite without -fopenmp then qt-sql builds successfully. If I build sqlite with -fopenmp then qt-sql fails. If I build sqlite with -fopenmp AND -lpthreads then qt-sql builds successfully. I had the exact same problem where net-libs/libasyncns-0.8 would only build with -fopenmp if -lpthreads was also explicitly set in the CFLAGS / CXXFLAGS. I imagine -fopenmp is not officially supported, so unless you want to look into this further or pass it on for somebody else to look at, you could probably mark as invalid.
This maybe calls for a strip-flags from flag-o-matic.eclass
I am against stripping flags on our eclass but I want to wait for the rest of the herd to speak up
there are a lot of cflags out there that can break more than just Qt libraries. we could create an array/list of damaging cflags that will be automatically filtered by the eclass, but I'm afraid this will quickly become hard to maintain. someone will have to check the list from time to time to see if its valid, then we also have those cases where one cflag needs another one in order not to fail! this bug is a good example of that :p i think a wiki page or other means of documentation listing these things, what works and what doesn't, would be more suitable than blindly filtering stuff :)
I think sqlite should put -lpthread in its pkgconfig file if it actually requires it for linking. This is not a qt-sql bug IMHO.
(In reply to comment #7) > I think sqlite should put -lpthread in its pkgconfig file if it actually > requires it for linking. -lpthread is already there and is required only for static linking. $ cat /usr/lib64/pkgconfig/sqlite3.pc # Package Information for pkg-config prefix=/usr exec_prefix=${prefix} libdir=/usr/lib64 includedir=${prefix}/include Name: SQLite Description: SQL database engine Version: 3.6.23.1 Libs: -L${libdir} -lsqlite3 Libs.private: -ldl -lpthread Cflags: -I${includedir} $ pkg-config sqlite3 --libs -lsqlite3 $ pkg-config sqlite3 --libs --static -lsqlite3 -ldl -lpthread $ scanelf -qyF '%F: %n' `qlist dev-db/sqlite | sort` /usr/bin/sqlite3: libsqlite3.so.0,libreadline.so.6,libc.so.6 /usr/lib64/libsqlite3.so.0.8.6: libdl.so.2,libpthread.so.0,libicui18n.so.44,libicuuc.so.44,libc.so.6 /usr/lib64/sqlite-3.6.23.1/libtclsqlite3.so: libsqlite3.so.0,libc.so.6
We could append LIBS += -lpthread on config.tests/unix/sqlite.pro file
(In reply to comment #8) > (In reply to comment #7) > > I think sqlite should put -lpthread in its pkgconfig file if it actually > > requires it for linking. > > -lpthread is already there and is required only for static linking. > I know that '-lpthread' is in Libs.private. We are not talking about static linking though. AFAICS libpthread is always required when using openmp.
(In reply to comment #10) > I know that '-lpthread' is in Libs.private. We are not talking about static > linking though. /usr/lib64/libsqlite3.so.0.8.6 is already linked against libpthread.so.0. > AFAICS libpthread is always required when using openmp. Then gcc should internally pass -lpthread to ld.
(In reply to comment #11) > (In reply to comment #10) > > I know that '-lpthread' is in Libs.private. We are not talking about static > > linking though. > > /usr/lib64/libsqlite3.so.0.8.6 is already linked against libpthread.so.0. > And how should qt-sql know that?
(In reply to comment #12) > (In reply to comment #11) > > /usr/lib64/libsqlite3.so.0.8.6 is already linked against libpthread.so.0. > > And how should qt-sql know that? x11-libs/qt-sql doesn't need to know it. Libraries of x11-libs/qt-sql should be directly linked only against directly used libraries.
bug 325771, bug 186316, bug 186311... it's applications job to provide openmp pragmas (the code) and then the configure checks if -fopenmp / gomp is supported or not and then use it... it's not something you should add yourself to make.conf
