From: Jerry <lan...@qw...> - 2012-05-09 10:21:19
|
I can no longer build from the current SVN version. I _can_ build from a rather old (months--not sure how many months) SVN that I have saved. As far as I know the only two things that have changed are PLplot version and OS version--I updated OS X from 10.6.8 Snow Leopard to 10.7.x Lion recently. The only variable I have easy control of is PLplot version. I assume that reverting to Snow Leopard would be painful and of questionable use. Here's the problem: Linking C shared library libplplottcltkd.dylib cd /usr/local/plplot_build_dir/bindings/tcl && "/Applications/CMake 2.8-6.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/plplottcltkd.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2011/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -single_module -compatibility_version 9.0.0 -current_version 9.2.0 -o libplplottcltkd.9.2.0.dylib -install_name /usr/local/plplot_build_dir/bindings/tcl/libplplottcltkd.9.dylib CMakeFiles/plplottcltkd.dir/tclAPI.c.o CMakeFiles/plplottcltkd.dir/tclMain.c.o CMakeFiles/plplottcltkd.dir/__/tk/Pltk_Init.c.o CMakeFiles/plplottcltkd.dir/__/tk/plframe.c.o CMakeFiles/plplottcltkd.dir/__/tk/plr.c.o CMakeFiles/plplottcltkd.dir/__/tk/tcpip.c.o CMakeFiles/plplottcltkd.dir/__/tk/tkMain.c.o libtclmatrixd.9.2.0.dylib ../../src/libplplotd.11.0.0.dylib -framework tcl -framework tk ../../lib/csa/libcsirocsa.0.0.1.dylib ../../lib/qsastime/libqsastime.0.0.1.dylib Undefined symbols for architecture x86_64: "_XLookupString", referenced from: _PlFrameKeyEH in plframe.c.o "_XFlush", referenced from: _DisplayPlFrame in plframe.c.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[2]: *** [bindings/tcl/libplplottcltkd.9.2.0.dylib] Error 1 make[1]: *** [bindings/tcl/CMakeFiles/plplottcltkd.dir/all] Error 2 make: *** [all] Error 2 I should add that there has been one other change but I don't think it's relevant--I have (once again!) installed MacPorts which is a shadow quasi-OS-and-more which purports to be completely independent of OS X, and installs in /opt/local. However, and I mention this only because I don't understand what is happening above but see some possible tcl issues, MacPorts does place this symlink /Library/Tcl/macports1.0 which points to /opt/local/share/macports/Tcl/macports1.0/macports_autoconf.tcl /opt/local/share/macports/Tcl/macports1.0/macports_dlist.tcl /opt/local/share/macports/Tcl/macports1.0/macports_fastload.tcl /opt/local/share/macports/Tcl/macports1.0/macports_index.tcl /opt/local/share/macports/Tcl/macports1.0/macports_util.tcl /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib /opt/local/share/macports/Tcl/macports1.0/macports.tcl /opt/local/share/macports/Tcl/macports1.0/pkgIndex.tcl Jerry |
From: Andrew R. <and...@us...> - 2012-05-09 21:13:23
|
Jerry, It looks like this could be related to the recent changes to clean up redundant library linkages. As a quick check, you could try setting the NON_TRANSITIVE option to OFF to disable this. Does this help? If so we can start delving into what is happening. Looks like the linkage with the X11 library is missing, we just need to figure out why. Andrew On Wed, May 09, 2012 at 03:21:07AM -0700, Jerry wrote: > I can no longer build from the current SVN version. I _can_ build from a rather old (months--not sure how many months) SVN that I have saved. As far as I know the only two things that have changed are PLplot version and OS version--I updated OS X from 10.6.8 Snow Leopard to 10.7.x Lion recently. The only variable I have easy control of is PLplot version. I assume that reverting to Snow Leopard would be painful and of questionable use. > > Here's the problem: > > > > Linking C shared library libplplottcltkd.dylib > cd /usr/local/plplot_build_dir/bindings/tcl && "/Applications/CMake 2.8-6.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/plplottcltkd.dir/link.txt --verbose=1 > /usr/local/adacore-gnat-2011/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -single_module -compatibility_version 9.0.0 -current_version 9.2.0 -o libplplottcltkd.9.2.0.dylib -install_name /usr/local/plplot_build_dir/bindings/tcl/libplplottcltkd.9.dylib CMakeFiles/plplottcltkd.dir/tclAPI.c.o CMakeFiles/plplottcltkd.dir/tclMain.c.o CMakeFiles/plplottcltkd.dir/__/tk/Pltk_Init.c.o CMakeFiles/plplottcltkd.dir/__/tk/plframe.c.o CMakeFiles/plplottcltkd.dir/__/tk/plr.c.o CMakeFiles/plplottcltkd.dir/__/tk/tcpip.c.o CMakeFiles/plplottcltkd.dir/__/tk/tkMain.c.o libtclmatrixd.9.2.0.dylib ../../src/libplplotd.11.0.0.dylib -framework tcl -framework tk ../../lib/csa/libcsirocsa.0.0.1.dylib ../../lib/qsastime/libqsastime.0.0.1.dylib > Undefined symbols for architecture x86_64: > "_XLookupString", referenced from: > _PlFrameKeyEH in plframe.c.o > "_XFlush", referenced from: > _DisplayPlFrame in plframe.c.o > ld: symbol(s) not found for architecture x86_64 > collect2: ld returned 1 exit status > make[2]: *** [bindings/tcl/libplplottcltkd.9.2.0.dylib] Error 1 > make[1]: *** [bindings/tcl/CMakeFiles/plplottcltkd.dir/all] Error 2 > make: *** [all] Error 2 > > > > I should add that there has been one other change but I don't think it's relevant--I have (once again!) installed MacPorts which is a shadow quasi-OS-and-more which purports to be completely independent of OS X, and installs in /opt/local. However, and I mention this only because I don't understand what is happening above but see some possible tcl issues, MacPorts does place this symlink > > /Library/Tcl/macports1.0 > > which points to > > /opt/local/share/macports/Tcl/macports1.0/macports_autoconf.tcl > /opt/local/share/macports/Tcl/macports1.0/macports_dlist.tcl > /opt/local/share/macports/Tcl/macports1.0/macports_fastload.tcl > /opt/local/share/macports/Tcl/macports1.0/macports_index.tcl > /opt/local/share/macports/Tcl/macports1.0/macports_util.tcl > /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib > /opt/local/share/macports/Tcl/macports1.0/macports.tcl > /opt/local/share/macports/Tcl/macports1.0/pkgIndex.tcl > > Jerry > ------------------------------------------------------------------------------ > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Alan W. I. <ir...@be...> - 2012-05-09 21:54:09
|
On 2012-05-09 03:21-0700 Jerry wrote: > I can no longer build from the current SVN version. I _can_ build from a rather old (months--not sure how many months) SVN that I have saved. As far as I know the only two things that have changed are PLplot version and OS version--I updated OS X from 10.6.8 Snow Leopard to 10.7.x Lion recently. The only variable I have easy control of is PLplot version. I assume that reverting to Snow Leopard would be painful and of questionable use. > > Here's the problem: > > > > Linking C shared library libplplottcltkd.dylib > cd /usr/local/plplot_build_dir/bindings/tcl && "/Applications/CMake 2.8-6.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/plplottcltkd.dir/link.txt --verbose=1 > /usr/local/adacore-gnat-2011/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -single_module -compatibility_version 9.0.0 -current_version 9.2.0 -o libplplottcltkd.9.2.0.dylib -install_name /usr/local/plplot_build_dir/bindings/tcl/libplplottcltkd.9.dylib CMakeFiles/plplottcltkd.dir/tclAPI.c.o CMakeFiles/plplottcltkd.dir/tclMain.c.o CMakeFiles/plplottcltkd.dir/__/tk/Pltk_Init.c.o CMakeFiles/plplottcltkd.dir/__/tk/plframe.c.o CMakeFiles/plplottcltkd.dir/__/tk/plr.c.o CMakeFiles/plplottcltkd.dir/__/tk/tcpip.c.o CMakeFiles/plplottcltkd.dir/__/tk/tkMain.c.o libtclmatrixd.9.2.0.dylib ../../src/libplplotd.11.0.0.dylib -framework tcl -framework tk ../../lib/csa/libcsirocsa.0.0.1.dylib ../../lib/qsastime/libqsastime.0.0.1.dylib > Undefined symbols for architecture x86_64: > "_XLookupString", referenced from: > _PlFrameKeyEH in plframe.c.o > "_XFlush", referenced from: > _DisplayPlFrame in plframe.c.o > ld: symbol(s) not found for architecture x86_64 > collect2: ld returned 1 exit status > make[2]: *** [bindings/tcl/libplplottcltkd.9.2.0.dylib] Error 1 > make[1]: *** [bindings/tcl/CMakeFiles/plplottcltkd.dir/all] Error 2 > make: *** [all] Error 2 > > > > I should add that there has been one other change but I don't think it's relevant--I have (once again!) installed MacPorts which is a shadow quasi-OS-and-more which purports to be completely independent of OS X, and installs in /opt/local. However, and I mention this only because I don't understand what is happening above but see some possible tcl issues, MacPorts does place this symlink > > /Library/Tcl/macports1.0 > > which points to > > /opt/local/share/macports/Tcl/macports1.0/macports_autoconf.tcl > /opt/local/share/macports/Tcl/macports1.0/macports_dlist.tcl > /opt/local/share/macports/Tcl/macports1.0/macports_fastload.tcl > /opt/local/share/macports/Tcl/macports1.0/macports_index.tcl > /opt/local/share/macports/Tcl/macports1.0/macports_util.tcl > /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib > /opt/local/share/macports/Tcl/macports1.0/macports.tcl > /opt/local/share/macports/Tcl/macports1.0/pkgIndex.tcl > Hi Jerry: My guess is the the issue is some conflict between what -framework tcl means in the above command line (for example, that probably refers to the system version of Tcl) versus your macport install of Tcl. However, I don't have any Mac OS X/macports experience so one of the others here with such experience might be able to help you further. However, unless and until you can get such detailed help with the above Tcl linking issue, I suggest for now you simply work around the issue by disabling the Tcl part of the PLplot build using the -DENABLE_tcl=OFF cmake option. 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 __________________________ |
From: Jerry <lan...@qw...> - 2012-08-15 10:41:09
|
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 > __________________________ |
From: Andrew R. <and...@us...> - 2012-08-16 11:10:35
|
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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Jerry <lan...@qw...> - 2012-08-17 03:37:18
|
On Aug 16, 2012, at 4:10 AM, 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 Thanks for looking into this, Andrew. The results that I reported in my previous e-mail (reviving the thread) were with -DNON_TRANSITIVE=OFF. With your fix to 12216, I can now build 12216 for Qt. Problem fixed. When I switch to -DNON_TRANSITIVE=ON, however, the build fails like this: 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 -lQtCore ld: library not found for -lQtCore 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 I gather that with -DNON_TRANSITIVE=OFF the linking happens with possible redundancies. FWIW, the above line looks like it is using the AdaCore c++ which comes with the Ada (GNAT) compiler. (Apple does not ship Ada so we have to get it from other places.) The build process is apparently finding it rather the Apple compiler which is probably /usr/bin/gcc. Jerry |
From: Alan W. I. <ir...@be...> - 2012-08-17 16:59:41
|
On 2012-08-16 20:37-0700 Jerry wrote: > Thanks for looking into this, Andrew. > > The results that I reported in my previous e-mail (reviving the thread) were with -DNON_TRANSITIVE=OFF. With your fix to 12216, I can now build 12216 for Qt. Problem fixed. > > When I switch to -DNON_TRANSITIVE=ON, however, the build fails like this: > > 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 -lQtCore > ld: library not found for -lQtCore > 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 Andrew, just to interject here, I believe the source of the error is the lack of -L option in the above line to tell the linker where to find QtCore. QT_LIBRARIES should have that information along with a bunch of -l options that you do not want for the -DNON_TRANSITIVE=ON case. So probably the thing to do here is to parse the QT_LIBRARIES variable to remove the unwanted -l options. Since you are working through a 3rd party (Jerry) for a platform you are not familiar with (OS X), I suggest you use the CMake message command to always print out both QT_LIBRARIES, and its parsed form just in case Jerry finds any further difficulty with the parsed version. 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 __________________________ |
From: Jerry <lan...@qw...> - 2012-05-10 08:34:41
|
On May 9, 2012, at 1:42 PM, Andrew Ross wrote: > > Jerry, > > It looks like this could be related to the recent changes to clean up redundant library linkages. As a quick check, you could try setting the NON_TRANSITIVE option to OFF to disable this. Does this help? If so we can start delving into what is happening. Looks like the linkage with the X11 library is missing, we just need to figure out why. > > Andrew I actually tried this before I first posted, and with -DNON_TRANSITIVE=OFF I got exactly the same results (except with a couple more libraries listed)--everything from Undefined symbols for architecture x86_64: onward is exactly the same. Jerry > > On Wed, May 09, 2012 at 03:21:07AM -0700, Jerry wrote: >> I can no longer build from the current SVN version. I _can_ build from a rather old (months--not sure how many months) SVN that I have saved. As far as I know the only two things that have changed are PLplot version and OS version--I updated OS X from 10.6.8 Snow Leopard to 10.7.x Lion recently. The only variable I have easy control of is PLplot version. I assume that reverting to Snow Leopard would be painful and of questionable use. >> >> Here's the problem: >> >> >> >> Linking C shared library libplplottcltkd.dylib >> cd /usr/local/plplot_build_dir/bindings/tcl && "/Applications/CMake 2.8-6.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/plplottcltkd.dir/link.txt --verbose=1 >> /usr/local/adacore-gnat-2011/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -single_module -compatibility_version 9.0.0 -current_version 9.2.0 -o libplplottcltkd.9.2.0.dylib -install_name /usr/local/plplot_build_dir/bindings/tcl/libplplottcltkd.9.dylib CMakeFiles/plplottcltkd.dir/tclAPI.c.o CMakeFiles/plplottcltkd.dir/tclMain.c.o CMakeFiles/plplottcltkd.dir/__/tk/Pltk_Init.c.o CMakeFiles/plplottcltkd.dir/__/tk/plframe.c.o CMakeFiles/plplottcltkd.dir/__/tk/plr.c.o CMakeFiles/plplottcltkd.dir/__/tk/tcpip.c.o CMakeFiles/plplottcltkd.dir/__/tk/tkMain.c.o libtclmatrixd.9.2.0.dylib ../../src/libplplotd.11.0.0.dylib -framework tcl -framework tk ../../lib/csa/libcsirocsa.0.0.1.dylib ../../lib/qsastime/libqsastime.0.0.1.dylib >> Undefined symbols for architecture x86_64: >> "_XLookupString", referenced from: >> _PlFrameKeyEH in plframe.c.o >> "_XFlush", referenced from: >> _DisplayPlFrame in plframe.c.o >> ld: symbol(s) not found for architecture x86_64 >> collect2: ld returned 1 exit status >> make[2]: *** [bindings/tcl/libplplottcltkd.9.2.0.dylib] Error 1 >> make[1]: *** [bindings/tcl/CMakeFiles/plplottcltkd.dir/all] Error 2 >> make: *** [all] Error 2 >> >> >> >> I should add that there has been one other change but I don't think it's relevant--I have (once again!) installed MacPorts which is a shadow quasi-OS-and-more which purports to be completely independent of OS X, and installs in /opt/local. However, and I mention this only because I don't understand what is happening above but see some possible tcl issues, MacPorts does place this symlink >> >> /Library/Tcl/macports1.0 >> >> which points to >> >> /opt/local/share/macports/Tcl/macports1.0/macports_autoconf.tcl >> /opt/local/share/macports/Tcl/macports1.0/macports_dlist.tcl >> /opt/local/share/macports/Tcl/macports1.0/macports_fastload.tcl >> /opt/local/share/macports/Tcl/macports1.0/macports_index.tcl >> /opt/local/share/macports/Tcl/macports1.0/macports_util.tcl >> /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib >> /opt/local/share/macports/Tcl/macports1.0/macports.tcl >> /opt/local/share/macports/Tcl/macports1.0/pkgIndex.tcl >> >> Jerry >> ------------------------------------------------------------------------------ >> 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 >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-devel >> |
From: Arjen M. <arj...@de...> - 2012-05-10 09:46:23
|
Hi Jerry, I am not familiar with OS X to any useful extent, but from the error messages it is clear that the Xlib library for your platform is missing two routines that are normally present. Perhaps they require an extra library. I will see if I can find more information on this issue. Regards, Arjen On Thu, 10 May 2012 01:34:24 -0700 Jerry <lan...@qw...> wrote: > > On May 9, 2012, at 1:42 PM, Andrew Ross wrote: > >> >> Jerry, >> >> It looks like this could be related to the recent >>changes to clean up redundant library linkages. As a >>quick check, you could try setting the NON_TRANSITIVE >>option to OFF to disable this. Does this help? If so we >>can start delving into what is happening. Looks like the >>linkage with the X11 library is missing, we just need to >>figure out why. >> >> Andrew > > I actually tried this before I first posted, and with >-DNON_TRANSITIVE=OFF I got exactly the same results >(except with a couple more libraries listed)--everything >from > > Undefined symbols for architecture x86_64: > > onward is exactly the same. > > Jerry >> >> On Wed, May 09, 2012 at 03:21:07AM -0700, Jerry wrote: >>> I can no longer build from the current SVN version. I >>>_can_ build from a rather old (months--not sure how many >>>months) SVN that I have saved. As far as I know the only >>>two things that have changed are PLplot version and OS >>>version--I updated OS X from 10.6.8 Snow Leopard to >>>10.7.x Lion recently. The only variable I have easy >>>control of is PLplot version. I assume that reverting to >>>Snow Leopard would be painful and of questionable use. >>> >>> Here's the problem: >>> >>> >>> >>> Linking C shared library libplplottcltkd.dylib >>> cd /usr/local/plplot_build_dir/bindings/tcl && >>>"/Applications/CMake 2.8-6.app/Contents/bin/cmake" -E >>>cmake_link_script CMakeFiles/plplottcltkd.dir/link.txt >>>--verbose=1 >>> /usr/local/adacore-gnat-2011/bin/gcc -dynamiclib >>>-Wl,-headerpad_max_install_names -single_module >>>-compatibility_version 9.0.0 -current_version 9.2.0 -o >>>libplplottcltkd.9.2.0.dylib -install_name >>>/usr/local/plplot_build_dir/bindings/tcl/libplplottcltkd.9.dylib >>>CMakeFiles/plplottcltkd.dir/tclAPI.c.o >>>CMakeFiles/plplottcltkd.dir/tclMain.c.o >>>CMakeFiles/plplottcltkd.dir/__/tk/Pltk_Init.c.o >>>CMakeFiles/plplottcltkd.dir/__/tk/plframe.c.o >>>CMakeFiles/plplottcltkd.dir/__/tk/plr.c.o >>>CMakeFiles/plplottcltkd.dir/__/tk/tcpip.c.o >>>CMakeFiles/plplottcltkd.dir/__/tk/tkMain.c.o >>>libtclmatrixd.9.2.0.dylib >>>../../src/libplplotd.11.0.0.dylib -framework tcl >>>-framework tk ../../lib/csa/libcsirocsa.0.0.1.dylib >>>../../lib/qsastime/libqsastime.0.0.1.dylib >>> Undefined symbols for architecture x86_64: >>> "_XLookupString", referenced from: >>> _PlFrameKeyEH in plframe.c.o >>> "_XFlush", referenced from: >>> _DisplayPlFrame in plframe.c.o >>> ld: symbol(s) not found for architecture x86_64 >>> collect2: ld returned 1 exit status >>> make[2]: *** [bindings/tcl/libplplottcltkd.9.2.0.dylib] >>>Error 1 >>> make[1]: *** >>>[bindings/tcl/CMakeFiles/plplottcltkd.dir/all] Error 2 >>> make: *** [all] Error 2 >>> >>> >>> >>> I should add that there has been one other change but I >>>don't think it's relevant--I have (once again!) installed >>>MacPorts which is a shadow quasi-OS-and-more which >>>purports to be completely independent of OS X, and >>>installs in /opt/local. However, and I mention this only >>>because I don't understand what is happening above but >>>see some possible tcl issues, MacPorts does place this >>>symlink >>> >>> /Library/Tcl/macports1.0 >>> >>> which points to >>> >>> /opt/local/share/macports/Tcl/macports1.0/macports_autoconf.tcl >>> /opt/local/share/macports/Tcl/macports1.0/macports_dlist.tcl >>> /opt/local/share/macports/Tcl/macports1.0/macports_fastload.tcl >>> /opt/local/share/macports/Tcl/macports1.0/macports_index.tcl >>> /opt/local/share/macports/Tcl/macports1.0/macports_util.tcl >>> /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib >>> /opt/local/share/macports/Tcl/macports1.0/macports.tcl >>> /opt/local/share/macports/Tcl/macports1.0/pkgIndex.tcl >>> >>> Jerry >>> ------------------------------------------------------------------------------ >>> 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 >>> Plp...@li... >>> 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Jerry <lan...@qw...> - 2012-05-10 09:31:00
|
On May 9, 2012, at 2:54 PM, Alan W. Irwin wrote: > On 2012-05-09 03:21-0700 Jerry wrote: > >> I can no longer build from the current SVN version. I _can_ build from a rather old (months--not sure how many months) SVN that I have saved. As far as I know the only two things that have changed are PLplot version and OS version--I updated OS X from 10.6.8 Snow Leopard to 10.7.x Lion recently. The only variable I have easy control of is PLplot version. I assume that reverting to Snow Leopard would be painful and of questionable use. >> >> Here's the problem: >> >> >> >> Linking C shared library libplplottcltkd.dylib >> cd /usr/local/plplot_build_dir/bindings/tcl && "/Applications/CMake 2.8-6.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/plplottcltkd.dir/link.txt --verbose=1 >> /usr/local/adacore-gnat-2011/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -single_module -compatibility_version 9.0.0 -current_version 9.2.0 -o libplplottcltkd.9.2.0.dylib -install_name /usr/local/plplot_build_dir/bindings/tcl/libplplottcltkd.9.dylib CMakeFiles/plplottcltkd.dir/tclAPI.c.o CMakeFiles/plplottcltkd.dir/tclMain.c.o CMakeFiles/plplottcltkd.dir/__/tk/Pltk_Init.c.o CMakeFiles/plplottcltkd.dir/__/tk/plframe.c.o CMakeFiles/plplottcltkd.dir/__/tk/plr.c.o CMakeFiles/plplottcltkd.dir/__/tk/tcpip.c.o CMakeFiles/plplottcltkd.dir/__/tk/tkMain.c.o libtclmatrixd.9.2.0.dylib ../../src/libplplotd.11.0.0.dylib -framework tcl -framework tk ../../lib/csa/libcsirocsa.0.0.1.dylib ../../lib/qsastime/libqsastime.0.0.1.dylib >> Undefined symbols for architecture x86_64: >> "_XLookupString", referenced from: >> _PlFrameKeyEH in plframe.c.o >> "_XFlush", referenced from: >> _DisplayPlFrame in plframe.c.o >> ld: symbol(s) not found for architecture x86_64 >> collect2: ld returned 1 exit status >> make[2]: *** [bindings/tcl/libplplottcltkd.9.2.0.dylib] Error 1 >> make[1]: *** [bindings/tcl/CMakeFiles/plplottcltkd.dir/all] Error 2 >> make: *** [all] Error 2 >> >> >> >> I should add that there has been one other change but I don't think it's relevant--I have (once again!) installed MacPorts which is a shadow quasi-OS-and-more which purports to be completely independent of OS X, and installs in /opt/local. However, and I mention this only because I don't understand what is happening above but see some possible tcl issues, MacPorts does place this symlink >> >> /Library/Tcl/macports1.0 >> >> which points to >> >> /opt/local/share/macports/Tcl/macports1.0/macports_autoconf.tcl >> /opt/local/share/macports/Tcl/macports1.0/macports_dlist.tcl >> /opt/local/share/macports/Tcl/macports1.0/macports_fastload.tcl >> /opt/local/share/macports/Tcl/macports1.0/macports_index.tcl >> /opt/local/share/macports/Tcl/macports1.0/macports_util.tcl >> /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib >> /opt/local/share/macports/Tcl/macports1.0/macports.tcl >> /opt/local/share/macports/Tcl/macports1.0/pkgIndex.tcl >> > > Hi Jerry: > > My guess is the the issue is some conflict between what -framework tcl > means in the above command line (for example, that probably refers to the > system version of Tcl) versus your macport install of Tcl. However, I > don't have any Mac OS X/macports experience so one of the others here > with such experience might be able to help you further. However, > unless and until you can get such detailed help with the above Tcl > linking issue, I suggest for now you simply work around the issue by > disabling the Tcl part of the PLplot build using the -DENABLE_tcl=OFF > cmake option. > > Alan I thought of that earlier too but didn't report it in my first post. With -DENABLE_tcl=OFF \ -DENABLE_tk=OFF \ (FWIW, my build script includes in CMAKE_LIBRARY_PATH the paths /usr/lib/libtcl.dylib:\ /usr/lib/libtk.dylib which are the standard-issue OS X libraries as far as I know, and which have worked in the past.) I get this (!) which appears to be Qt problems: Linking CXX shared module qt.so cd /usr/local/plplot_build_dir/drivers && "/Applications/CMake 2.8-6.app/Contents/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 ../lib/csa/libcsirocsa.0.0.1.dylib ../lib/qsastime/libqsastime.0.0.1.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::lock()", referenced from: QMutexLocker::QMutexLocker(QMutex*) in qt.cpp.o "QMutex::unlock()", referenced from: QMutexLocker::unlock() 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 |
From: Andrew R. <and...@us...> - 2012-08-16 11:30:30
|
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 > > Plp...@li... > > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Jerry <lan...@qw...> - 2012-08-17 04:18:29
|
On Aug 16, 2012, at 4:30 AM, Andrew Ross wrote: > > 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 I have wxwidgets 2.8.12_0 installed as part of MacPorts. (All of the MacPorts stuff is in /opt/local.) With DNON_TRANSITIVE=OFF, DENABLE_wxwidgets=ON, and DPLD_wxwidgets=ON the build of 12216 fails like this: Linking CXX shared library libplplotwxwidgetsd.dylib cd /usr/local/plplot_build_dir/bindings/wxwidgets && /opt/local/bin/cmake -E cmake_link_script CMakeFiles/plplotwxwidgetsd.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2011/bin/c++ -dynamiclib -Wl,-headerpad_max_install_names -single_module -o libplplotwxwidgetsd.0.0.0.dylib -install_name /usr/local/plplot_build_dir/bindings/wxwidgets/libplplotwxwidgetsd.0.dylib CMakeFiles/plplotwxwidgetsd.dir/wxPLplotstream.cpp.o CMakeFiles/plplotwxwidgetsd.dir/wxPLplotwindow.cpp.o -lplplotcxxd -arch i386 -framework IOKit -framework Carbon -framework Cocoa -framework System -framework QuickTime -framework OpenGL -framework AGL /opt/local/lib/libwx_base_carbonu-2.8.dylib /opt/local/lib/libwx_macu_core-2.8.dylib ld: library not found for -lplplotcxxd collect2: ld returned 1 exit status make[2]: *** [bindings/wxwidgets/libplplotwxwidgetsd.0.0.0.dylib] Error 1 make[1]: *** [bindings/wxwidgets/CMakeFiles/plplotwxwidgetsd.dir/all] Error 2 make: *** [all] Error 2 To my unpracticed eye the part "-arch i386" sticks out. I'm using x86_64 and as far as I know everything associated with building plplot on my machine is 64-bit. The wiki for OS X has long had the recommendation to not build for wxwidgets, possibly for an issue unrelated to what we are working on now; it would be great if we could get wxwidgets working on this OS. Jerry > > 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 >> |
From: Jerry <lan...@qw...> - 2012-08-17 04:48:11
|
On Aug 16, 2012, at 4:30 AM, Andrew Ross wrote: > > 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 > I also tried to build 12216 for tcl/tk. DNON_TRANSITIVE=OFF, DENABLE_tcl=ON, DENABLE_tk=ON, with the result below. This is the same condition which prompted the thread in the beginning, on May 9, 2012. The result is exactly the same whether I use the built-in tcl/tk by doing this: CMAKE_LIBRARY_PATH=/usr/local/adacore-gnat-2011/lib/gcc/x86_64-apple-darwin10.2.0/4.5.3/adalib:\ /usr/lib/libtcl.dylib:\ /usr/lib/libtk.dylib or (I think) using the MacPorts version by doing only this: CMAKE_LIBRARY_PATH=/usr/local/adacore-gnat-2011/lib/gcc/x86_64-apple-darwin10.2.0/4.5.3/adalib (The MacPorts paths are at the front of my PATH variable.) Linking C shared library libplplottcltkd.dylib cd /usr/local/plplot_build_dir/bindings/tcl && /opt/local/bin/cmake -E cmake_link_script CMakeFiles/plplottcltkd.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2011/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -single_module -compatibility_version 9.0.0 -current_version 9.2.0 -o libplplottcltkd.9.2.0.dylib -install_name /usr/local/plplot_build_dir/bindings/tcl/libplplottcltkd.9.dylib CMakeFiles/plplottcltkd.dir/tclAPI.c.o CMakeFiles/plplottcltkd.dir/tclMain.c.o CMakeFiles/plplottcltkd.dir/__/tk/Pltk_Init.c.o CMakeFiles/plplottcltkd.dir/__/tk/plframe.c.o CMakeFiles/plplottcltkd.dir/__/tk/plr.c.o CMakeFiles/plplottcltkd.dir/__/tk/tcpip.c.o CMakeFiles/plplottcltkd.dir/__/tk/tkMain.c.o libtclmatrixd.9.2.0.dylib ../../src/libplplotd.11.0.0.dylib -framework tcl -framework tk /usr/lib/libltdl.dylib /usr/lib/libdl.dylib ../../lib/csa/libcsirocsa.0.0.1.dylib ../../lib/qsastime/libqsastime.0.0.1.dylib /usr/lib/libm.dylib Undefined symbols for architecture x86_64: "_XLookupString", referenced from: _PlFrameKeyEH in plframe.c.o "_XFlush", referenced from: _DisplayPlFrame in plframe.c.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[2]: *** [bindings/tcl/libplplottcltkd.9.2.0.dylib] Error 1 make[1]: *** [bindings/tcl/CMakeFiles/plplottcltkd.dir/all] Error 2 make: *** [all] Error 2 Jerry |
From: Arjen M. <arj...@de...> - 2012-05-10 13:55:47
|
Hi Jerry, could it be the installation of X11? (I was told that such problems as unresolved symbols often result from architectures as x86_64.) A simple remedy might be to install the latest version of XQuartz - the open source version of X11 for OS X at http://xquartz.macosforge.org/landing/ Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Jerry <lan...@qw...> - 2012-05-10 23:21:55
|
On May 10, 2012, at 6:55 AM, Arjen Markus wrote: > Hi Jerry, > > could it be the installation of X11? (I was told that > such problems as unresolved symbols often result from > architectures as x86_64.) A simple remedy might be to > install the latest version of XQuartz - the open source > version of X11 for OS X at http://xquartz.macosforge.org/landing/ > > Regards, > > Arjen I'll keep this in mind. As the page says, XQuartz has shipped with OS X for several years. However, the version listed on that page is 2.7.1 while the one included with the latest version of OS X is 2.6.3 with a Build Date: 20120112. Jerry |
From: Alan W. I. <ir...@be...> - 2012-05-10 18:03:03
|
On 2012-05-10 02:30-0700 Jerry wrote: > > On May 9, 2012, at 2:54 PM, Alan W. Irwin wrote: > >> On 2012-05-09 03:21-0700 Jerry wrote: >> >>> I can no longer build from the current SVN version. I _can_ build from a rather old (months--not sure how many months) SVN that I have saved. As far as I know the only two things that have changed are PLplot version and OS version--I updated OS X from 10.6.8 Snow Leopard to 10.7.x Lion recently. The only variable I have easy control of is PLplot version. I assume that reverting to Snow Leopard would be painful and of questionable use. >>> >>> Here's the problem: >>> >>> >>> >>> Linking C shared library libplplottcltkd.dylib >>> cd /usr/local/plplot_build_dir/bindings/tcl && "/Applications/CMake 2.8-6.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/plplottcltkd.dir/link.txt --verbose=1 >>> /usr/local/adacore-gnat-2011/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -single_module -compatibility_version 9.0.0 -current_version 9.2.0 -o libplplottcltkd.9.2.0.dylib -install_name /usr/local/plplot_build_dir/bindings/tcl/libplplottcltkd.9.dylib CMakeFiles/plplottcltkd.dir/tclAPI.c.o CMakeFiles/plplottcltkd.dir/tclMain.c.o CMakeFiles/plplottcltkd.dir/__/tk/Pltk_Init.c.o CMakeFiles/plplottcltkd.dir/__/tk/plframe.c.o CMakeFiles/plplottcltkd.dir/__/tk/plr.c.o CMakeFiles/plplottcltkd.dir/__/tk/tcpip.c.o CMakeFiles/plplottcltkd.dir/__/tk/tkMain.c.o libtclmatrixd.9.2.0.dylib ../../src/libplplotd.11.0.0.dylib -framework tcl -framework tk ../../lib/csa/libcsirocsa.0.0.1.dylib ../../lib/qsastime/libqsastime.0.0.1.dylib >>> Undefined symbols for architecture x86_64: >>> "_XLookupString", referenced from: >>> _PlFrameKeyEH in plframe.c.o >>> "_XFlush", referenced from: >>> _DisplayPlFrame in plframe.c.o >>> ld: symbol(s) not found for architecture x86_64 >>> collect2: ld returned 1 exit status >>> make[2]: *** [bindings/tcl/libplplottcltkd.9.2.0.dylib] Error 1 >>> make[1]: *** [bindings/tcl/CMakeFiles/plplottcltkd.dir/all] Error 2 >>> make: *** [all] Error 2 >>> >>> >>> >>> I should add that there has been one other change but I don't think it's relevant--I have (once again!) installed MacPorts which is a shadow quasi-OS-and-more which purports to be completely independent of OS X, and installs in /opt/local. However, and I mention this only because I don't understand what is happening above but see some possible tcl issues, MacPorts does place this symlink >>> >>> /Library/Tcl/macports1.0 >>> >>> which points to >>> >>> /opt/local/share/macports/Tcl/macports1.0/macports_autoconf.tcl >>> /opt/local/share/macports/Tcl/macports1.0/macports_dlist.tcl >>> /opt/local/share/macports/Tcl/macports1.0/macports_fastload.tcl >>> /opt/local/share/macports/Tcl/macports1.0/macports_index.tcl >>> /opt/local/share/macports/Tcl/macports1.0/macports_util.tcl >>> /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib >>> /opt/local/share/macports/Tcl/macports1.0/macports.tcl >>> /opt/local/share/macports/Tcl/macports1.0/pkgIndex.tcl >>> >> >> Hi Jerry: >> >> My guess is the the issue is some conflict between what -framework tcl >> means in the above command line (for example, that probably refers to the >> system version of Tcl) versus your macport install of Tcl. However, I >> don't have any Mac OS X/macports experience so one of the others here >> with such experience might be able to help you further. However, >> unless and until you can get such detailed help with the above Tcl >> linking issue, I suggest for now you simply work around the issue by >> disabling the Tcl part of the PLplot build using the -DENABLE_tcl=OFF >> cmake option. >> >> Alan > > I thought of that earlier too but didn't report it in my first post. With > -DENABLE_tcl=OFF \ > -DENABLE_tk=OFF \ > > (FWIW, my build script includes in CMAKE_LIBRARY_PATH the paths > /usr/lib/libtcl.dylib:\ > /usr/lib/libtk.dylib > which are the standard-issue OS X libraries as far as I know, and which have worked in the past.) > > > I get this (!) which appears to be Qt problems: > > > Linking CXX shared module qt.so > cd /usr/local/plplot_build_dir/drivers && "/Applications/CMake 2.8-6.app/Contents/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 ../lib/csa/libcsirocsa.0.0.1.dylib ../lib/qsastime/libqsastime.0.0.1.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::lock()", referenced from: > QMutexLocker::QMutexLocker(QMutex*) in qt.cpp.o > "QMutex::unlock()", referenced from: > QMutexLocker::unlock() 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 > What is going on here is you bypassed one problem/inconsistency with your system installation only to find a further completely unrelated problem. To bypass each such problem, do what you did with the Tcl issue, that is disable the relevant part of the PLplot build (in order to find the next problem or else finally exhaust the list of such problems that you have to bypass to get a valid PLplot build). In this case it is some issue with Qt4 which is a rather complicated part of our PLplot build. I think you bypass all of that part of the PLplot build with -DDEFAULT_NO_QT_DEVICES=ON, but you will have to experiment. (Note, I am getting the name of this variable and some idea what to do with it from the short annotations in CMakeCache.txt that is generated for any given build in the top of the build directory. So when you are disabling various parts of PLplot, that file is a good place to start looking for the names of the appropriate variables to set ON or OFF.) I have no idea why you are suddenly having all these problems, but obviously it is some system or PLplot change that was made since the last time you ran the test_noninteractive target with success. Note svn allows you to easily access any particular revision number that you like. Once you find some revision that worked in the past for your current system (if your current system installation is not the culprit), then use a binary search on revision numbers to find the last good one/first bad one. For example, from plplot.sf.net the last release occurred on 2011-10-13, and the "svn log" command shows revision 11957 is about the closest you get to that release date on svn trunk. The current revision is 12194 So to change to revision 11957 simply cd to the top of your source tree and svn update --revision 11957 Then do your normal build and test with "make test_noninteractive" in the top of the core build tree to see if that revision works. If it does, then try a revision half way between 11957 and 12194 to see if that works, etc. That is do a binary search for the last revision that worked, and the next revision after that is the one that first introduced a PLplot change that is not right for your current Mac OS X/macports platform. The binary search method is actually amazingly fast. In this case a maximum 8 builds should find the problem since there are less than 256 revisions between 11957 and 12194. There is a procedure to automate such binary searches, but in this case it is probably easier to do it by hand. Note if the problems are caused by some issues with your new Mac OS X/macports system not even revision 11957 (or whatever revision you last tested successfully with the test_noninteractive target) would work well for you now. 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 __________________________ |
From: Jerry <lan...@qw...> - 2012-05-11 07:43:39
|
On May 10, 2012, at 11:02 AM, Alan W. Irwin wrote: > What is going on here is you bypassed one problem/inconsistency with your > system installation only to find a further completely unrelated problem. > > To bypass each such problem, do what you did with the Tcl issue, that is > disable the relevant part of the PLplot build (in order to find the next > problem or else finally exhaust the list of such problems that you have > to bypass to get a valid PLplot build). > > In this case it is some issue with Qt4 which is a rather complicated > part of our PLplot build. I think you bypass all of that part of the > PLplot build with -DDEFAULT_NO_QT_DEVICES=ON, but you will have > to experiment. > > (Note, I am getting the name of this variable and some idea what to do > with it from the short annotations in CMakeCache.txt that is generated > for any given build in the top of the build directory. So when you > are disabling various parts of PLplot, that file is a good place to > start looking for the names of the appropriate variables to set ON > or OFF.) > > I have no idea why you are suddenly having all these problems, but > obviously it is some system or PLplot change that was made since the > last time you ran the test_noninteractive target with success. > > Note svn allows you to easily access any particular revision number > that you like. Once you find some revision that worked in the past for > your current system (if your current system installation is not the > culprit), then use a binary search on revision numbers to find the > last good one/first bad one. > > For example, from plplot.sf.net the last release occurred on 2011-10-13, and the > "svn log" command shows revision 11957 is about the closest you get to > that release date on svn trunk. The current revision is 12194 > > So to change to revision 11957 simply cd to the top > of your source tree and > > svn update --revision 11957 > > Then do your normal build and test with "make test_noninteractive" in the > top of the core build tree to see if that revision works. If it does, > then try a revision half way between 11957 and 12194 to see if that > works, etc. That is do a binary search for the last revision that > worked, and the next revision after that is the one that first > introduced a PLplot change that is not right for your current Mac OS > X/macports platform. The binary search method is actually amazingly > fast. In this case a maximum 8 builds should find the problem since > there are less than 256 revisions between 11957 and 12194. There is > a procedure to automate such binary searches, but in this case it > is probably easier to do it by hand. 12121 Builds 12122 Doesn't build http://plplot.svn.sourceforge.net/viewvc/plplot?view=revision&sortby=log&revision=12122 tcl-related.cmake looks interesting. Here's the error output again: Linking C shared library libplplottcltkd.dylib cd /usr/local/plplot_build_dir/bindings/tcl && "/Applications/CMake 2.8-6.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/plplottcltkd.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2011/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -single_module -compatibility_version 9.0.0 -current_version 9.2.0 -o libplplottcltkd.9.2.0.dylib -install_name /usr/local/plplot_build_dir/bindings/tcl/libplplottcltkd.9.dylib CMakeFiles/plplottcltkd.dir/tclAPI.c.o CMakeFiles/plplottcltkd.dir/tclMain.c.o CMakeFiles/plplottcltkd.dir/__/tk/Pltk_Init.c.o CMakeFiles/plplottcltkd.dir/__/tk/plframe.c.o CMakeFiles/plplottcltkd.dir/__/tk/plr.c.o CMakeFiles/plplottcltkd.dir/__/tk/tcpip.c.o CMakeFiles/plplottcltkd.dir/__/tk/tkMain.c.o libtclmatrixd.9.2.0.dylib ../../src/libplplotd.11.0.0.dylib -framework tcl -framework tk /usr/lib/libltdl.dylib /usr/lib/libdl.dylib ../../lib/csa/libcsirocsa.0.0.1.dylib ../../lib/qsastime/libqsastime.0.0.1.dylib /usr/lib/libm.dylib Undefined symbols for architecture x86_64: "_XLookupString", referenced from: _PlFrameKeyEH in plframe.c.o "_XFlush", referenced from: _DisplayPlFrame in plframe.c.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[2]: *** [bindings/tcl/libplplottcltkd.9.2.0.dylib] Error 1 make[1]: *** [bindings/tcl/CMakeFiles/plplottcltkd.dir/all] Error 2 make: *** [all] Error 2 Jerry > > Note if the problems are caused by some issues with your new Mac OS > X/macports system not even revision 11957 (or whatever revision you > last tested successfully with the test_noninteractive target) would > work well for you now. > > Alan |
From: Arjen M. <arj...@de...> - 2012-05-11 07:54:56
|
On Fri, 11 May 2012 00:43:22 -0700 Jerry <lan...@qw...> wrote: > > > 12121 Builds > 12122 Doesn't build > http://plplot.svn.sourceforge.net/viewvc/plplot?view=revision&sortby=log&revision=12122 > tcl-related.cmake looks interesting. > Hi Jerry, it would seem that reverting the change to tcl-related.cmake should solve the Tcl/Tk issue. What surprises me a bit is that there are only two unresolved symbols - plframe uses several other X11 functions as well. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Jerry <lan...@qw...> - 2012-05-11 09:18:51
|
On May 11, 2012, at 12:54 AM, Arjen Markus wrote: > On Fri, 11 May 2012 00:43:22 -0700 > Jerry <lan...@qw...> wrote: >> 12121 Builds >> 12122 Doesn't build >> http://plplot.svn.sourceforge.net/viewvc/plplot?view=revision&sortby=log&revision=12122 >> tcl-related.cmake looks interesting. > > Hi Jerry, > > it would seem that reverting the change to tcl-related.cmake > should solve the Tcl/Tk issue. What surprises me a bit is > that there are only two unresolved symbols - plframe uses > several other X11 functions as well. > > Regards, > > Arjen > /usr/X11/bin is on my PATH. Could PLplot be getting into that? Jerry > > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. > The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. > > > > |
From: Arjen M. <arj...@de...> - 2012-05-11 09:34:30
|
Hi Jerry, On Fri, 11 May 2012 02:18:38 -0700 Jerry <lan...@qw...> wrote: > >> > /usr/X11/bin is on my PATH. Could PLplot be getting into >that? > Jerry That seems very unlikely to me: the error occurs at link-time and the linker does not pay attention to the PATH variable to resolve symbols or find libraries. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2012-05-11 19:17:06
|
Hi Andrew and Jerry: Andrew, would you please review my conclusions below and take appropriate action for svn trunk? On 2012-05-11 00:43-0700 Jerry wrote: > 12121 Builds > 12122 Doesn't build > http://plplot.svn.sourceforge.net/viewvc/plplot?view=revision&sortby=log&revision=12122 > tcl-related.cmake looks interesting. Jerry, your binary search to find the commit that screwed up the Tcl/Tk part of the PLplot build for you is extremely useful. Thanks! I have looked fairly carefully at that non-whitespace changes for that commit with svn diff -x -w --revision=12121:12122 |less A while ago I reverted the cmake/modules/wxwidgets.cmake part of revision 12122 since that caused (if I recall correctly) a run-time error on Linux. So the rest of that commit should be treated with caution as you have just discovered. Our Tk related bindings/examples depend on X (this is the reason our Tk stuff cannot currently be used on Windows). So I think we should revert (as Arjen also suggested) the revision=12122 change to cmake/modules/tcl-related.cmake, but I hope Andrew double-checks that conclusion. The following command run in examples/tk software@raven> grep -l "sin(" xtk*.c xtk01.c xtk02.c xtk04.c shows that all our xtk*.c examples depend directly on the math library so the revision=12122 change to examples/tk/Makefile.examples.in that drops -lm should be reverted. That leaves the cmake/modules/FindLTDL.cmake revision=12122 change as the only legitimate part (I think) to revision 12122, but I hope Andrew reviews that one as well since the rest of this commit is problematic. Jerry, would you be willing to do a similar binary search for the revision that caused the Qt4 issues for you? If so, I would disable Tcl with the appropriate cmake option (so the above commit issues don't matter for your test) and repeat the binary search from revision 12121 onward. 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 __________________________ |
From: Jerry <lan...@qw...> - 2012-05-11 19:38:31
|
On May 11, 2012, at 12:16 PM, Alan W. Irwin wrote: > Jerry, would you be willing to do a similar binary search for the > revision that caused the Qt4 issues for you? If so, I would disable > Tcl with the appropriate cmake option (so the above commit issues > don't matter for your test) and repeat the binary search from revision > 12121 onward. Sure, no problem. I might not be able to get to it today or tomorrow, though. Should I disable tk as well? Jerry > > Alan |
From: Alan W. I. <ir...@be...> - 2012-08-18 00:46:54
|
On 2012-08-17 09:59-0700 Alan W. Irwin wrote: > On 2012-08-16 20:37-0700 Jerry wrote: > >> Thanks for looking into this, Andrew. >> >> The results that I reported in my previous e-mail (reviving the thread) were with -DNON_TRANSITIVE=OFF. With your fix to 12216, I can now build 12216 for Qt. Problem fixed. >> >> When I switch to -DNON_TRANSITIVE=ON, however, the build fails like this: >> >> 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 -lQtCore >> ld: library not found for -lQtCore >> 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 > > Andrew, just to interject here, I believe the source of the error is > the lack of -L option in the above line to tell the linker where to > find QtCore. QT_LIBRARIES should have that information along with a > bunch of -l options that you do not want for the -DNON_TRANSITIVE=ON > case. So probably the thing to do here is to parse the QT_LIBRARIES > variable to remove the unwanted -l options. Since you are working > through a 3rd party (Jerry) for a platform you are not familiar with > (OS X), I suggest you use the CMake message command to always print > out both QT_LIBRARIES, and its parsed form just in case Jerry finds > any further difficulty with the parsed version. P.S. That comment wasn't quite right. To further clarify, all lists of linking flags like QT_LIBRARIES are further processed by our build system when they are first encountered (in cmake/modules) to transform -L and -l options to construct the equivalent full path name of libraries without disturbing other linking flags. (The absolute pathname form is the preferred one for variables that are used in target_link_libraries even though CMake internally changes that back to the -L and -l form when linking Linux libraries. But the actual resulting linking command may be different on other platforms which is why the absolute pathname form for library locations is preferred for input to target_link_libraries.) In sum, that clarification means for the case where you need to drop some but not all of those libraries, you should parse lists of linking flags such as QT_LIBRARIES to drop all absolute pathames other than the libraries you want. That parsing should leave hyphenated options alone. 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 __________________________ |
From: Andrew R. <and...@us...> - 2012-08-18 20:37:21
|
On Fri, Aug 17, 2012 at 05:46:47PM -0700, Alan Irwin wrote: > On 2012-08-17 09:59-0700 Alan W. Irwin wrote: > > > On 2012-08-16 20:37-0700 Jerry wrote: > > > >> Thanks for looking into this, Andrew. > >> > >> The results that I reported in my previous e-mail (reviving the thread) were with -DNON_TRANSITIVE=OFF. With your fix to 12216, I can now build 12216 for Qt. Problem fixed. > >> > >> When I switch to -DNON_TRANSITIVE=ON, however, the build fails like this: > >> > >> 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 -lQtCore > >> ld: library not found for -lQtCore > >> 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 > > > > Andrew, just to interject here, I believe the source of the error is > > the lack of -L option in the above line to tell the linker where to > > find QtCore. QT_LIBRARIES should have that information along with a > > bunch of -l options that you do not want for the -DNON_TRANSITIVE=ON > > case. So probably the thing to do here is to parse the QT_LIBRARIES > > variable to remove the unwanted -l options. Since you are working > > through a 3rd party (Jerry) for a platform you are not familiar with > > (OS X), I suggest you use the CMake message command to always print > > out both QT_LIBRARIES, and its parsed form just in case Jerry finds > > any further difficulty with the parsed version. > > P.S. That comment wasn't quite right. To further clarify, all lists > of linking flags like QT_LIBRARIES are further processed by our build > system when they are first encountered (in cmake/modules) to transform > -L and -l options to construct the equivalent full path name of > libraries without disturbing other linking flags. (The absolute > pathname form is the preferred one for variables that are used in > target_link_libraries even though CMake internally changes that back > to the -L and -l form when linking Linux libraries. But the actual > resulting linking command may be different on other platforms which is > why the absolute pathname form for library locations is preferred for > input to target_link_libraries.) > > In sum, that clarification means for the case where you need to drop > some but not all of those libraries, you should parse lists of linking > flags such as QT_LIBRARIES to drop all absolute pathames other than > the libraries you want. That parsing should leave hyphenated options > alone. I've now done this, parsing QT_LIBRARIES to extract just the QtCore library. Jerry, can you try this version? Out of interest, if it doesn't work can you report the values of QT_LIBRARIES and QT_LINK_LIBS returned by cmake, and also the actual command used to link the Qt driver? Thanks Andrew |
From: Jerry <lan...@qw...> - 2012-05-11 23:10:05
|
On May 11, 2012, at 12:16 PM, Alan W. Irwin wrote: > Jerry, would you be willing to do a similar binary search for the > revision that caused the Qt4 issues for you? If so, I would disable > Tcl with the appropriate cmake option (so the above commit issues > don't matter for your test) and repeat the binary search from revision > 12121 onward. > > Alan 12164 builds 12165 fails Jerry Linking CXX shared module qt.so cd /usr/local/plplot_build_dir/drivers && "/Applications/CMake 2.8-6.app/Contents/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 ../lib/csa/libcsirocsa.0.0.1.dylib ../lib/qsastime/libqsastime.0.0.1.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::lock()", referenced from: QMutexLocker::QMutexLocker(QMutex*) in qt.cpp.o "QMutex::unlock()", referenced from: QMutexLocker::unlock() 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 |