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

Reply via email to