When updating from x11-libs/qscintilla-2.6.2 to x11-libs/qscintilla-2.7.1 /usr/lib64/qt4/plugins/designer/libqscintillaplugin.so links to libqscintilla2.so.8 instead of libqscintilla2.so.9. Rebuilding x11-libs/qscintilla again solves problem. revdep-rebuild output: * Checking dynamic linking consistency [ 26% ] * broken /usr/bin/sqliteman (requires libqscintilla2.so.8) [ 84% ] * broken /usr/lib64/qt4/plugins/designer/libqscintillaplugin.so (requires libqscintilla2.so.8) [ 97% ] * broken /usr/lib/qt4/plugins/designer/libqscintillaplugin.so (requires libqscintilla2.so.8) [ 100% ] * Generated new 3_broken.rr * Assigning files to packages * /usr/bin/sqliteman -> dev-db/sqliteman * /usr/lib64/qt4/plugins/designer/libqscintillaplugin.so -> x11-libs/qscintilla * /usr/lib/qt4/plugins/designer/libqscintillaplugin.so -> x11-libs/qscintilla * Generated new 4_raw.rr and 4_owners.rr
I thought this should have been fixed by this commit, although you opened the bug a month later... 11 Mar 2013; Michael Palimaka <kensington@gentoo.org> +files/qscintilla-2.7.1-designer.patch, qscintilla-2.7.1.ebuild: Add patch to fix build of designer plugin when qscintilla is not installed. In any case I can't reproduce now, so closing as WFM.
Sorry, I *can* reproduce when upgrading from 2.7.2 to 2.8.3 # emerge -pv qscintilla These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-libs/qscintilla-2.8.3:0/11 USE="-doc" 0 kB # scanelf -qn /usr/lib64/qt4/plugins/designer/libqscintillaplugin.so libqscintilla2.so.9,libQtGui.so.4,libQtCore.so.4,libstdc++.so.6,libgcc_s.so.1,libc.so.6 /usr/lib64/qt4/plugins/designer/libqscintillaplugin.so libqscintillaplugin.so is linked to the old libqscintilla2.so.9
x86_64-pc-linux-gnu-g++ -Wl,--hash-style=gnu -Wl,-O1 -Wl,--as-needed -shared -o libqscintillaplugin.so qscintillaplugin.o moc_qscintillaplugin.o -L/usr/lib64/qt4 -L../Qt4Qt5 -lqscintilla2 -lQtScript -L/usr/lib64/qt4 -lQtXml -lQtGui -L/usr/X11R6/lib -lQtCore -lQtDesigner -lpthread "-L/usr/lib64/qt4 -L../Qt4Qt5 -lqscintilla2" doesn't look good...
The reason for this turned out to be much "lower" in the stack than I expected, but anyway... it's now fixed in 2.8.4
For the record: it is necessary (albeit slightly hackish) to add "../Qt4Qt5" to QMAKE_LIBDIR because the content of that variable is eventually prepended to all other library paths on the final linker command line, and the problem is that features/qt.prf adds QMAKE_LIBDIR_QT (i.e. /usr/lib64/qt4) to QMAKE_LIBDIR, so there's no way to make -L../Qt4Qt5 appear before -L/usr/lib64/qt4 unless ../Qt4Qt5 is also added to the same QMAKE_LIBDIR variable.
Your fix is incomplete. qscintillaplugin.cpp contains '#include <Qsci/qsciscintilla.h>'. ... make x86_64-pc-linux-gnu-g++ -c -march=native -O2 -fno-ident -frecord-gcc-switches -pipe -Wall -D_REENTRANT -Wall -W -fPIC -DQT_NO_DEBUG -DQT_PLUGIN -DQT_SCRIPT_LIB -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQDESIGNER_EXPORT_WIDGETS -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtDesigner -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtScript -I/usr/include/qt4 -I../Qt4Qt5 -I. -o qscintillaplugin.o qscintillaplugin.cpp ... -I/usr/include/qt4 is before -I../Qt4Qt5, so /usr/include/qt4/Qsci/qsciscintilla.h is used instead of ../Qt4Qt5/Qsci/qsciscintilla.h. You can add e.g. '#error' to /usr/include/qt4/Qsci/qsciscintilla.h to see it. A fix used by me in x11-libs/qscintilla::progress instead of a patch is to call eqmake4 in designer-Qt4Qt5 directory in this way: CXXFLAGS="${CXXFLAGS}${CXXFLAGS:+ }-I../Qt4Qt5" LDFLAGS="${LDFLAGS}${LDFLAGS:+ }-L../Qt4Qt5" eqmake4
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #6) https://code.google.com/p/gentoo-progress/source/browse/overlays/progress/x11-libs/qscintilla/qscintilla-2.8.4-r1000.ebuild#39
I don't like abusing CXXFLAGS for include paths. Why haven't you used CPPFLAGS or append-cppflags?
CPPFLAGS is ignored by eqmake4.
Ah right... sometimes I forget that qmake sucks and doesn't distinguish between the two. I guess we can just use append-{cxx,ld}flags then, and get rid of the patch.
Fixed in 2.8.4-r1