On Sat, Apr 18, 2015 at 05:00:52PM -0700, Alan Irwin wrote:
> On 2015-04-18 22:56+0100 Andrew Ross wrote:
>
> >
> >Alan,
> >
> >I've finally got time to rerun my comnprehensive tests with Ubuntu 14.10
> >and try to debug the niggle issues I encountered with the static build
> >
> >(My only change from last time is that I've had to build cmake from source
> >to get a new enough version - I'm using 3.2.2)
> [...]
> >2) The code in src/CMakeFiles to find the stdc++ library doesn't work for
> >me. The comments suggest that g++ returns a semicolon delimited list of
> >paths, which is just like a cmake list so no manipulation is needed. At
> >least on my system it is actually colon separated. Replacing the colons
> >with semicolons fixes the problem and ensures the correct linkage options
> >for pkg-config, and hence the traditional examples build. I've not
> >commited this fix, since it might upset other people. In particularly on
> >windows the colon may be used for drive letters? Can others check
> >what g++ returns to check that a simple replacement of colons with
> >semicolons wouldn't break anything? Try g++ --verbose --version and look
> >at what LIBRARY_PATH is set to.
>
> The problem is that libplplot is a mixed C and C++ library for the
> nondynamic or static case (because of including C++ drivers code in
> the library for those cases). Therefore, for the traditional build
> system for the installed examples, when gcc is used to link a C
> example a specific link to libstdc++.so has to be provided.
>
> The code in src/CMakeLists.txt to find that library is really ugly,
> works only for g++ and no other C++ compiler, and depends on g++
> internals which apparently have now changed. And colon separation
> when there are drive letters is a real pain to deal with. So I plan
> to abandon that code completely and simply solve the problem
> in a general way for the static and nondyamic cases by using the CXX
> compiler (which automatically links in libstdc++.so) for building
> the C examples using the traditional build system. Implementation
> to follow....
I didn't want to comment on your code, but that was the impression I got!
I am using g++-4.9, but I did the g++ --verbose --version test on Ubuntu
versions back to 4.4 and all used the colon. I agree, dropping it is
perhaps the best. Presumably the linkage with the CXX compiler should only
be if the C++ bindings are enabled? This is almost always going to be the
case these days, but someone might want to compile a minimal C only
static library for embedded purposes?
> >3) I also get the following errors
> >
> >/usr/bin/ld:
> >/home/andrew/software/plplot/comprehensive_test_disposeable/static/install_tree/lib/libplplot.a(wxwidgets_comms.cpp.o):
> > undefined reference to symbol 'shm_unlink@@GLIBC_2.2.5'
> >/lib/x86_64-linux-gnu/librt.so.1: error adding symbols: DSO missing from
> >command line
> >collect2: error: ld returned 1 exit status
> >Makefile:103: recipe for target 'x00c' failed
> >make[1]: *** [x00c] Error 1
> >
> >which I think are probably due to librt not being linked explicitly? Alan
> >- I'm not quite sure where this needs fixing. Can you reproduce this on
> >Debian?
>
> I cannot reproduce that issue (my comprehensive tests sailed through without
> issues
> for Debian stable).
>
> There was an attempt to fix the rt issues prior to the 5.11.0 release,
> but it sounds like we missed something that matters on at least
> Ubuntu.
>
> Here is where to look in our current source code for such fixes.
>
> software@raven> find . -type f |grep -v .git |grep -v ChangeLog |xargs grep
> RT_LIB
> ./drivers/CMakeLists.txt: ${RT_LIB}
> ./src/CMakeLists.txt: list(APPEND libplplot_LINK_LIBRARIES ${RT_LIB})
> ./cmake/modules/wxwidgets.cmake: # So only define RT_LIB for the Unix but
> not Mac case.
> ./cmake/modules/wxwidgets.cmake: find_library(RT_LIB rt)
> ./cmake/modules/wxwidgets.cmake: if(RT_LIB)
> ./cmake/modules/wxwidgets.cmake: message(STATUS "RT_LIB = ${RT_LIB}")
> ./cmake/modules/wxwidgets.cmake: else(RT_LIB)
> ./cmake/modules/wxwidgets.cmake: set(RT_LIB)
> ./cmake/modules/wxwidgets.cmake: endif(RT_LIB)
> ./cmake/modules/wxwidgets.cmake: set(RT_LIB)
> ./utils/CMakeLists.txt: target_link_libraries(wxPLViewer plplotwxwidgets
> plplotcxx ${wxwidgets_LINK_FLAGS} ${MATH_LIB} ${RT_LIB})
>
> If that message result from cmake shows you are finding the rt library
> on Ubuntu without issues, then for the static case the code in
> src/CMakeListx.txt is what you should look at to see why that rt
> library is not being included properly when building libplplot (which
> contains the wxwidgets code which refers to rt symbols).
RT_LIB is set fine, and it all works for the cmake builds, it's only the
traditional example build which fails, so I suspect this is a problem with
-lrt not being included in the pkg-config files for some reason. I'll
delve further.
Andrew
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
