libqwt-devel-5.1.1-alt1 Класс QwtData (qwt_data.h) содержит метод QwtData &operator=(const QwtData &) который не объявлен как виртуальный, но при этом libqwt.so.5.1.1 не содержит соответствующего символа. Решение: добавить virtual в описание метода.
Как воспроизвести проблему? В qwt_data.cpp есть QwtArrayData& QwtArrayData::operator=(const QwtArrayData &data)
Виталик, никто и не спорит, что в классе QwtArrayData этот метод реализован. Дело в том, что в классе QwtData этот метод не реализован. Обычные программы вряд ли будут его использовать, но вот некоторые кодогенераторы... Проверить можно вот на чем: ftp://ftp.gis-auto.ru/ruby-qt4-1.4.10-alt2.src.rpm Если в нем оторвать первый кусок патча ruby-qt4-alt-fix-kalyptus.patch, который относится к kalyptusCxxToSmoke.pm (это как раз и есть workaround данной проблемы), то в итоге получим unresolved symbol у libsmokeqt именно на QwtData &operator=(const QwtData &).
qwt_data.h: class QWT_EXPORT QwtData: ... /*! Assignment operator (virtualized) */ QwtData &operator=(const QwtData &); Автор явно имел какой-то тайный умысел, написав слово virtualized. Если я добавлю слово virtual, это изменит ABI библиотеки. Возможно стоит авторам ruby-qt4 договориться с авторами libqwt? :)
(In reply to comment #3) > Автор явно имел какой-то тайный умысел, написав слово virtualized. Что именно имел в виду автор, для меня загадка. Возможно он просто забыл реализовать этот метод или объявить его виртуальным. А т.к. в обычной ситуации это ничем не грозит, то скорее всего он даже не в курсе. > Если я добавлю слово virtual, это изменит ABI библиотеки. По всей видимости. > Возможно стоит авторам ruby-qt4 договориться с авторами libqwt? :) Теперь это уже должна быть головная боль zerg@, если он все-таки собирается делать ruby-qt4 из kde4bindings и собирать это хозяйство с qwt (в последнем я не уверен).
