P.S. I've also checked the wxwidgets code. The wxwidgets driver does
not link against libplplotwxwidgetsd and so there should not be a
problem there. The example using this class explicitly links against
the wxwidgets libraries as it uses some of the function directly so
again should be fine.
Jerry - if you have wxwidgets, please let me know if you encounter any
problems.
Regards
Andrew
On Thu, Aug 16, 2012 at 12:10:24PM +0100, Andrew Ross wrote:
>
> I've revisited this and taken a closer look at the code. There are no
> explicit references to QWidget in the qt driver other than pointers
> (which are fine). The QtPLWidget class does however inherit from
> QWidget and so some of its functions are used. It looks like although
> this code is all in libplplotqtd it results in QWidget functions being
> called from the qt driver implicitly. Now this seems to work ok on
> Linux, but not on OS-X.
>
> To do this "properly" the qt driver would need to link against QtCore,
> but not QtSvg or QtGui. I've included the changes to do this. Jerry,
> can you test the svn head to see if this works for you?
>
> Thanks
>
> Andrew
>
> On Wed, Aug 15, 2012 at 03:40:55AM -0700, Jerry wrote:
> > I would like to revive this thread from mid-May 2012 as I believe there are
> > still unresolved issues.
> >
> > The short version is that on OS X 10.7.4 (now more than a year old) I can't
> > build for the Qt driver after SVN version 12053.
> >
> > To clarify my remark below from my posting on 2012-05-13 21:15-0700,
> >
> > 12053 builds with -DDEFAULT_NO_QT_DEVICES=OFF
> > 12054 fails with -DDEFAULT_NO_QT_DEVICES=OFF builds with
> > -DDEFAULT_NO_QT_DEVICES=ON
> >
> > I tried building against both 4.7.0 and, since there was a warning when
> > building plpot that OS X 10.7 wasn't supported by 4.7.0, I also tried
> > building against Qt 4.8.2--no warning but _nearly_ the same error.
> >
> > Here's the long version, from building against Qt 4.8.2:
> >
> >
> > Linking CXX shared module qt.so
> > cd /usr/local/plplot_build_dir/drivers && /opt/local/bin/cmake -E
> > cmake_link_script CMakeFiles/qt.dir/link.txt --verbose=1
> > /usr/local/adacore-gnat-2011/bin/c++ -bundle
> > -Wl,-headerpad_max_install_names -o qt.so CMakeFiles/qt.dir/qt.cpp.o
> > ../src/libplplotd.11.0.0.dylib /usr/lib/libm.dylib
> > ../bindings/qt_gui/libplplotqtd.0.0.1.dylib ../src/libplplotd.11.0.0.dylib
> > Undefined symbols for architecture x86_64:
> > "QString::fromAscii_helper(char const*, int)", referenced from:
> > QString::QString(char const*) in qt.cpp.o
> > "QString::free(QString::Data*)", referenced from:
> > QString::~QString() in qt.cpp.o
> > "QCoreApplication::self", referenced from:
> > QCoreApplication::instance() in qt.cpp.o
> > "QWidget::move(QPoint const&)", referenced from:
> > QWidget::move(int, int) in qt.cpp.o
> > "QWidget::resize(QSize const&)", referenced from:
> > QWidget::resize(int, int) in qt.cpp.o
> > "qt_assert_x(char const*, char const*, char const*, int)", referenced
> > from:
> > QMutexLocker::QMutexLocker(QMutex*) in qt.cpp.o
> > "QMutex::unlock()", referenced from:
> > QMutex::unlockInline() in qt.cpp.o
> > "QMutex::lock()", referenced from:
> > QMutex::lockInline() in qt.cpp.o
> > "QApplication::QApplication(int&, char**, bool, int)", referenced from:
> > initQtApp(bool) in qt.cpp.o
> > "QSvgGenerator::size() const", referenced from:
> > plD_eop_svgqt(PLStream*) in qt.cpp.o
> > "QPicture::QPicture(int)", referenced from:
> > plD_init_qtwidget(PLStream*) in qt.cpp.o
> > plD_init_extqt(PLStream*) in qt.cpp.o
> > "QPainter::QPainter(QPaintDevice*)", referenced from:
> > plD_init_qtwidget(PLStream*) in qt.cpp.o
> > plD_init_extqt(PLStream*) in qt.cpp.o
> > "QWidget::setWindowTitle(QString const&)", referenced from:
> > plD_init_qtwidget(PLStream*) in qt.cpp.o
> > "qFlagLocation(char const*)", referenced from:
> > plD_init_qtwidget(PLStream*) in qt.cpp.o
> > "QObject::connect(QObject const*, char const*, QObject const*, char
> > const*, Qt::ConnectionType)", referenced from:
> > plD_init_qtwidget(PLStream*) in qt.cpp.o
> > "QPainter::~QPainter()", referenced from:
> > plD_init_qtwidget(PLStream*) in qt.cpp.o
> > plD_init_extqt(PLStream*) in qt.cpp.o
> > "QPicture::~QPicture()", referenced from:
> > plD_init_qtwidget(PLStream*) in qt.cpp.o
> > plD_init_extqt(PLStream*) in qt.cpp.o
> > "QWidget::raise()", referenced from:
> > plD_eop_qtwidget(PLStream*) in qt.cpp.o
> > "QCoreApplication::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)",
> > referenced from:
> > plD_eop_qtwidget(PLStream*) in qt.cpp.o
> > "QImage::scanLine(int)", referenced from:
> > plD_init_memqt(PLStream*) in qt.cpp.o
> > plD_eop_memqt(PLStream*) in qt.cpp.o
> > ld: symbol(s) not found for architecture x86_64
> > collect2: ld returned 1 exit status
> > make[2]: *** [drivers/qt.so] Error 1
> > make[1]: *** [drivers/CMakeFiles/qt.dir/all] Error 2
> > make: *** [all] Error 2
> >
> >
> > Jerry
> >
> >
> >
> > On May 14, 2012, at 10:54 AM, Alan W. Irwin wrote:
> >
> > > Hi Jerry and Andrew:
> > >
> > > On 2012-05-13 21:15-0700 Jerry wrote:
> > >
> > >> with -DNON_TRANSITIVE=ON \ (and tcl/tk still disabled), both 12121 and
> > >> 12165 failed to build. I then bisected between 12121 and 11957 and found:
> > >>
> > >> 12053 builds
> > >> 12054 fails
> > >
> > > Thanks very much, Jerry, for that essential information!
> > >
> > > Andrew, the rest of this e-mail is addressed largely to you.
> > >
> > > If you look at
> > >
> > > svn diff -x -w --revision=12053:12054 |less
> > >
> > > everything seems fine on the surface. The cmake logic
> > >
> > > target_link_libraries(plplotqt${LIB_TAG} LINK_INTERFACE_LIBRARIES)
> > > # This configures the pkg-config method to use non-transitive linking.
> > > set(PC_REQUIRES_TAG "Requires.private")
> > >
> > > simply tells both CMake and pkg-config (when we use the latter) when
> > > some application or shared object links to libplplotqtd not to link to
> > > the libplplotqtd Qt4 dependencies to avoid overlinking. Of course, this
> > > only works if we can assume that all of the applications/shared
> > > objects that are linking to libplplotqtd actually have no direct
> > > references to Qt4.
> > >
> > > But it appears this assumption is violated for at least
> > > qt.so (one important shared object that depends on libplplotqtd).
> > >
> > > software@raven> nm --demangle --undefined-only qt.so |grep QWidget
> > > U QtPLWidget::QtPLWidget(int, int, QWidget*)
> > > U QWidget::setWindowTitle(QString const&)
> > > U QWidget::move(QPoint const&)
> > > U QWidget::raise()
> > > U QWidget::resize(QSize const&)
> > >
> > > and similarly for other Qt4 classes I recognize such as QPainter. So
> > > qt.so clearly violates the above assumption. However, I don't know
> > > whether the _other_ applications (and shared objects?) that depend on
> > > libplplotqtd have direct references to Qt4 symbols or not. To help
> > > figure that out I suggest you remove the above CMake logic as an
> > > experiment, to see if you get overlinked warnings for other
> > > applications/shared objects which depend on libplplotqtd. Of course,
> > > in the past we have got overlinked warnings which were false positives
> > > so such warnings would have to be followed up with investigation using
> > > nm as above.
> > >
> > > Alan
> > > __________________________
> > > Alan W. Irwin
> > >
> > > Astronomical research affiliation with Department of Physics and
> > > Astronomy,
> > > University of Victoria (astrowww.phys.uvic.ca).
> > >
> > > Programming affiliations with the FreeEOS equation-of-state
> > > implementation for stellar interiors (freeeos.sf.net); the Time
> > > Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> > > software package (plplot.sf.net); the libLASi project
> > > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> > > and the Linux Brochure Project (lbproject.sf.net).
> > > __________________________
> > >
> > > Linux-powered Science
> > > __________________________
> >
> >
> > ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Plplot-devel mailing list
> > Plplot-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/plplot-devel
> >
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
