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 __________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel