More responses below.
On Thu, Dec 19, 2013 at 10:25:19AM -0800, Alan Irwin wrote:
> Hi Andrew:
>
> Thanks for this very interesting test. More below.
>
> On 2013-12-19 13:10-0000 Andrew Ross wrote:
>
> >
> > I plan to try the comprehensive test script for my Debian based
> > configurations
> > later. In the meantime I've been trying to build plplot on a CentOS 5.10
> > machine at work. This is old software now and I expected problems. I also
> > have no root access so have to work with what's there.
> >
> > I build only cmake from scratch then tried to build plplot.
> >
> > Many drivers / bindings were disabled anyway since components were missing
> > from the system. Bugs I encountered were
> >
> > [ 18%] Building Ada object bindings/ada/CMakeFiles/plplotadad.dir/plplot.o
> > plplot.ads:24:05: "Ada.Numerics.Long_Real_Arrays" is not a predefined
> > library unit
> > plplot.ads:24:05: "Plplot (body)" depends on "Plplot (spec)"
> > plplot.ads:24:05: "Plplot (spec)" depends on "Plplot_Thin (spec)"
> > plplot.ads:24:05: "Plplot_Thin (spec)" depends on "Plplot_Auxiliary (spec)"
> > plplot.ads:24:05: "Plplot_Auxiliary (spec)" depends on
> > "Ada.Numerics.Long_Real_Arrays (spec)"
> > make[2]: *** [bindings/ada/CMakeFiles/plplotadad.dir/plplot.o] Error 1
> > make[1]: *** [bindings/ada/CMakeFiles/plplotadad.dir/all] Error 2
> >
> > Old version of gnat (4.1.2) probably the cause. I disabled Ada and continued
> >
> > 25%] Building C object utils/CMakeFiles/pltek.dir/pltek.c.o
> > Linking C executable pltek
> > ../src/libplplotd.so.12.0.0: undefined reference to
> > `cairo_ps_surface_set_eps'
> > ../src/libplplotd.so.12.0.0: undefined reference to
> > `pango_layout_get_baseline'
> > collect2: ld returned 1 exit status
> > make[2]: *** [utils/pltek] Error 1
> > make[1]: *** [utils/CMakeFiles/pltek.dir/all] Error 2
> >
> > This was built without dynamic drivers (relevant lib missing) and so
> > cairo driver was compiled into plplot. This looks to me like a linking
> > issue in plplot, possible due to old version of linker since Alan hasn't
> > reported it for his test?
>
> I am pretty sure the problem is the old version of cairo. libplplotd needs
> cairo_ps_surface_set_eps, etc., but it looks like the old version of
> cairo on that system does not supply it.
That sounds plausible. It may be worth a version check somewhere, but given this
is a pretty old version of cairo, I suspect not.
> > Anyway, I disabled the cairo drivers and proceeded.
> >
> > [ 32%] Generating plplot/examples/x00.class
> > ----------
> > 1. ERROR in
> > /nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java
> > (at line 29)
> > import static plplot.core.plplotjavacConstants.*;
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Syntax error, static imports are only available if source level is 5.0
> > ----------
> > 2. ERROR in
> > /nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java
> > (at line 56)
> > pls.parseopts( args, PL_PARSE_FULL | PL_PARSE_NOPROGRAM );
> > ^^^^^^^^^^^^^
> > PL_PARSE_FULL cannot be resolved
> > ----------
> > 3. ERROR in
> > /nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java
> > (at line 56)
> > pls.parseopts( args, PL_PARSE_FULL | PL_PARSE_NOPROGRAM );
> > ^^^^^^^^^^^^^^^^^^
> > PL_PARSE_NOPROGRAM cannot be resolved
> > ----------
> > 3 problems (3 errors)make[3]: *** [examples/java/plplot/examples/x00.class]
> > Error 255
> > make[2]: *** [examples/java/CMakeFiles/plplot_examples.dir/all] Error 2
> > make[1]: *** [examples/CMakeFiles/test_noninteractive.dir/rule] Error 2
> >
> > This looks like a problem with an old version of javac. I might be able
> > to fix this by setting the source level, but I just disabled java and
> > continued.
> >
> > After all this I ended up with just C / C++ / F95 bindings and with a
> > minimal set of drivers (mem, null, psc, svg, xfig, xwin). It did however
> > pass make test_interactive and make test_noninteractive.
>
> That's an extremely useful test result for enterprise Linux. Can you
> write it up in the same style as the rest of the test results in
> README.release?
Will do.
> > On the plus side I spotted a bug with plcolorbar in the C++ bindings.
> > Not sure why this hadn't been triggered with newer versions of gcc.
>
> I am surprised also that slipped through our previous tests, but I am
> very glad you found it.
>
> >
> > I have also tried epa_build_lite. I got as far as building libharu and
> > the build failed with
> >
> > Building C object src/CMakeFiles/hpdf_static.dir/hpdf_string.o
> > cd /tmp/build_plplot/build_dir-linux/epa_build/Build/build_libharu/src &&
> > /usr/bin
> > /cc -O3 -fvisibility=hidden -Wuninitialized
> > -I/tmp/build_plplot/build_dir-linux
> > /epa_build/Source/build_libharu/include
> > -I/tmp/build_plplot/build_dir-linux/epa_bu
> > ild/Build/build_libharu/include -o
> > CMakeFiles/hpdf_static.dir/hpdf_string.o -
> > c
> > /tmp/build_plplot/build_dir-linux/epa_build/Source/build_libharu/src/hpdf_string
> > .c
> > /usr/local/lib/libz.so: could not read symbols: File in wrong format
> > collect2: ld returned 1 exit status
> > gmake[6]: *** [src/libhpdf.so.0.0.0] Error 1
> >
> > Note this is a static build, but trying to link in the shared version of
> > libz. I think this is because there is no libz.a installed, however
> > cmake didn't spot this corner case. Manually massaging the linker
> > options allowed me to continue, however for some reason the header file
> > hpdf_pdfa.h is not installed (this is only required in the static case)
> > and so any code using hpdf.h will fail. Copying the header into the
> > install tree got me a bit further.
>
> So far I have only tested epa_build for shared builds, and I never
> particularly intended to try it with static builds which are always
> more tricky. So at least for now, I suggest you switch to shared
> builds.
Cmake chose to build a static library, not me, so I assume something was
missing for building shared versions. Cmake finds.so versions of the
libraries when performing the library checks. All these then get successfully
change to -l flags, except in this case libz.so. By changing all references
to libz.so in CMakeCache.txt to point to another directory with a full copy
(.so + .a files) I got everything to "just work". From this I conclude that
static libraries would work as long as there is both a shared and static
version of the library present.
> > I then had to muck about to disable ada and java to get the build to
> > complete
> > and to install (p.s. Alan: How do I pass cmake options to the plplot build
> > when
> > using epa? I went in and reran cmake by hand - not ideal).
>
> Please go ahead and start making changes in epa_build to suit your
> needs. If it is something simple (like below) feel free to commit
> it, but if it is something more complicated that potentially might mess up my
> testing today, I would appreciate you holding off until later to
> actually do the commit.
No problem. I'll wait until post-release now I think.
> To implement the present feature request, note that plplot
> and plplot_lite invoke cmake as follows:
>
> CONFIGURE_COMMAND ${ENV_EXECUTABLE} PATH=${EPA_PATH}
> "CFLAGS=${CFLAGS}" "CXXFLAGS=${CXXFLAGS}" "FFLAGS=${FFLAGS}"
> ${EPA_CMAKE_COMMAND} -DBUILD_TEST=ON ${cmake_args}
> ${EPA_BASE}/Source/build_${PACKAGE}
>
> where ${cmake_args} is a list of cmake arguments that are defined
> differently for plplot and plplot_lite, and
> EPA_CMAKE_COMMAND includes the generator and prefix (see the
> top-level CMakeLists.txt).
>
> I suggest you replace ${cmake_args} above (in both plplot and
> plplot_lite) by
> ${cmake_args} ${PLPLOT_USER_cmake_args} where normally
> PLPLOT_USER_cmake_args is not defined, but in your case
> you could define it on the cmake command line as
>
> -DPLPLOT_USER_cmake_args:STRING="-DENABLE_java=OFF;-DENABLE_ada=OFF;-DDEFAULT_NO_CAIRO_DEVICES:BOOL=ON"
>
> (Note how the list of cmake options masquerades as a semicolon-separated
> series of
> cmake options).
>
> In other words, a minor change to plplot/CMakeLists.txt and
> plplot_lite/CMakeLists.txt plus invoking cmake for epa_build with the
> above option should implement your feature request.
Sounds like a good idea. I'll try it.
> >
> > I then tried the cmake based tests in the install tree.
> >
> > make test_noninteractive failed becauase the epa built itcl / itk
> > libraries were not found. There is no rpath information for these,
> > even though the other libraries are fine. Setting LD_LIBRARY_PATH
> > allowed me to continue and then the examples ran fine.
>
> The PLplot build system does specifically set and use RPATH variables
> for the Tcl and Tk libraries. If those are empty, that is because
> somehow they have been set to system locations which are filtered out
> to nothing by design (since you never want rpath to point to system
> locations) rather than the desired epa_build buildtools location. I
> suspect you might not have followed the directions in README with
> regard to the epa_build of buildtools and setting up your epa_build
> environment by sourcing a version of setup/setup_linux that has been
> tailored to your own particular locations for everything. Anyhow,
> when I follow those directions here, I get the following RPATH results:
>
> -- TCL_RPATH = /home/wine/newstart/build_script/install-linux_buildtools/lib
> -- TCL_TK_RPATH =
> /home/wine/newstart/build_script/install-linux_buildtools/lib
> -- TCL_TK_ITCL_ITK_RPATH =
> /home/wine/newstart/build_script/install-linux_buildtools/lib;/home/wine/newstart/build_script/install-linux_buildtools/lib/itcl3.4;/home/wine/newstart/build_script/install-linux_buildtools/lib/itk3.3
>
> If you don't get lines similar to the above, then those variables have
> been emptied because they point to the system locations as explained
> above. The above variables are used appropriately in the PLplot build
> system so at least for my case is not necessary for me to set
> LD_LIBRARY_PATH.
I get just this, so cmake is setting the RPATH variables correctly. ldd
on libplplotd.so in the build directory looks fine, but ldd in the
install directory can't find itcl or itk. The tcl and tk libraries are
found fine in their epa install location. This is most odd...
> >
> > Tried to run build_plplot which fails straight away with
> >
> > 1%] Performing download step (verify and extract) for 'build_qt4_lite'
> > cd /tmp/build_plplot/build_dir-linux/epa_build/Source &&
> > /nfs/see-archive-15_a58/l
> > ecanr/software/plplot/build_script/install-linux_buildtools/bin/cmake -P
> > /tmp/buil
> > d_plplot/build_dir-linux/epa_build/Stamp/build_qt4_lite/verify-build_qt4_lite.cmak
> > e
> > -- verifying file...
> >
> > file='/home/software/build_qt4/qt-everywhere-opensource-src-4.8.5.tar.gz'
> > CMake Error at
> > /tmp/build_plplot/build_dir-linux/epa_build/Stamp/build_qt4_lite/ve
> > rify-build_qt4_lite.cmake:5 (file):
> > file MD5 failed to read file
> > "/home/software/build_qt4/qt-everywhere-opensource-src-4.8.5.tar.gz": No
> > such file or directory
> >
> > Looks like this points to a file on Alan's hard disk rather than trying
> > to download. You probably want to comment out the temporary debugging line
> > before the release. I'll commit that change myself now.
> > Having done that the
> > build is now chugging away. More later...
>
> Thanks for spotting and fixing that issue and also giving epa_build a try on
> CentOS
> 5.10. More later in response to your finished epa_build results.
Andrew
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
