On 2012-08-20 20:10-0700 Jerry wrote:
>
> On Aug 20, 2012, at 2:07 PM, Andrew Ross wrote:
>
>> Jerry,
>>
>> Thanks. So my method did what it was meant to, but unforunately it looks
>> like we need to actually link in QtGui and QtSvg as well, so we might
>> as well just use QT_LIBRARIES without trying to parse it.
>>
>> Note that QtCore has to be explicitly linked in since qt.cpp references
>> QApplication.
>>
>> Classes from QtGui and QtSvg are not explictly mentioned in qt.cpp, but
>> derived classes (QtPLWidget etc from plplotqtd) are mentioned. On Linux
>> at least "ldd -u qt.so" shows these libraries as unused dependencies, but
>> "nm --demangle --undefined-only qt.so" contains references to functions
>> in these libraries. I don't quite understand why, but I think to be safe
>> we need to link with them, even if it causes warnings about linking
>> with unused dependencies.
>>
>> Andrew
>
> Great! 12218 builds Qt with NON_TRANSITIVE=ON.
To Andrew, Jim, and Jerry:
I am resurrecting this two-year-old thread because as of commit id
c67fd66 I have changed from deprecated to recommended CMake methods of
implementing NON_TRANSITIVE=ON, and while making the change, I noticed
Andrew's commit to always link ${QT_LIBRARIES} transitively to solve a
problem Jerry was having almost two years ago with building on Lion.
With the new method, I still link ${QT_LIBRARIES} transitively
(see notes in bindings/qt_gui/CMakeLists.txt) so I predict
all should be well when Jim or Jerry builds PLplot with qt on
whatever versions of Mac OS X they have installed.
@Jim and Jerry:
Could you please check that prediction when you get a chance?
@Andrew:
As we both already know "ldd -u" produces lots of false positives
about overlinking, but a google search shows that is not the correct way to use
that option, and you must always use the -r flag at the same time to get
reliable results.
So with the new linking implementation, here is the ldd -u -r
results for qt_example.
software@raven> ldd -u -r examples/c++/qt_example
Unused direct dependencies:
/usr/lib/x86_64-linux-gnu/libQtSvg.so.4
I believe "ldd -u -r" is working correctly here, i.e., that is a real
overlinking issue. libQtSvg is only used to support the svgqt
device so it makes sense that it should not be needed by qt_example.
But I may be wrong here since you concluded above (two years ago)
that libQtSvg was needed.
Note, that although I felt you would be interested in this result, I
also don't think we should make any extraordinary attempts to drop
libQtSvg from this link step (even if you decide that is allowed)
since overlinking is not that harmful, and the above is a Qt4 result
(whose CMake support is very different from the CMake support for Qt5)
which will no longer be relevant once we fully switch to Qt5 (probably
still at least a year in the future depending on how soon the Qt5
alignment bugs are fixed).
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
__________________________
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
