[Plplot-devel] executable stacks
Fedora has now started generating errors when code generates an executable stack. This breaks the plplot build: [ 75%] Linking Fortran executable x09f cd /builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/examples/fortran && /usr/bin/cmake -E cmake_link_script CMakeFiles/x09f.dir/link.txt --verbose=1 /usr/bin/gfortran -Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer CMakeFiles/x09f.dir/x09f.f90.o -o x09f -Wl,-rpath,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/bindings/fortran:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime ../libplfortrandemolib.a ../../bindings/fortran/libplplotfortran.so.0.2.0 -Wl,-rpath-link,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime /usr/bin/ld: error: /tmp/cczNXqc0.ltrans0.ltrans.o: is triggering the generation of an executable stack (because it has an executable .note.GNU-stack section) Using -Wtrampolines yields: plplot-5.15.0/examples/fortran/x09f.f90:187:21: warning: trampoline generated for nested function ‘mypltr.3’ [-Wtrampolines] plplot-5.15.0/examples/fortran/x09f.f90:187:21: warning: trampoline generated for nested function ‘mypltr’ [-Wtrampolines] and: /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xtraditional09a.adb:92:5: warning: trampoline generated for nested function ‘xtraditional09a.mypltr’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xstandard09a.adb:92:5: warning: trampoline generated for nested function ‘xstandard09a.mypltr’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xtraditional14a.adb:258:9: warning: trampoline generated for nested function ‘xtraditional14a.plot5.mypltr’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xstandard14a.adb:258:9: warning: trampoline generated for nested function ‘xstandard14a.plot5.mypltr’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xtraditional16a.adb:103:5: warning: trampoline generated for nested function ‘xtraditional16a.zdefined’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xstandard16a.adb:103:5: warning: trampoline generated for nested function ‘xstandard16a.zdefined’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xtraditional19a.adb:68:5: warning: trampoline generated for nested function ‘xtraditional19a.map_transform’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xtraditional19a.adb:97:5: warning: trampoline generated for nested function ‘xtraditional19a.mapform19’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xtraditional19a.adb:124:5: warning: trampoline generated for nested function ‘xtraditional19a.geolocation_labeler’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xstandard19a.adb:68:5: warning: trampoline generated for nested function ‘xstandard19a.map_transform’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xstandard19a.adb:97:5: warning: trampoline generated for nested function ‘xstandard19a.mapform19’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xstandard19a.adb:124:5: warning: trampoline generated for nested function ‘xstandard19a.geolocation_labeler’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xtraditional22a.adb:140:5: warning: trampoline generated for nested function ‘xtraditional22a.transform’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xstandard22a.adb:140:5: warning: trampoline generated for nested function ‘xstandard22a.transform’ [-Wtrampolines] -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.
Re: [Plplot-devel] The Debian PLplot fails
On 11/2/21 10:40, Rafael Laboissière wrote: > * Orion Poplawski [2021-10-30 16:32]: >> >> So, it appears that the Fedora plplot package is building fine with sip >> 6.3.1. Perhaps you may find some clues there, though I'm not sure we >> re-generate the bindings in our builds. > > Are the Fedora build logs available somewhere. I mean, like in Debian: > https://buildd.debian.org/status/package.php?p=plplot > > Best, > > Rafael Laboissière https://koji.fedoraproject.org/koji/packageinfo?packageID=3493 -- Orion Poplawski IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] The Debian PLplot fails
On 10/30/21 15:38, Alan W. Irwin wrote: On 2021-10-30 20:33+0100 António Rodrigues Tomé wrote: Hi Alan I do not know if I will be able to solve in short/medium time whatever the problem is as I usually do not use python or pyqt. So I will try to learn what this is all about. Thanks for being willing to take this on. Sip (which is how we generate our pyqt bindings) advertises itself as a really easy-to-use method of generating such bindings. So by consulting that sip documentation page (referenced in my recent email), you might be able to very quickly figure out what to do for the latest sip version. If/when you get modern sip to generate our pyqt5 binding by hand, I would be happy to help with any CMake-related adjustments that need to be made. For example, I have just discovered that "sip -V" generates the sip version string which would allow me to create a simple CMake test for the sip version. That test would allow us to use the present method for old sip versions and any new method you figure out for later sip versions. So, it appears that the Fedora plplot package is building fine with sip 6.3.1. Perhaps you may find some clues there, though I'm not sure we re-generate the bindings in our builds. -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] swig (and thus plplot) support for octave 6.1
PLplot folks - I'm looking to update the octave package in Fedora to version 6.1. However swig 4.0.2 fails to build against it. According to swig upstream here: https://github.com/swig/swig/issues/1893 the former swig-octave maintainer has stepped away, so support will have to come from the users of swig-octave. Anyone here have some time and interest? Thanks, Orion -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plplot build fails with Qt 5.15.1
On 9/13/20 1:42 PM, António Rodrigues Tomé wrote: hi orion this was solved in the commit [2aa2e1] so you should use the development version. download it using git clone git://git.code.sf.net/p/plplot/plplot <http://git.code.sf.net/p/plplot/plplot> plplot.git cheers António - Thanks for the reference. That commit fixes the build. Orion On Sun, Sep 13, 2020 at 12:58 AM Orion Poplawski <mailto:or...@nwra.com>> wrote: Fedora rawhide just updated from Qt 5.14.2 to 5.15.1 and now the plplot build fails with: [ 63%] Built target xstandard08a /builddir/build/BUILD/plplot-5.15.0/bindings/qt_gui/plqt.cpp: In member function 'void QtPLDriver::drawTextInPicture(QPainter*, const QString&)': /builddir/build/BUILD/plplot-5.15.0/bindings/qt_gui/plqt.cpp:222:22: error: aggregate 'QPainterPath path' has incomplete type and cannot be defined 222 | QPainterPath path; | ^~~~ A quick google search of this error indicates that it has hit a number of projects and there are some example fixes out there, e.g.: https://github.com/Nheko-Reborn/nheko/issues/214 HTH, Orion -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com <mailto:or...@nwra.com> Boulder, CO 80301 https://www.nwra.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net <mailto:Plplot-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/plplot-devel -- António Rodrigues Tomé Universidade da Beira Interior Instituto D. Luís (lab associado) email address: art...@gmail.com <mailto:art...@gmail.com> art...@ubi.pt <mailto:art...@ubi.pt> http://www.researcherid.com/rid/A-5681-2013 -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] plplot build fails with Qt 5.15.1
Fedora rawhide just updated from Qt 5.14.2 to 5.15.1 and now the plplot build fails with: [ 63%] Built target xstandard08a /builddir/build/BUILD/plplot-5.15.0/bindings/qt_gui/plqt.cpp: In member function 'void QtPLDriver::drawTextInPicture(QPainter*, const QString&)': /builddir/build/BUILD/plplot-5.15.0/bindings/qt_gui/plqt.cpp:222:22: error: aggregate 'QPainterPath path' has incomplete type and cannot be defined 222 | QPainterPath path; | ^~~~ A quick google search of this error indicates that it has hit a number of projects and there are some example fixes out there, e.g.: https://github.com/Nheko-Reborn/nheko/issues/214 HTH, Orion -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] FindLua
Is cmake/modules/FindLua.cmake useful anymore? For Fedora rawhide with Lua 5.4 I'm removing it so that we use the patched system version from cmake that can find 5.4. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plplot fails to build with ocaml 1.08
On 5/22/20 11:32 AM, Richard W.M. Jones wrote: On Fri, May 22, 2020 at 10:09:31AM -0700, Alan W. Irwin wrote: On 2020-05-22 16:31+0100 Richard W.M. Jones wrote: Xavier changed cpp -traditional back to cpp (https://github.com/xavierleroy/camlidl/issues/18), and I have added the new camlidl 1.09 to Rawhide. I will rebuild plplot against this shortly. Thanks, Orion, for initiating camlidl bug 18 and Richard (and Xavier) for following up on it. From the discussion there, it sounds like all is now well with unit testing of the problem, and I therefore assume the above test with a full PLplot build will confirm that. And if so, kudos to everybody for figuring out this issue so swiftly. Build here: https://koji.fedoraproject.org/koji/taskinfo?taskID=44826613 Seems to be going OK so far. Rich. Awesome, thanks Rich and everyone. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plplot fails to build with ocaml 1.08
On 5/21/20 2:01 PM, Alan W. Irwin wrote: Hi Orion: Thanks for your report. On 2020-05-20 21:28-0600 Orion Poplawski wrote: With the update from ocaml 1.05 to 1.08 plplot now fails to build: The ocaml versions on Debian Buster are 4.0.5* while the camlidl version there is 1.0.5*, and it is camlidl that failed below. Therefore, I assume you meant camlidl rather than ocaml above. Indeed, sorry for the confusion. [ 4%] Generating plplot_core.idl, plplot_core.mli, plplot_core.ml, plplot_core_stubs.c, plplot_core.h cd /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml && /usr/bin/cmake -E copy /builddir/build/BUILD/plplot-5.15.0/bindings/ocaml/plplot_core.idl /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml/plplot_core.idl cd /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml && /usr/bin/camlidl -I /builddir/build/BUILD/plplot-5.15.0/bindings/ocaml -header plplot_core.idl File plplot_core.idl, line 369, column 13: Illegal character # This line is: RAW_ML(external plgriddata : float array -> float array -> float array -> float array -> float array -> plplot_grid_method_type -> float -> float array array = "ml_plgriddata_bytecode" "ml_plgriddata") The macros involved are: #define QUOTEME(x) #x #define RAW_ML(x) quote(mlmli, QUOTEME(x)); Now, I know nothing about ocaml so I'm hoping Richard can clue us in on what has changed. For your information, here is the effect of the RAW_ML macro (as generated by camlidl Version: 1.05-15.1 on Debian Buster = Stable). software@merlin> grep -i plgriddata plplot_core* |grep -iv binary plplot_core.idl:// Hand-translated PL_GRID_* flags for use with plgriddata plplot_core.idl:RAW_ML(external plgriddata : float array -> float array -> float array -> float array -> float array -> plplot_grid_method_type -> float -> float array array = "ml_plgriddata_bytecode" "ml_plgriddata") plplot_core.ml:external plgriddata : float array -> float array -> float array -> float array -> float array -> plplot_grid_method_type -> float -> float array array = "ml_plgriddata_bytecode" "ml_plgriddata" plplot_core.mli:external plgriddata : float array -> float array -> float array -> float array -> float array -> plplot_grid_method_type -> float -> float array array = "ml_plgriddata_bytecode" "ml_plgriddata" So RAW_ML appears to do what its name implies (generate an exact copy in the relevant output files generated by camlidl). But my OCaml (and camlidl) knowledge is pretty limited as well so I don't understand (at all) how that simple result is implemented with the macros #define QUOTEME(x) #x #define RAW_ML(x) quote(mlmli, QUOTEME(x)); So I also hope you can get help from Richard on how this result is generated, but since the result is so simple, my best guess is this issue is due to a bug in the particular pre-release 1.0.8 version that Fedora has decided to package. I am tied up with a large number of different projects for the next month or so. But when I get a free moment (and if this Fedora issue has not been resolved by then), I will attempt to obtain the latest camlidl from <https://github.com/xavierleroy/camlidl> to see if I can replicate the issue you have found. N.B. from the latest commit message there, 1.0.8 hasn't actually been released yet. Therefore, if the issue is because of a bug in the particular pre-release version of camlidl that Fedora has packaged, then it is alway possible that Xavier Leroy has already fixed this bug in a later pre-release version. But if changing the Fedora package to the latest pre-release version does not fix the current issue, then I would recommend you contact Xavier Leroy about this issue to see if he can fix it before he releases 1.0.8. Good luck, and let me know how it goes. Alan I've filed this with camlidl: https://github.com/xavierleroy/camlidl/issues/18 hopefully they can help. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plplot fails to build with ocaml 1.08
On 5/21/20 3:01 AM, Richard W.M. Jones wrote:
On Wed, May 20, 2020 at 09:28:10PM -0600, Orion Poplawski wrote:
With the update from ocaml 1.05 to 1.08 plplot now fails to build:
4.05 -> 4.08 ?
Sorry, ocaml-camlidl 1.05 -> 1.08 . No ocaml change directly.
[ 4%] Generating plplot_core.idl, plplot_core.mli, plplot_core.ml,
plplot_core_stubs.c, plplot_core.h
cd /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml &&
/usr/bin/cmake -E copy
/builddir/build/BUILD/plplot-5.15.0/bindings/ocaml/plplot_core.idl
/builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml/plplot_core.idl
cd /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml &&
/usr/bin/camlidl -I
/builddir/build/BUILD/plplot-5.15.0/bindings/ocaml -header
plplot_core.idl
File plplot_core.idl, line 369, column 13: Illegal character #
This line is:
RAW_ML(external plgriddata : float array -> float array -> float
array -> float array -> float array -> plplot_grid_method_type ->
float -> float array array = "ml_plgriddata_bytecode"
"ml_plgriddata")
The macros involved are:
#define QUOTEME(x) #x
#define RAW_ML(x) quote(mlmli, QUOTEME(x));
Now, I know nothing about ocaml so I'm hoping Richard can clue us in
on what has changed.
I compiled plplot from git fine using OCaml 4.11 prerelease, so
probably the easiest thing is to move to the latest git version.
mkdir build
cd build
CFLAGS="%{optflags}" cmake .. -DENABLE_ocaml:BOOL=ON
make
Nothing has changed significantly under bindings/ocaml/ for a long
time, so I don't know why specifically it works from git and not from
the Fedora build. Maybe one of the huge number of cmake flags?
Rich.
I suspect without ocaml-camlidl-devel installed it won't build the above
code.
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] plplot fails to build with ocaml 1.08
With the update from ocaml 1.05 to 1.08 plplot now fails to build: [ 4%] Generating plplot_core.idl, plplot_core.mli, plplot_core.ml, plplot_core_stubs.c, plplot_core.h cd /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml && /usr/bin/cmake -E copy /builddir/build/BUILD/plplot-5.15.0/bindings/ocaml/plplot_core.idl /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml/plplot_core.idl cd /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml && /usr/bin/camlidl -I /builddir/build/BUILD/plplot-5.15.0/bindings/ocaml -header plplot_core.idl File plplot_core.idl, line 369, column 13: Illegal character # This line is: RAW_ML(external plgriddata : float array -> float array -> float array -> float array -> float array -> plplot_grid_method_type -> float -> float array array = "ml_plgriddata_bytecode" "ml_plgriddata") The macros involved are: #define QUOTEME(x) #x #define RAW_ML(x) quote(mlmli, QUOTEME(x)); Now, I know nothing about ocaml so I'm hoping Richard can clue us in on what has changed. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Issue with ocaml in tree tests
On 9/23/19 8:51 PM, Alan W. Irwin wrote: On 2019-09-22 20:06-0600 Orion Poplawski wrote: I'm trying to update the Fedora plplot package to 5.15.0 but running into the problem that the build tree rpath is not being set: plplot-5.15.0/fedora/examples/ocaml/CMakeFiles/target_x13ocaml.dir/build.make: cd /home/orion/fedora/plplot/plplot-5.15.0/fedora/examples/ocaml && /usr/bin/ocamlopt.opt -g -I /home/orion/fedora/plplot/plplot-5.15.0/fedora/bindings/ocaml -ccopt "-L /home/orion/fedora/plplot/plplot-5.15.0/fedora/src -Wl,-rpath -Wl, " plplot.cmxa -o x13ocaml x13.ml The problem is we build with USE_RPATH=OFF but the ocaml_RPATH variables are only set with USE_RPATH=ON. I think we want a special case to always set the build_*_RPATH variables. Hi Orion: Good catch. This build-system bug for the combination of ocaml and -DUSE_RPATH=OFF in the core build tree is now fixed in the git commit described (using "git describe master") as plplot-5.15.0-37-g6b215267e. Alan Thanks. That does the trick. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Issue with ocaml in tree tests
I'm trying to update the Fedora plplot package to 5.15.0 but running into the problem that the build tree rpath is not being set: plplot-5.15.0/fedora/examples/ocaml/CMakeFiles/target_x13ocaml.dir/build.make: cd /home/orion/fedora/plplot/plplot-5.15.0/fedora/examples/ocaml && /usr/bin/ocamlopt.opt -g -I /home/orion/fedora/plplot/plplot-5.15.0/fedora/bindings/ocaml -ccopt "-L /home/orion/fedora/plplot/plplot-5.15.0/fedora/src -Wl,-rpath -Wl, " plplot.cmxa -o x13ocaml x13.ml The problem is we build with USE_RPATH=OFF but the ocaml_RPATH variables are only set with USE_RPATH=ON. I think we want a special case to always set the build_*_RPATH variables. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] swig 4.0.0 issues
On 5/7/19 3:27 PM, Alan W. Irwin wrote: On 2019-05-06 19:12-0600 Orion Poplawski wrote: FYI - swig 4.0.0 just landed in Fedora Rawhide and it looks like it broke plplot's python bindings: Hi Orion: Thanks for this report, but for once I am (slightly) ahead of you. :-) Try the latest git version where this issue has been fixed. See commit plplot-5.14.0-38-g6b00b9717. No promises at this stage, but I am hoping to stick to a 6-month release cycle, i.e., I hope to release plplot-5.15.0 (with this important fix, the Qt5 important font fix, and several others) within a month or so. Thanks. Looks like someone filed a Fedora bug with a patch as well so I'm all set now. BTW - I have no idea how to find the above commit ID. It git proper it seems to be 6b00b9717a6c98ee16e49f991957f91cb5b76c1f -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] swig 4.0.0 issues
FYI - swig 4.0.0 just landed in Fedora Rawhide and it looks like it broke plplot's python bindings: https://apps.fedoraproject.org/koschei/package/plplot?collection=f31 Start 5: examples_python 5: Test command: /usr/bin/bash "-c" "EXAMPLES_PREFIX=/builddir/build/BUILD/plplot-5.14.0/fedora/examples SRC_EXAMPLES_PREFIX=/builddir/build/BUILD/plplot-5.14.0/examples OUTPUT_DIR=/builddir/build/BUILD/plplot-5.14.0/fedora/ctest_examples_output_dir VC_CTEST_DIRECTORY= ./plplot-test.sh --verbose --device=svg --front-end=python" 5: Test timeout computed to be: 15000 5: Testing front-end python 5: x00 5: x01 5: x02 5: x03 5: x04 5: x05 5: x06 5: x07 5: x08 5: x09 5: x10 5: x11 5: x12 5: x13 5: x15 5: x16 5: x18 5: x19 5: x20 5: call to python pltr function with 3 arguments failed 5: call to python pltr function with 3 arguments failed 5: call to python pltr function with 3 arguments failed 5: call to python pltr function with 3 arguments failed 5: call to python pltr function with 3 arguments failed I haven't had a chance to investigate yet... -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Help needed for plplot runtime tests
On 11/24/18 11:55 AM, Alan W. Irwin wrote: Hi Orion: This thread has previously been directed mostly at Ole, but I am including you now because I think it will interest you. It concerns the problems (one of them upstream which I plan to fix soon by factoring the export files [as I promised you long ago, but it got lost on the stack until Ole ran into this problem again!]) that Ole has been having with Debian to get testing working properly for the installed examples. I would appreciate you contributing to this thread. For example, if all Fedora binary packages are installed (which works around the above factoring problem until I can get it fixed) do the following tests of the CMake-based and legacy-based installed examples work? # CMake-based build system for the installed examples # Move to initially empty build tree first. rm -rf /tmp/plplot_cmake_test mkdir /tmp/plplot_cmake_test cd /tmp/plplot_cmake_test cmake $prefix/share/plplot$plplot_version/examples make -j test_noninteractive >& test_noninteractive.out # Legacy-based build system for the installed examples # Keep the install-tree clean by copying the installed examples elsewhere cp -a $prefix/share/plplot$plplot_version/examples /tmp cd /tmp/examples make -j test_noninteractive >& test_noninteractive.out If the above tests work on Fedora that proves that the Fedora PLplot installation has correctly configured CMake export and pkg-config *.pc files for the final Fedora installation locations. Currently such tests fail for Ole's Debian packages, but I think some attention to the details of PLplot installation locations will solve this issue. And similarly in your case if those tests fail for Fedora. Alan It mostly seems to work fine. The one strange error for cmake is: Generate C results for bmpqt file device /usr/share/plplot5.13.0/examples/test_lua.sh: line 50: lua_svg_test.error: Permission denied [ 92%] Built target xtraditional16a cat: lua_svg_test.error: No such file or directory make[3]: *** [CMakeFiles/test_lua_svg.dir/build.make:374: test_examples_output_dir/x00lua01.svg] Error 1 and for make/pkgconfig: Generate Octave results for svg device ./plplot-test.sh --verbose --front-end=octave --device=svg /usr/bin/bash: ./plplot-test.sh: Permission denied make: *** [Makefile:126: x01o01.svg] Error 126 which is due to my removing the executable bit for the example script to avoid issues with automatic dependencies. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Plplot now working well with Debian Buster + release timing
On 09/20/2018 12:22 AM, Alan W. Irwin wrote: On 2018-09-19 22:06-0600 Orion Poplawski wrote: On 09/15/2018 01:49 PM, Alan W. Irwin wrote: To Orion and Ole: Commit a730ebe34 has removed the last of the "new software" issues I have identified with Debian Testing = Buster. @Orion: I encourage you to try that commit on Fedora to see if you get similarly good results for all Linux-available components of PLplot for that other cutting-edge Linux platform. @Both: You both also might want to experiment with this commit as the basis for much-improved PLplot packages for Fedora and Debian. However such packages can only be considered preliminary until PLplot makes an official release. What I can say on that topic is commit a730ebe34 is an important milestone on the trail to the next release, but we are not there yet. For example, the CMake test that is automatically produced every night by my computer for the CMake developers builds and tests the latest CMake. One of those tests is the PLplot contract test which tests whether a build (but not test) of PLplot is successful. That test is formally succeeding, but those PLplot builds are incomplete (with the cairo device driver dropped) because of incompatibilities with the way we configure our cairo device driver using internal details of the CMake pkg-config capability. Although the use of such internal details has worked well over many years with few adjustments needed for changes to those internal details with CMake version, it is again no longer working with the very latest CMake. This reflects the fundamental fragility of any method that uses internal details. Therefore, to deal with this issue my plan is to completely rewrite our support for the cairo device using the official CMake pkg-config support rather than internal details of that support. And there are also a few other topics I would like to squeeze into the next release. So this makes the ETA of our next PLplot release still somewhat uncertain, but I am still hoping to get it done this year (before Christmas season) rather than early next year. Latest git (a9d9500c) built on Fedora Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=29771905 Despite the overall failure to build, looks mostly okay, but it appears that you don't support lua 5.3: -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact version "5.2") -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact version "5.1") -- LUA_INCLUDE_DIR = -- LUA_LIBRARIES = /usr/lib64/liblua.so;/usr/lib64/libm.so -- WARNING: Lua header and/or library not found. Disabling Lua binding Hi Orion: Thanks for that feedback. Lua5.3 worked here (Debian Testing = Buster) for all but one example, but that one example exposed a Lua-5.3 bug (at least for the Debian version of Lua5.3) that was severe (arithmetic quit working if more than 8 (!) arrays were initialized). See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for a simple Lua script that triggers this Lua-5.3 bug and other details about this bug. I temporarily worked around the problem by using our build system to blacklist Lua-5.3 until this bug is fixed (i.e., in the absence of Lua5.1 or 5.2 our build system should just cleanly drop the Lua PLplot component and continue). Please try that simple Lua script to see whether the Fedora version of Lua-5.3 also has this severe bug. If you do confirm, then that is pretty good evidence it is a general Lua-5.3 bug (rather than just Debian related), and in this case I would be willing to take this issue to the Lua developers rather than waiting for some response to my bug report from the Debian packagers. It appears from <https://kojipkgs.fedoraproject.org//work/tasks/1906/29771906/build.log> the blacklisting worked without actual build issues (as expected), but the actual error you get is because your rpm logic is expecting Lua files from PLplot that are not there because of the blacklisting. So your response to this issue likely depends on whether you can get the above simple test script to work for Fedora's version of Lua5.3. If that test actually works for Fedora, then it appears the Lua5.3 issue is simply a Debian packaging issue that has nothing to do with Fedora, and you should edit cmake/modules/lua.cmake to make the slight change to look first for 5.3, then 5.2, then 5.1. However, if that test also fails for you, and you think the upstream Lua5.3 fix is going to take a while to get fixed, then you should change your rpm logic to drop all the expected Lua results. Alan I replied to the debian bug. It appears that lua 5.3.5 on Fedora rawhide is fine. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ __
Re: [Plplot-devel] Plplot now working well with Debian Buster + release timing
On 09/15/2018 01:49 PM, Alan W. Irwin wrote: To Orion and Ole: Commit a730ebe34 has removed the last of the "new software" issues I have identified with Debian Testing = Buster. @Orion: I encourage you to try that commit on Fedora to see if you get similarly good results for all Linux-available components of PLplot for that other cutting-edge Linux platform. @Both: You both also might want to experiment with this commit as the basis for much-improved PLplot packages for Fedora and Debian. However such packages can only be considered preliminary until PLplot makes an official release. What I can say on that topic is commit a730ebe34 is an important milestone on the trail to the next release, but we are not there yet. For example, the CMake test that is automatically produced every night by my computer for the CMake developers builds and tests the latest CMake. One of those tests is the PLplot contract test which tests whether a build (but not test) of PLplot is successful. That test is formally succeeding, but those PLplot builds are incomplete (with the cairo device driver dropped) because of incompatibilities with the way we configure our cairo device driver using internal details of the CMake pkg-config capability. Although the use of such internal details has worked well over many years with few adjustments needed for changes to those internal details with CMake version, it is again no longer working with the very latest CMake. This reflects the fundamental fragility of any method that uses internal details. Therefore, to deal with this issue my plan is to completely rewrite our support for the cairo device using the official CMake pkg-config support rather than internal details of that support. And there are also a few other topics I would like to squeeze into the next release. So this makes the ETA of our next PLplot release still somewhat uncertain, but I am still hoping to get it done this year (before Christmas season) rather than early next year. Latest git (a9d9500c) built on Fedora Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=29771905 Despite the overall failure to build, looks mostly okay, but it appears that you don't support lua 5.3: -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact version "5.2") -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact version "5.1") -- LUA_INCLUDE_DIR = -- LUA_LIBRARIES = /usr/lib64/liblua.so;/usr/lib64/libm.so -- WARNING: Lua header and/or library not found. Disabling Lua binding -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] libieee.a is no more
On 12/12/2017 04:42 PM, Alan W. Irwin wrote: On 2017-12-12 15:36-0700 Orion Poplawski wrote: Apparently glibc is dropping libieee.a in the next release. In Fedora Rawhide, -mieee-fp on i686 results in: /usr/bin/ld: Cannot find -lieee Dropping -mieee-fp from csiro.cmake fixes it for me. Hi Orion: For i686 hardware and your patched case, what is the result of the test? In other words, does the CMake output say "Check for NaN awareness in C compiler - found" or "Check for NaN awareness in C compiler - not found" followed by WARNING: Setting PL_HAVE_QHULL and WITH_CSA to OFF. ? The latter result is a fairly serious constraint on our plgrid function for i686 hardware. So I am hoping for the former result since that simply means the gcc option -mieee-fp is no longer required to get this NaN test to work correctly on i686 hardware. Alan __ Alan W. Irwin Sorry I wasn't clear. The test was failing because of the compile error. With the patch the test returns "found" and the build is normal/successful. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] libieee.a is no more
Apparently glibc is dropping libieee.a in the next release. In Fedora
Rawhide, -mieee-fp on i686 results in:
/usr/bin/ld: Cannot find -lieee
Dropping -mieee-fp from csiro.cmake fixes it for me. Also works with glibc
2.25. Not sure about older ones.
diff -up plplot-5.12.0/cmake/modules/csiro.cmake.ieee
plplot-5.12.0/cmake/modules/csiro.cmake
--- plplot-5.12.0/cmake/modules/csiro.cmake.ieee2017-01-28
18:50:35.0 -0700
+++ plplot-5.12.0/cmake/modules/csiro.cmake 2017-12-12 15:05:56.964587720
-0700
@@ -27,17 +27,13 @@ option(WITH_CSA "Enable use of the csa l
# expanded to a lot more cases as we gain platform experience.
set(NAN_CFLAGS ${CMAKE_C_FLAGS})
if(PL_HAVE_QHULL OR WITH_CSA)
- if(CMAKE_SYSTEM_PROCESSOR MATCHES "i[0-9]86")
-set(NAN_CFLAGS "${NAN_CFLAGS} -mieee-fp")
- else(CMAKE_SYSTEM_PROCESSOR MATCHES "i[0-9]86")
-if(CMAKE_SYSTEM_PROCESSOR MATCHES "alpha.*")
- if(CMAKE_C_COMPILER MATCHES "gcc")
-set(NAN_CFLAGS "${NAN_CFLAGS} -mieee")
- else(CMAKE_C_COMPILER MATCHES "gcc")
-set(NAN_CFLAGS "${NAN_CFLAGS} -ieee")
- endif(CMAKE_C_COMPILER MATCHES "gcc")
-endif(CMAKE_SYSTEM_PROCESSOR MATCHES "alpha.*")
- endif(CMAKE_SYSTEM_PROCESSOR MATCHES "i[0-9]86")
+ if(CMAKE_SYSTEM_PROCESSOR MATCHES "alpha.*")
+if(CMAKE_C_COMPILER MATCHES "gcc")
+ set(NAN_CFLAGS "${NAN_CFLAGS} -mieee")
+else(CMAKE_C_COMPILER MATCHES "gcc")
+ set(NAN_CFLAGS "${NAN_CFLAGS} -ieee")
+endif(CMAKE_C_COMPILER MATCHES "gcc")
+ endif(CMAKE_SYSTEM_PROCESSOR MATCHES "alpha.*")
if(NOT DEFINED NaNAwareCCompiler)
message(STATUS "Check for NaN awareness in C compiler")
try_run(NaNAwareCCompiler COMPILE_RESULT
Fedora doesn't build for alpha, so no idea there.
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Patch for OCaml 4.06
Fedora patch to fix build with OCaml 4.0.6. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ --- plplot-5.12.0.old/examples/ocaml/x20.ml 2017-01-29 01:50:35.0 + +++ plplot-5.12.0/examples/ocaml/x20.ml 2017-11-18 12:10:33.476409441 + @@ -59,7 +59,7 @@ let w, h = Scanf.sscanf w_h_line "%d %d" (fun w h -> w, h) in let num_col = Scanf.sscanf num_col_line "%d" (fun n -> n) in - let img = String.make (w * h) ' ' in + let img = Bytes.make (w * h) ' ' in let imf = Array.make_matrix w h 0.0 in (* Note that under 32bit OCaml, this will only work when reading strings up @@ -72,7 +72,7 @@ for j = 0 to h - 1 do imf.(i).(j) <- (* flip image up-down *) -float_of_int (int_of_char (img.[(h - 1 - j ) * w + i])); +float_of_int (int_of_char (Bytes.get img ((h - 1 - j ) * w + i))); done done; imf, w, h, num_col -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] PLplot Debian package
Hello all On 07/14/2017 02:18 PM, Alan W. Irwin wrote: > To Ole and Orion: > > @Ole: > > To introduce Orion, he maintains the packaging of PLplot for Fedora, > and he has been a big help to us when dealing with "library > version" issues. > > @Orion: > > To introduce Ole, he is the new maintainer of PLplot packaging for > Debian, and it appears he has been running into some "library > version" issues (at least in the Octave-4.2 case) that you have also > run into in the past. > > On 2017-07-14 09:40+0200 Ole Streicher wrote: > >> On 13.07.2017 21:49, Alan W. Irwin wrote: >> [Octave bindings] >>> So I suggest you try enabling it, and then follow up with a build of >>> the test_diff_psc target. If that test works, i.e., it produces the >>> good octave results above, then I think you can be pretty confident >>> all is well with an octave4 binding of PLplot. >> >> I tried, but then I got many error about op_lshift: >> >> [ 10%] Building CXX object >> bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o >> cd /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave && >> /usr/bin/c++ -DPLPLOT_HAVE_CONFIG_H -Dplplot_octave_EXPORTS >> -I/build/plplot-5.12.0+dfsg/include -I/build/plplot-5.12.0+dfsg/lib/qsastime >> -I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu >> -I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/include >> -I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave >> -I/usr/include/hdf5/serial -I/usr/include/octave-4.2.1 >> -I/usr/include/octave-4.2.1/octave >> -I/build/plplot-5.12.0+dfsg/bindings/swig-support -g -O2 >> -fdebug-prefix-map=/build/plplot-5.12.0+dfsg=. -fstack-protector-strong >> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 >> -I/usr/include/octave-4.2.1/octave/.. -I/usr/include/octave-4.2.1/octave >> -I/usr/include/hdf5/serial -Wdate-time -D_FORTIFY_SOURCE=2 >> -I/usr/include/octave-4.2.1/octave/.. -I/usr/include/octave-4.2.1/octave >> -I/usr/include/hdf5/serial -fPIC -o >> CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c >> /build/plplot-5.1! > 2.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx >> In file included from >> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:181:0: >> >> /usr/include/octave-4.2.1/octave/toplev.h:28:2: warning: #warning "toplev.h >> has been deprecated; use interpreter.h instead" [-Wcpp] >> #warning "toplev.h has been deprecated; use interpreter.h instead" >> ^~~ >> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: >> In function 'void SWIG_InstallBinaryOps(int, int)': >> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2099:46: >> error: 'op_lshift' is not a member of 'octave_value' >> if >> (!octave_value_typeinfo::lookup_binary_op(octave_value::op_##name,tid1,tid2)) >> \ >> ^ >> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2147:5: >> note: in expansion of macro 'swigreg_binary_op' >> swigreg_binary_op(lshift); >> ^ >> >> and a number of warnings about octave_value::octave_value: >> >> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: >> In function 'octave_value_list _wrap_plGetCursor(const octave_value_list&, >> int)': >> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:10770:60: >> warning: 'octave_value::octave_value(const charMatrix&, bool, char)' is >> deprecated: note: IS_STRING argument is ignored [-Wdeprecated-declarations] >> retval4( 0 ) = octave_value( charMatrix( 80, 1 ), true ); >>^ >> In file included from /usr/include/octave-4.2.1/octave/ovl.h:36:0, >> from /usr/include/octave-4.2.1/octave/ov-fcn.h:33, >> from /usr/include/octave-4.2.1/octave/ov-builtin.h:30, >> from /usr/include/octave-4.2.1/octave/defun-int.h:30, >> from /usr/include/octave-4.2.1/octave/defun-dld.h:32, >> from /usr/include/octave-4.2.1/octave/oct.h:32, >> from >> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:173: >> >> /usr/include/octave-4.2.1/octave/ov.h:244:3: note: declared here >> octave_value (c
[Plplot-devel] No swig support for octave 4.2
Just a heads up that currently swig does not support octave 4.2. You get errors like: [ 10%] Building CXX object bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o cd /builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave && /usr/lib64/ccache/c++ -DPLPLOT_HAVE_CONFIG_H -Dplplot_octave_EXPORTS -I/builddir/build/BUILD/plplot-5.11.1-7756f60/include -I/builddir/build/BUILD/plplot-5.11.1-7756f60/lib/qsastime -I/builddir/build/BUILD/plplot-5.11.1-7756f60/fedora -I/builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/include -I/builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave -I/usr/include/octave-4.2.0 -I/usr/include/octave-4.2.0/octave -I/builddir/build/BUILD/plplot-5.11.1-7756f60/bindings/swig-support -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fPIC -o CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c /builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx In file included from /builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:181:0: /usr/include/octave-4.2.0/octave/toplev.h:28:2: warning: #warning "toplev.h has been deprecated; use interpreter.h instead" [-Wcpp] #warning "toplev.h has been deprecated; use interpreter.h instead" ^~~ /builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In function 'void SWIG_InstallBinaryOps(int, int)': /builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2099:46: error: 'op_lshift' is not a member of 'octave_value' if (!octave_value_typeinfo::lookup_binary_op(octave_value::op_##name,tid1,tid2)) \ ^ /builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2147:5: note: in expansion of macro 'swigreg_binary_op' swigreg_binary_op(lshift); ^ /builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2100:43: error: 'op_lshift' is not a member of 'octave_value' octave_value_typeinfo::register_binary_op(octave_value::op_##name,tid1,tid2,swig_binary_op_##name); ^ /builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2147:5: note: in expansion of macro 'swigreg_binary_op' swigreg_binary_op(lshift); ^ /builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2099:46: error: 'op_rshift' is not a member of 'octave_value' if (!octave_value_typeinfo::lookup_binary_op(octave_value::op_##name,tid1,tid2)) \ ^ /builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2148:5: note: in expansion of macro 'swigreg_binary_op' swigreg_binary_op(rshift); ^ /builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2100:43: error: 'op_rshift' is not a member of 'octave_value' octave_value_typeinfo::register_binary_op(octave_value::op_##name,tid1,tid2,swig_binary_op_##name); ^ /builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2148:5: note: in expansion of macro 'swigreg_binary_op' swigreg_binary_op(rshift); ^ See https://github.com/swig/swig/issues/847 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] ocaml cairo
Re:
commit 893625ca34ed22f4d8941f9902aa71bf30eaf8fb
Author: Alan W. Irwin <air...@users.sourceforge.net>
Date: Sat Oct 24 13:30:10 2015 -0700
Build system: Disable OCAML_HAS_CAIRO
I have taken this step because substantial maintenance will be
required before this component of PLplot will configure, build, or run
again because of backwards incompatibilities that have been introduced
in ocaml support of cairo. For example, the package name "cairo2" no
longer exists any more and should probably be replaced by the package
name cairo, but that is just the start of the backwards
incompatibilities.
diff --git a/cmake/modules/ocaml.cmake b/cmake/modules/ocaml.cmake
index 0403abd..a106ed2 100644
--- a/cmake/modules/ocaml.cmake
+++ b/cmake/modules/ocaml.cmake
@@ -2,7 +2,7 @@
#
# Copyright (C) 2008 Andrew Ross
# Copyright (C) 2009 Hezekiah M. Carty
-# Copyright (C) 2009-2014 Alan W. Irwin
+# Copyright (C) 2009-2015 Alan W. Irwin
#
# This file is part of PLplot.
#
@@ -196,6 +196,9 @@ if(ENABLE_ocaml)
if(OCAMLFIND)
if(PLD_extcairo)
option(OCAML_HAS_CAIRO "OCaml has the cairo package" ON)
+ # Disable since substantial maintenance is required before this component
+ # of PLplot will configure, build, and/or run.
+ set(OCAML_HAS_CAIRO OFF CACHE BOOL "OCaml has the cairo package" FORCE)
if(OCAML_HAS_CAIRO)
set(text_cairo "module C = Cairo")
file(WRITE ${CMAKE_BINARY_DIR}/test_cairo.ml ${text_cairo})
It would be nice if the message was changed to something like "plplot ocaml
cairo support currently disabled", so avoid having people like me spend time
figuring out why it's not finding the cairo package. Thanks.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] octave 4
-- OCTAVE_VERSION = 4.0.3 -- WARNING: Octave-4 has been found which is likely to lead to build errors for PLplot. -- WARNING: TRY_OCTAVE4 = ON so experimentally trying Octave-4 Is this still experimental? Octave 4 has been out for a while now. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] qhull 2015
qhull 2015 uses new directories for the include files: - Include headers prefixed with libqhull/, libqhull_r/, or libqhullcpp/ The _r is a re-entrant version apparently. From http://www.qhull.org/ Qhull 2015.2 introduces reentrant Qhull. It allows concurrent Qhull runs and simplifies the C++ interface to Qhull. If you call Qhull from your program, you should use reentrant Qhull (libqhull_r) instead of qh_QHpointer (libqhull). So at the moment phplot does not find qhull because it is looking for qhull/qhull_a.h. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Fwd: [Bug 1295175] New: plplot contain problematic content
This does look like a problem, unless there is specific permission for this file? Forwarded Message Subject: [Bug 1295175] New: plplot contain problematic content Date: Sun, 03 Jan 2016 08:08:59 + From: bugzi...@redhat.com To: or...@cora.nwra.com https://bugzilla.redhat.com/show_bug.cgi?id=1295175 Bug ID: 1295175 Summary: plplot contain problematic content Product: Fedora Version: rawhide Component: plplot Assignee: or...@cora.nwra.com Reporter: kame55-itasenpara...@y2.dion.ne.jp QA Contact: extras...@fedoraproject.org CC: or...@cora.nwra.com Hello. plplot included non-free image. This is "Lena" (Lenna) image. (PGM and IMG file) This file license (Copyright) is non-free, and this content is violate Fedora Packaging Guideline. https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content Thanks. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] The D component of PLplot
On 11/09/2015 09:49 PM, Alan W. Irwin wrote: > On 2015-11-01 19:54-0700 Orion Poplawski wrote: > > [...] >> I don't enable D support on the Fedora package [] > > Hi Orion: > > Our D results with the gdc compiler on the Debian Jessie Linux > platform are perfect right now as measured by comparing C and D > results for all our standard examples. See the commit message giving > those latest test details at > <http://sourceforge.net/p/plplot/plplot/ci/16fe6dcb1e5acc3284f265af366eccc1b2099bfc>. > > Therefore, I encourage you to go ahead and package the D component of > PLplot for Fedora assuming gdc is packaged for that platform. Thanks for the detailed message. However, gdc is not packaged for Fedora. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready!
On 10/31/2015 11:10 AM, Alan W. Irwin wrote: Hi Orion: Thanks for implementing Brad's suggestion to fix the PLplot Ada language support issue for CMake-3.4. To help give you PLplot git credit for your work, would you please put the patch in "git format-patch" form? Attached. I also notice substantial use of in the PLplot D language support case. I assume your tests did not reveal any issues for D because you were not trying any D compiler flags, but I predict if you do that, you will encounter the same problem. For example, if you try export DFLAGS=-Iwhatever I assume that (harmless) compile flag will correctly propagate to the D compile step (as seen by the VERBOSE=1 option for make) for older versions of CMake but will not propagate correctly for CMake-3.4. Anyhow, I am virtually positive there is also a PLplot D language support issue for CMake-3.4 so if you don't beat me to it, I plan (likely late next week because I am currently tied up with something else) to expose that issue with a test like the one I suggested above and also plan to fix the issue following Brad's suggestion. I don't enable D support on the Fedora package, so I haven't looked at this. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com >From f72545a21c2aeb206a4e06d9329eb6019a22ea99 Mon Sep 17 00:00:00 2001 From: Orion Poplawski <or...@cora.nwra.com> Date: Sun, 1 Nov 2015 19:51:48 -0700 Subject: [PATCH] Add support for cmake 3.4 for Ada --- cmake/modules/language_support/cmake/CMakeAdaInformation.cmake | 10 +++--- .../cmake_experimental/Modules/CMakeAdaInformation.cmake | 10 +++--- cmake/test_ada/cmake_working/Modules/CMakeAdaInformation.cmake | 10 +++--- 3 files changed, 21 insertions(+), 9 deletions(-) diff --git a/cmake/modules/language_support/cmake/CMakeAdaInformation.cmake b/cmake/modules/language_support/cmake/CMakeAdaInformation.cmake index 4d9a78a..3f0e6a4 100644 --- a/cmake/modules/language_support/cmake/CMakeAdaInformation.cmake +++ b/cmake/modules/language_support/cmake/CMakeAdaInformation.cmake @@ -176,9 +176,13 @@ ENDIF(NOT CMAKE_Ada_CREATE_STATIC_LIBRARY) # compile a Ada file into an object file IF(NOT CMAKE_Ada_COMPILE_OBJECT) - SET(CMAKE_Ada_COMPILE_OBJECT -" -c -o -") + IF(NOT CMAKE_VERSION VERSION_LESS 3.4) +SET(CMAKE_Ada_COMPILE_OBJECT + " -c -o ") + ELSE() +SET(CMAKE_Ada_COMPILE_OBJECT + " -c -o ") + ENDIF() ENDIF(NOT CMAKE_Ada_COMPILE_OBJECT) # Constraints: GNAT_EXECUTABLE_BUILDER = gnatmake diff --git a/cmake/test_ada/cmake_experimental/Modules/CMakeAdaInformation.cmake b/cmake/test_ada/cmake_experimental/Modules/CMakeAdaInformation.cmake index 03d4db7..a0fcb40 100644 --- a/cmake/test_ada/cmake_experimental/Modules/CMakeAdaInformation.cmake +++ b/cmake/test_ada/cmake_experimental/Modules/CMakeAdaInformation.cmake @@ -147,9 +147,13 @@ ENDIF(NOT CMAKE_Ada_CREATE_STATIC_LIBRARY) # compile a Ada file into an object file IF(NOT CMAKE_Ada_COMPILE_OBJECT) - SET(CMAKE_Ada_COMPILE_OBJECT -" -c -o -") + IF(NOT CMAKE_VERSION VERSION_LESS 3.4) +SET(CMAKE_Ada_COMPILE_OBJECT + " -c -o ") + ELSE() +SET(CMAKE_Ada_COMPILE_OBJECT + " -c -o ") + ENDIF() ENDIF(NOT CMAKE_Ada_COMPILE_OBJECT) # Constraints: GNAT_EXECUTABLE_BUILDER = gnatmake diff --git a/cmake/test_ada/cmake_working/Modules/CMakeAdaInformation.cmake b/cmake/test_ada/cmake_working/Modules/CMakeAdaInformation.cmake index 4d9a78a..3f0e6a4 100644 --- a/cmake/test_ada/cmake_working/Modules/CMakeAdaInformation.cmake +++ b/cmake/test_ada/cmake_working/Modules/CMakeAdaInformation.cmake @@ -176,9 +176,13 @@ ENDIF(NOT CMAKE_Ada_CREATE_STATIC_LIBRARY) # compile a Ada file into an object file IF(NOT CMAKE_Ada_COMPILE_OBJECT) - SET(CMAKE_Ada_COMPILE_OBJECT -" -c -o -") + IF(NOT CMAKE_VERSION VERSION_LESS 3.4) +SET(CMAKE_Ada_COMPILE_OBJECT + " -c -o ") + ELSE() +SET(CMAKE_Ada_COMPILE_OBJECT + " -c -o ") + ENDIF() ENDIF(NOT CMAKE_Ada_COMPILE_OBJECT) # Constraints: GNAT_EXECUTABLE_BUILDER = gnatmake -- 2.4.3 -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready!
On 10/22/2015 11:30 AM, Brad King wrote: On 10/22/2015 11:28 AM, Orion Poplawski wrote: This appears to have broken plplot's ada build on Fedora. FYI - builds still fail with cmake 3.4.0-rc2. Have had time to look at it closer. plplot issue seems to be triggered by a change in Ada_FLAGS: -Ada_FLAGS = -I/home/orion/fedora/plplot/plplot-5.11.1/build-3.3.2/examples/ada -I/home/orion/fedora/plplot/plplot-5.11.1/bindings/ada +Ada_FLAGS = but plplot I believe has custom Ada cmake platform support. I am still concerned about possible regressions here. Plplot's Ada support uses CMake internal APIs so it is plplot's responsibility to adapt to our changes: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeAddNewLanguage.txt;hb=v3.4.0-rc2 Maintainers of external language support are responsible for porting it to each version of CMake as upstream changes are made. Our 3.4.0-rc2 release notes point out a change likely causing this problem: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/release/3.4.rst;hb=v3.4.0-rc2#l271 * The internal "CMAKE__COMPILE_OBJECT" rule variable now substitutes compiler include flags in a separate "" placeholder instead of the main "" placeholder. Where Plplot currently writes: SET(CMAKE_Ada_COMPILE_OBJECT " -c -o ") try: if(NOT CMAKE_VERSION VERSION_LESS 3.4) set(CMAKE_Ada_COMPILE_OBJECT " -c -o ") else() set(CMAKE_Ada_COMPILE_OBJECT " -c -o ") endif() -Brad Ah, thank you very much. The attached patch fixes this. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com diff -up plplot-5.11.1/cmake/modules/language_support/cmake/CMakeAdaInformation.cmake.cmake34 plplot-5.11.1/cmake/modules/language_support/cmake/CMakeAdaInformation.cmake --- plplot-5.11.1/cmake/modules/language_support/cmake/CMakeAdaInformation.cmake.cmake34 2015-08-12 11:35:27.0 -0600 +++ plplot-5.11.1/cmake/modules/language_support/cmake/CMakeAdaInformation.cmake 2015-10-29 14:47:44.505370445 -0600 @@ -176,9 +176,13 @@ ENDIF(NOT CMAKE_Ada_CREATE_STATIC_LIBRAR # compile a Ada file into an object file IF(NOT CMAKE_Ada_COMPILE_OBJECT) - SET(CMAKE_Ada_COMPILE_OBJECT -" -c -o -") + IF(NOT CMAKE_VERSION VERSION_LESS 3.4) +SET(CMAKE_Ada_COMPILE_OBJECT + " -c -o ") + ELSE() +SET(CMAKE_Ada_COMPILE_OBJECT + " -c -o ") + ENDIF() ENDIF(NOT CMAKE_Ada_COMPILE_OBJECT) # Constraints: GNAT_EXECUTABLE_BUILDER = gnatmake diff -up plplot-5.11.1/cmake/test_ada/cmake_experimental/Modules/CMakeAdaInformation.cmake.cmake34 plplot-5.11.1/cmake/test_ada/cmake_experimental/Modules/CMakeAdaInformation.cmake --- plplot-5.11.1/cmake/test_ada/cmake_experimental/Modules/CMakeAdaInformation.cmake.cmake34 2015-08-12 11:35:27.0 -0600 +++ plplot-5.11.1/cmake/test_ada/cmake_experimental/Modules/CMakeAdaInformation.cmake 2015-10-29 14:49:01.544790784 -0600 @@ -147,9 +147,13 @@ ENDIF(NOT CMAKE_Ada_CREATE_STATIC_LIBRAR # compile a Ada file into an object file IF(NOT CMAKE_Ada_COMPILE_OBJECT) - SET(CMAKE_Ada_COMPILE_OBJECT -" -c -o -") + IF(NOT CMAKE_VERSION VERSION_LESS 3.4) +SET(CMAKE_Ada_COMPILE_OBJECT + " -c -o ") + ELSE() +SET(CMAKE_Ada_COMPILE_OBJECT + " -c -o ") + ENDIF() ENDIF(NOT CMAKE_Ada_COMPILE_OBJECT) # Constraints: GNAT_EXECUTABLE_BUILDER = gnatmake diff -up plplot-5.11.1/cmake/test_ada/cmake_working/Modules/CMakeAdaInformation.cmake.cmake34 plplot-5.11.1/cmake/test_ada/cmake_working/Modules/CMakeAdaInformation.cmake --- plplot-5.11.1/cmake/test_ada/cmake_working/Modules/CMakeAdaInformation.cmake.cmake34 2015-08-12 11:35:27.0 -0600 +++ plplot-5.11.1/cmake/test_ada/cmake_working/Modules/CMakeAdaInformation.cmake 2015-10-29 14:48:39.296954258 -0600 @@ -176,9 +176,13 @@ ENDIF(NOT CMAKE_Ada_CREATE_STATIC_LIBRAR # compile a Ada file into an object file IF(NOT CMAKE_Ada_COMPILE_OBJECT) - SET(CMAKE_Ada_COMPILE_OBJECT -" -c -o -") + IF(NOT CMAKE_VERSION VERSION_LESS 3.4) +SET(CMAKE_Ada_COMPILE_OBJECT + " -c -o ") + ELSE() +SET(CMAKE_Ada_COMPILE_OBJECT + " -c -o ") + ENDIF() ENDIF(NOT CMAKE_Ada_COMPILE_OBJECT) # Constraints: GNAT_EXECUTABLE_BUILDER = gnatmake -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready!
On 10/07/2015 10:45 AM, Orion Poplawski wrote: > On 10/06/2015 09:00 PM, Orion Poplawski wrote: >> On 10/06/2015 09:42 AM, Robert Maynard wrote: >>> I am proud to announce the first CMake 3.4 release candidate. >> >> This appears to have broken plplot's ada build on Fedora. Previous good >> (cmake >> 3.3.2): >> >> [ 22%] Building Ada object examples/ada/CMakeFiles/x00a.dir/x00a.o >> cd /builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada && >> /usr/bin/gnatgcc >> -I/builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada >> -I/builddir/build/BUILD/plplot-5.11.1/bindings/ada-c >> /builddir/build/BUILD/plplot-5.11.1/examples/ada/x00a.adb -o >> CMakeFiles/x00a.dir/x00a.o >> >> New bad: >> >> [ 22%] Building Ada object examples/ada/CMakeFiles/x00a.dir/x00a.o >> cd /builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada && >> /usr/bin/gnatgcc -c >> /builddir/build/BUILD/plplot-5.11.1/examples/ada/x00a.adb -o >> CMakeFiles/x00a.dir/x00a.o >> x00a.adb:28:05: file "plplot_auxiliary.ads" not found >> x00a.adb:29:05: file "plplot_traditional.ads" not found >> examples/ada/CMakeFiles/x00a.dir/build.make:65: recipe for target >> 'examples/ada/CMakeFiles/x00a.dir/x00a.o' failed >> >> So we're now missing the -I include dir options. >> >> That's all I have for now, I'll try to take a closer look later. >> > > There also appears to be a similar issue with building Paraview where the > MPI_INLCUDE_PATH is no longer being passed to the compile line. > FYI - builds still fail with cmake 3.4.0-rc2. Have had time to look at it closer. plplot issue seems to be triggered by a change in Ada_FLAGS: -Ada_FLAGS = -I/home/orion/fedora/plplot/plplot-5.11.1/build-3.3.2/examples/ada -I/home/orion/fedora/plplot/plplot-5.11.1/bindings/ada +Ada_FLAGS = but plplot I believe has custom Ada cmake platform support. I am still concerned about possible regressions here. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready!
On 10/06/2015 09:42 AM, Robert Maynard wrote: > I am proud to announce the first CMake 3.4 release candidate. This appears to have broken plplot's ada build on Fedora. Previous good (cmake 3.3.2): [ 22%] Building Ada object examples/ada/CMakeFiles/x00a.dir/x00a.o cd /builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada && /usr/bin/gnatgcc -I/builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada -I/builddir/build/BUILD/plplot-5.11.1/bindings/ada-c /builddir/build/BUILD/plplot-5.11.1/examples/ada/x00a.adb -o CMakeFiles/x00a.dir/x00a.o New bad: [ 22%] Building Ada object examples/ada/CMakeFiles/x00a.dir/x00a.o cd /builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada && /usr/bin/gnatgcc -c /builddir/build/BUILD/plplot-5.11.1/examples/ada/x00a.adb -o CMakeFiles/x00a.dir/x00a.o x00a.adb:28:05: file "plplot_auxiliary.ads" not found x00a.adb:29:05: file "plplot_traditional.ads" not found examples/ada/CMakeFiles/x00a.dir/build.make:65: recipe for target 'examples/ada/CMakeFiles/x00a.dir/x00a.o' failed So we're now missing the -I include dir options. That's all I have for now, I'll try to take a closer look later. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Full-scale, agent-less Infrastructure Monitoring from a single dashboard Integrate with 40+ ManageEngine ITSM Solutions for complete visibility Physical-Virtual-Cloud Infrastructure monitoring from one console Real user monitoring with APM Insights and performance trend reports Learn More http://pubads.g.doubleclick.net/gampad/clk?id=247754911=/4140 ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Octave 4.0.0
On 07/11/2015 08:27 PM, Alan W. Irwin wrote: On 2015-07-11 17:52-0600 Orion Poplawski wrote: On 07/10/2015 12:04 PM, Orion Poplawski wrote: My fix for octave 4.0,0 support in swig is here: https://github.com/swig/swig/pull/460 plplot 5.11.0 is building fine in Rawhide with a patched swig 3.0.6, octave 4.0.0, and the patch to plplot for swig 3.0.6 doc issue. Hi Orion: Thanks for that encouraging news with regard to good builds of the octave binding of PLplot against Octave-4.0.0. But I have also been concerned about the run-time results as well which you can straightforwardly check there by simply running cmake cmake.out make test_diff_psc test_diff_psc.out in an initially empty build tree. Normally that test shows there are no differences between the octave-generated and C-generated results for all our examples for the Octave-3.x.y case. If running that test there shows the same thing for the Octave-4.0.0 case that is a very strong test of our octave bindings for that case. Regardless of whether you try such a run time check, your build success motivates me to expand the epa_build implementation to see how far I can get with an epa_build of Octave-4.0.0 and patched versions of swig-2 and swig-3. Assuming I can epa_build all of those, then that would allow me to do the above run-time check here for patched versions of both swig-2 and swig-3, and thus help build the case to get your swig patch (or two variants of that if your patch has to be modified for swig-2) into the next official releases of both swig-2 and swig-3. Alan I'm afraid that the plplot octave tests have been failing for quite a while in Fedora Rawhide, probably due to gcc 5 as reported back in March. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Octave 4.0.0
On 07/10/2015 12:04 PM, Orion Poplawski wrote: My fix for octave 4.0,0 support in swig is here: https://github.com/swig/swig/pull/460 I'll test builds of plplot once the swig build is complete. plplot 5.11.0 is building fine in Rawhide with a patched swig 3.0.6, octave 4.0.0, and the patch to plplot for swig 3.0.6 doc issue. http://koji.fedoraproject.org/koji/taskinfo?taskID=10334481 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Octave 4.0.0
On 07/08/2015 03:36 PM, Alan W. Irwin wrote: On 2015-07-08 15:46- Arjen Markus wrote: Well, I tried it with Octave allowed, but I get build errors - see the tarball. It does not seem to be complaining about 2 versus 4 arguments anymore, but something is definitely wrong. Could that be the SWIG version? (Note: I did not use the very latest checkout, but the commits I saw have nothing to do with Octave). To Arjen and Orion: @Arjen: Thanks for this comprehensive test report. The short response for working around the octave error you encountered is you should remove the Cygwin package octave-devel-4.0.0-1 and install instead octave-devel-3.8.2-1. (And you should also confirm you have libhdf5-devel-1.8.15-1 installed.) And then you should try the test again (probably it is best if you do that with the PLplot master tip version). I am pretty sure that will just work since the 2 versus 4 argument issue has now been fixed and we have plenty of good tests of octave-3 on other platforms. @Orion: I suggest you also use Octave-3 for now assuming that Fedora has Octave-3 packages. @Arjen: Here is my longer response to your report. It turns out you ran into virtually exactly the same octave problems that Orion reported here so you may want to reread his recent post about this and my response to it. The first part of Orion's post shows that the swig-3.0.6 octave component does not like leading blanks in documentation of the swig-generated bindings for some reason, but swig-3.0.5 is OK with that. I have fixed that issue as of the current master tip. Your use of ae0e9da misses that fix to our documentation of the swig-generated bindings, but missing that fix did not matter for your case since Cygwin currently supplies you with swig-3.0.5. However, once Orion locally fixed the leading blank issue in our documentation of swig-generated bindings (the issue that is now permanently fixed in master tip), he went on to describe additional issues with octave #includes supplied by swig that are not compatible with Octave-4.0.0, and it appears you ran into those exact same swig issues. In sum, it appears build issues like you encountered above will not allow us to even try Octave-4.0.0 until swig fixes their Octave-4.0.0 #include issues, and that swig fix propagates to swig versions we are using. So for now (commit id 2ad5aef) the build system issues a WARNING if it finds Octave-4. For that case it disables the octave bindings unless the user specifically opts in using the cmake experimental option -DTRY_OCTAVE4=ON. Once swig fixes their problem with Octave-4 #includes so that -DTRY_OCTAVE4=ON has even a chance of working, I assume we will have a lot of work ahead of us both in the octave bindings and octave examples to become compatible with Octave-4. So I expect -DTRY_OCTAVE4=ON will be experimental for quite some time after the required swig fix. Alan __ Alan W. Irwin My fix for octave 4.0,0 support in swig is here: https://github.com/swig/swig/pull/460 I'll test builds of plplot once the swig build is complete. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Fedora plplot patches
On 04/25/2015 11:05 AM, Alan W. Irwin wrote:
While we are at it, are there any other general issues like this one
(i.e., issues likely to affect all distros) addressed by the Fedora
downstream patches which we should be aware of upstream?
There are two other issues currently addressed downstream, which I'm
pretty sure I've raised here before. The ocaml one relatively recently,
not sure about the multiarch one.
Patch2: plplot-multiarch.patch
This allows for the core plplot package to be multiarch - exactly
the same content for 32-bit and 64-bit builds. Otherwise the
PKG_CONFIG_ENV and RPATH variables have /usr/lib or /usr/lib64 in them.
I know this patch isn't acceptable upstream as it is, but if you found
a way to address it, that would be great.
# Don't use -custom with ocamlc
Patch7: plplot-ocaml.patch
I've attached both.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
diff -up plplot-5.11.0/examples/c/Makefile.examples.in.multiarch plplot-5.11.0/examples/c/Makefile.examples.in
--- plplot-5.11.0/examples/c/Makefile.examples.in.multiarch 2015-02-06 13:39:40.538189158 -0700
+++ plplot-5.11.0/examples/c/Makefile.examples.in 2015-02-06 13:40:08.976036737 -0700
@@ -25,9 +25,6 @@ SHELL = @SH_EXECUTABLE@
CC = @CC@
EXEEXT = @EXEEXT@
-PKG_CONFIG_ENV = @PKG_CONFIG_ENV@
-RPATHCMD = @RPATHCMD@
-
@gcw_true@PLPLOTCANVAS_EXECUTABLES_list = \
@gcw_true@ plplotcanvas_demo$(EXEEXT) \
@gcw_true@ plplotcanvas_animation$(EXEEXT)
diff -up plplot-5.11.0/examples/c++/Makefile.examples.in.multiarch plplot-5.11.0/examples/c++/Makefile.examples.in
--- plplot-5.11.0/examples/c++/Makefile.examples.in.multiarch 2015-02-06 13:39:40.537189163 -0700
+++ plplot-5.11.0/examples/c++/Makefile.examples.in 2015-02-06 13:41:04.003741815 -0700
@@ -25,10 +25,7 @@ SHELL = @SH_EXECUTABLE@
CXX = @CXX@
EXEEXT = @EXEEXT@
-PKG_CONFIG_ENV = @PKG_CONFIG_ENV@
-RPATHCMD = @RPATHCMD@
@qt_gui_true@QT_MOC_EXECUTABLE = @QT_MOC_EXECUTABLE@
-@qt_gui_true@qt_RPATHCMD = @qt_RPATHCMD@
@wxwidgets_true@PLPLOTWXWIDGETS_EXECUTABLES_list = \
@wxwidgets_true@ wxPLplotDemo$(EXEEXT)
diff -up plplot-5.11.0/examples/f95/Makefile.examples.in.multiarch plplot-5.11.0/examples/f95/Makefile.examples.in
--- plplot-5.11.0/examples/f95/Makefile.examples.in.multiarch 2015-02-06 13:39:40.538189158 -0700
+++ plplot-5.11.0/examples/f95/Makefile.examples.in 2015-02-06 13:40:22.148966137 -0700
@@ -25,9 +25,6 @@ SHELL = @SH_EXECUTABLE@
F95 = @FC@
EXEEXT = @EXEEXT@
-PKG_CONFIG_ENV = @PKG_CONFIG_ENV@
-RPATHCMD = @RPATHCMD@
-
EXECUTABLES_list = \
x00f$(EXEEXT) \
x01f$(EXEEXT) \
diff -up plplot-5.11.0/examples/tk/Makefile.examples.in.multiarch plplot-5.11.0/examples/tk/Makefile.examples.in
--- plplot-5.11.0/examples/tk/Makefile.examples.in.multiarch 2015-02-06 13:39:40.538189158 -0700
+++ plplot-5.11.0/examples/tk/Makefile.examples.in 2015-02-06 13:40:43.527851552 -0700
@@ -24,9 +24,6 @@ SHELL = @SH_EXECUTABLE@
CC = @CC@
EXEEXT = @EXEEXT@
-PKG_CONFIG_ENV = @PKG_CONFIG_ENV@
-plplottcltk_Main_RPATHCMD = @plplottcltk_Main_RPATHCMD@
-
EXECUTABLES_list = xtk01$(EXEEXT)
# Second and fourth examples depend on itk.
@itk_true@itk_EXECUTABLES_list = xtk02$(EXEEXT) xtk04$(EXEEXT)
diff -up plplot-5.11.0/bindings/ocaml/CMakeLists.txt.ocaml plplot-5.11.0/bindings/ocaml/CMakeLists.txt
--- plplot-5.11.0/bindings/ocaml/CMakeLists.txt.ocaml 2015-02-06 13:43:35.261931129 -0700
+++ plplot-5.11.0/bindings/ocaml/CMakeLists.txt 2015-02-06 13:44:58.758486273 -0700
@@ -154,11 +154,11 @@ if(ENABLE_ocaml)
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/plplot.cmo
)
- # ocamlc -a -custom builds a *.cma library from *.cmo
+ # ocamlc -a builds a *.cma library from *.cmo
add_custom_command(
OUTPUT
${CMAKE_CURRENT_BINARY_DIR}/plplot.cma
-COMMAND ${OCAMLC} -a -custom -o ${CMAKE_CURRENT_BINARY_DIR}/plplot.cma ${CMAKE_CURRENT_BINARY_DIR}/plplot_core.cmo ${CMAKE_CURRENT_BINARY_DIR}/plplot.cmo -dllib -lplplot_stubs -ccopt -L${CMAKE_CURRENT_BINARY_DIR} -cclib -lplplot_stubs -ccopt -L${CAMLIDL_LIB_DIR} -cclib -lcamlidl -ccopt -L${CMAKE_BINARY_DIR}/src -cclib -lplplot -dllpath ${CMAKE_BINARY_DIR}/src ${ocaml_STATIC_FLAGS}
+COMMAND ${OCAMLC} -a -o ${CMAKE_CURRENT_BINARY_DIR}/plplot.cma ${CMAKE_CURRENT_BINARY_DIR}/plplot_core.cmo ${CMAKE_CURRENT_BINARY_DIR}/plplot.cmo -dllib -lplplot_stubs -ccopt -L${CMAKE_CURRENT_BINARY_DIR} -cclib -lplplot_stubs -ccopt -L${CAMLIDL_LIB_DIR} -cclib -lcamlidl -ccopt -L${CMAKE_BINARY_DIR}/src -cclib -lplplot -dllpath ${CMAKE_BINARY_DIR}/src ${ocaml_STATIC_FLAGS}
DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/plplot_core.cmo
${CMAKE_CURRENT_BINARY_DIR}/plplot.cmo
diff -up plplot-5.11.0/bindings/ocaml/plcairo/CMakeLists.txt.ocaml plplot-5.11.0/bindings/ocaml/plcairo/CMakeLists.txt
--- plplot-5.11.0/bindings
Re: [Plplot-devel] fortran example compile error
On 04/24/2015 08:08 PM, Alan W. Irwin wrote: On 2015-04-24 16:51-0600 Orion Poplawski wrote: # make /usr/bin/gfortran x00f.f90 -o x00f -I/usr/include/plplot -I/usr/lib64/gfortran/modules -I/usr/include/plplot -lplplotf95 -lplf95demolib /usr/bin/ld: /tmp/ccNUjhko.o: undefined reference to symbol 'plinit_' /usr/lib64/libplplotf95c.so.12: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status # grep -Fi plinit x00f.f90 call plinit /usr/lib64/libplplotf95c.so 9350 T plinit_ So we need to link with -lplplotf95c Please clarify which of three build systems (build tree configured with cmake, installed examples tree configured with cmake, or traditional installed examples tree configured with pkg-config) generate the above error on Fedora. Installed examples tree using the installed Makefile. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- 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
[Plplot-devel] c++ wxWidget example compile issue
[-Wdeprecated-declarations] } ^ In file included from /usr/include/wx-2.8/wx/wx.h:36:0, from wxPLplotDemo.cpp:29: /usr/include/wx-2.8/wx/window.h:1453:13: note: declared here inline void wxWindowBase::SetInitialBestSize(const wxSize size) ^ /usr/bin/ld: /tmp/ccH0vhU9.o: undefined reference to symbol '_ZN8plstream4lineEiPKdS1_' /usr/lib64/libplplotcxx.so.12: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Makefile:81: recipe for target 'wxPLplotDemo' failed So it looks like something in either the wxPLplotDemo.cpp file or its includes references the '_ZN8plstream4lineEiPKdS1_' symbol and so needs to be linked with -lplplotcxx. If it is wxPLplotDemo.cpp, then it should be added to the Makefile like my other example. If it the includes and so all plplot-wxwidgets users need it, it should be added to the pkg-config output: # pkg-config --cflags --libs plplot-wxwidgets -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -I/usr/include/plplot -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -I/usr/include/plplot -lplplotwxwidgets -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- 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
[Plplot-devel] PDL-Graphics-PLplot and plplot 5.11.0
I'm trying to build PDL-Graphics-PLplot 0.67 with plplot 5.11.0. First I need
the attached patch to handle the name change.
Next issue I'm running into is the plplot.t test segfaulting:
$ LD_LIBRARY_PATH=../blib/arch/auto/PDL/Graphics/PLplot/ gdb perl
GNU gdb (GDB) Fedora 7.9-11.fc23
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-redhat-linux-gnu.
Type show configuration for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type help.
Type apropos word to search for commands related to word...
Reading symbols from perl...Reading symbols from
/home/orion/fedora/perl-PDL-Graphics-PLplot/PDL-Graphics-PLplot-0.67/t/perl...(no
debugging symbols found)...done.
(no debugging symbols found)...done.
Missing separate debuginfos, use: dnf debuginfo-install
perl-5.20.2-328.fc23.x86_64
(gdb) run -I../blib/lib ./plplot.t
Starting program: /usr/bin/perl -I../blib/lib ./plplot.t
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib64/libthread_db.so.1.
Detaching after fork from child process 26859.
Program received signal SIGSEGV, Segmentation fault.
0x72fd66fa in plP_state (op=op@entry=7)
at /usr/src/debug/plplot-5.11.0/src/plcore.c:260
260 ( *plsc-dispatch_table-pl_state )( (struct PLStream_struct
*) plsc, op );
(gdb) bt
#0 0x72fd66fa in plP_state (op=op@entry=7)
at /usr/src/debug/plplot-5.11.0/src/plcore.c:260
#1 0x72ff4e84 in c_plschr (def=optimized out, scale=optimized out)
at /usr/src/debug/plplot-5.11.0/src/plsdef.c:209
#2 0x732e1ab2 in pdl_plschr_readdata (__tr=0x15924e0) at
PLplot.xs:11154
#3 0x755a6194 in pdl.ensure_trans ()
from /usr/lib64/perl5/vendor_perl/auto/PDL/Core/Core.so
#4 0x755a5150 in pdl_make_trans_mutual ()
from /usr/lib64/perl5/vendor_perl/auto/PDL/Core/Core.so
#5 0x732ababf in XS_PDL_plschr (my_perl=optimized out,
cv=optimized out)
at PLplot.xs:50441
#6 0x77aea6ab in Perl_pp_entersub () from /lib64/libperl.so.5.20
#7 0x77ae2f36 in Perl_runops_standard () from /lib64/libperl.so.5.20
#8 0x77a729c0 in perl_run () from /lib64/libperl.so.5.20
#9 0x00400d79 in main ()
(gdb) list
255 plbuf_state( plsc, op );
256
257 save_locale = plsave_set_locale();
258 if ( !plsc-stream_closed )
259 {
260 ( *plsc-dispatch_table-pl_state )( (struct PLStream_struct
*) plsc, op );
261 }
262 plrestore_locale( save_locale );
263 }
264
(gdb) print plsc
$1 = (PLStream *) 0x7321eaa0 pls0
(gdb) print op
$2 = 7
(gdb) print plsc-dispatch_table
$3 = (PLDispatchTable *) 0x0
(gdb) print *plsc
$2 = {ipls = 0, level = 0, verbose = 0, debug = 0, initialized = 0,
dev_initialized = 0,
program = 0x0, coordinate_transform = 0x0, coordinate_transform_data = 0x0,
icol0 = 0,
ncol0 = 16, icol1 = 0, ncol1 = 0, ncp1 = 0, curcmap = 0, cmap1_min = 0,
cmap1_max = 0,
curcolor = {r = 0 '\000', g = 0 '\000', b = 0 '\000', a = 0, name = 0x0},
tmpcolor = {
r = 0 '\000', g = 0 '\000', b = 0 '\000', a = 0, name = 0x0}, cmap0 =
0x155e310,
cmap1 = 0x0, cmap1cp = {{h = 0, l = 0, s = 0, p = 0, a = 0,
alt_hue_path = 0} repeats 256 times}, width = 0, widthset = 0,
widthlock = 0,
arrow_x = 0x0, arrow_y = 0x0, arrow_npts = 0, arrow_fill = 0, dispatch_table
= 0x0,
plbuf_read = 0, plbuf_write = 0, device = 0, dev_minor = 0, termin = 0,
graphx = 0,
nopause = 0, color = 0, colorset = 0, family = 0, member = 0, finc = 0,
fflen = 0,
bytemax = 0, famadv = 0, dev_fill0 = 0, dev_fill1 = 0, dev_dash = 0, dev_di =
0,
dev_flush = 0, dev_swin = 0, dev_text = 0, dev_xor = 0, dev_clear = 0,
dev_fastimg = 0,
dev_arc = 0, DevName = xfig, '\000' repeats 75 times, OutFile = 0x0,
BaseName = 0x151a800 test2.xfig, FileName = 0x155e2d0 test2.xfig,
output_type = 0,
bytecnt = 0, page = 0, linepos = 0, pdfs = 0x0, dev_npts = 0, dev_x = 0x0,
dev_y = 0x0,
dev_nptsX = 0, dev_nptsY = 0, dev_ix = 0x0, dev_iy = 0x0, dev_z = 0x0,
dev_zmin = 0,
dev_zmax = 0, imclxmin = 0, imclxmax = 0, imclymin = 0, imclymax = 0, dev =
0x0,
dev_data = 0x0, KeyEH = 0x0, KeyEH_data = 0x0, ButtonEH = 0x0, ButtonEH_data
= 0x0,
LocateEH = 0x0, LocateEH_data = 0x0, bop_handler = 0x0, bop_data = 0x0,
eop_handler = 0x0,
eop_data = 0x0, xdpi = 0, ydpi = 0, xlength = 0, ylength = 0, xoffset = 0,
yoffset = 0,
pageset = 0, hack = 0, tidy = 0x0, tidy_data = 0x0, errcode = 0x0, errmsg =
0x0,
geometry = 0x0, window_id = 0, nopixmap = 0, db = 0, ext_resize_draw = 0,
server_name = 0x0
Re: [Plplot-devel] Strange issues with octave+swig+UTF8 in Fedora rawhide
On 03/19/2015 09:53 AM, Jim Dishaw wrote:
Would you run the example in the debugger and set a breakpoint in plP_text
and send me a hexdump of the contents of *string? A backtrace would also be
handy.
We're choking on the cyrillic text in x33c.
Here's an example:
Breakpoint 1, plP_text (base=base@entry=0, just=just@entry=0.5,
xform=xform@entry=0x7fff9440, x=x@entry=297, y=y@entry=1349,
refx=refx@entry=297,
refy=1198, string=0x55f94d40 @b\375UUU)
at /scratch/orion/redhat/plplot-5.10.0/plplot-5.10.0-git/src/plcore.c:1142
1142{
1: string = 0x55f94d40 @b\375UUU
If I walk up to the swig wrapper function, the string is already messed up.
(gdb) up 5
#5 0x7fffe2e82862 in _wrap_plcolorbar (args=..., nargout=optimized out)
at
/scratch/orion/redhat/plplot-5.10.0/plplot-5.10.0-git/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:14814
14814
my_plcolorbar(arg1,arg2,arg3,arg4,arg5,arg6,arg7,arg8,arg9,arg10,arg11,arg12,arg13,arg14,arg15,arg16,(int
const *)arg17,(char const **)arg18,arg19,(char const **)arg20,(double const
*)arg21,(int const *)arg22,(int const *)arg23,(double const *)arg24);
(gdb) print *arg18
$14 = 0x55f94d40 @b\375UUU
I can't debug the octave data structures though, just too much c++.
(gdb) bt
#0 plP_text (base=base@entry=0, just=just@entry=0.5,
xform=xform@entry=0x7fff9440,
x=x@entry=297, y=y@entry=1349, refx=refx@entry=297, refy=1198,
string=0x55f94d40 @b\375UUU)
at /scratch/orion/redhat/plplot-5.10.0/plplot-5.10.0-git/src/plcore.c:1142
#1 0x7fffe2bc44b2 in c_plmtex (side=side@entry=0x7fff94c0 l,
disp=disp@entry=1.2,
pos=optimized out, just=0.5, text=text@entry=0x55f94d40 @b\375UUU)
at /scratch/orion/redhat/plplot-5.10.0/plplot-5.10.0-git/src/plsym.c:700
#2 0x7fffe2bcf655 in draw_label (if_bb=if_bb@entry=0, opt=optimized out,
label=0x55f94d40 @b\375UUU)
at /scratch/orion/redhat/plplot-5.10.0/plplot-5.10.0-git/src/pllegend.c:1330
#3 0x7fffe2bd1df7 in c_plcolorbar (p_colorbar_width=0x7fff9af8,
p_colorbar_height=0x7fff9b00, opt=optimized out, position=optimized
out,
x=optimized out, y=optimized out, x_length=optimized out,
y_length=optimized out,
bg_color=15, bb_color=1, bb_style=1, low_cap_color=0, high_cap_color=1,
cont_color=0,
cont_width=0, n_labels=1, label_opts=0x55f94a90,
labels=0x55f94d60, n_axes=1,
axis_opts=0x55f94d20, ticks=0x55f94bd0, sub_ticks=0x55f95020,
n_values=0x55f95490, values=0x7fff98c0)
at /scratch/orion/redhat/plplot-5.10.0/plplot-5.10.0-git/src/pllegend.c:2366
#4 0x7fffe2e22a8d in my_plcolorbar (
p_colorbar_width=p_colorbar_width@entry=0x7fff9af8,
p_colorbar_height=p_colorbar_height@entry=0x7fff9b00,
opt=opt@entry=98833,
position=position@entry=1, x=x@entry=0, y=y@entry=0,
x_length=x_length@entry=0.050003, y_length=y_length@entry=0.5,
bg_color=bg_color@entry=15, bb_color=bb_color@entry=1, bb_style=1,
low_cap_color=low_cap_color@entry=0,
high_cap_color=high_cap_color@entry=1, cont_color=0,
cont_width=cont_width@entry=0, n_labels=1, label_opts=0x55f94a90,
label=0x55f94d60, n_axes=1, axis_opts=0x55f94d20,
ticks=0x55f94bd0,
sub_ticks=0x55f95020, n_values=0x55f95490, a=0x55f956d0)
at
/scratch/orion/redhat/plplot-5.10.0/plplot-5.10.0-git/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:3008
#5 0x7fffe2e82862 in _wrap_plcolorbar (args=..., nargout=optimized out)
at
/scratch/orion/redhat/plplot-5.10.0/plplot-5.10.0-git/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:14814
#6 0x7717209c in octave_builtin::do_multi_index_op
(this=0x55f475f0, nargout=2,
args=..., lvalue_list=optimized out) at octave-value/ov-builtin.cc:132
#7 0x77170908 in octave_builtin::subsref (this=0x55f475f0,
type=..., idx=...,
nargout=2, lvalue_list=0x7fffa820) at octave-value/ov-builtin.cc:64
#8 0x7725c34a in octave_value::subsref
(this=this@entry=0x7fffa4b0, type=...,
idx=..., nargout=nargout@entry=2,
lvalue_list=lvalue_list@entry=0x7fffa820)
at octave-value/ov.cc:1278
#9 0x772ef7a8 in tree_index_expression::rvalue (this=0x55f20150,
nargout=2,
lvalue_list=0x7fffa820) at parse-tree/pt-idx.cc:415
#10 0x772c0995 in tree_multi_assignment::rvalue (this=0x55f20920)
at parse-tree/pt-assign.cc:232
#11 0x772bee0d in tree_multi_assignment::rvalue1 (this=0x55f20920,
nargout=0)
at parse-tree/pt-assign.cc:198
#12 0x772d764c in tree_evaluator::visit_statement (
this=0x77dd1880 std_evaluator, stmt=...) at parse-tree/pt-eval.cc:747
#13 0x772d6cf1 in tree_evaluator::visit_statement_list (
this=0x77dd1880 std_evaluator, lst=...) at parse-tree/pt-eval.cc:797
#14 0x772d8f9a in tree_evaluator::visit_simple_for_command (
this=0x77dd1880 std_evaluator, cmd=...) at parse-tree/pt-eval.cc
Re: [Plplot-devel] Strange issues with octave+swig+UTF8 in Fedora rawhide
On 03/18/2015 10:48 PM, Jim Dishaw wrote: On Mar 18, 2015, at 11:18 PM, Orion Poplawski or...@cora.nwra.com wrote: The check in the plplot package for the octave bindings is failing in Fedora rawhide. I point my finger at gcc 5.0.0 :), but I have no idea what is going on so just putting this out there. plplot uses a swig generated interface for the octave wrapper. By the time the swig wrapper is calling the plplot C function I'm seeing UTF8 string pointers pointing to garbage (or perhaps just off by a byte, who knows). I've rebuilt swig, then octave, but no avail. So, I have no idea what is going on. test ouput is like: 5: x33c 5: 5: *** PLPLOT WARNING *** 5: Driver does not support native gradients, switching to software fallback gradient. 5: 5: 5: *** PLPLOT ERROR, ABORTING OPERATION *** 5: UTF-8 string is malformed: �*���*, aborting operation 5: 5: *** PLPLOT ERROR, ABORTING OPERATION *** 5: UTF-8 string is malformed: ��c��*, aborting operation 5: Output file name is /builddir/build/BUILD/plplot-5.10.0-git/fedora/ctest_examples_output_dir/x31o.p 5: 5: *** PLPLOT ERROR, ABORTING OPERATION *** 5: UTF-8 string is malformed: И|��*, aborting operation …. I was not able to replicate this error. I tried make test, make test_octave_psc, and make test_octave_xwin and did not get the above error. What character encoding is your version octave setup for? What is the value of HAVE_LIBUNICODE? Based on the error, I'm guessing HAVE_LIBUNICODE is not defined and perhaps a non utf-8 encoded string is passed. I'm pretty sure that this is triggered by changes in Fedora rawhide (gcc 5, ?) as I get the same error building plplot 5.10.0. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Why ocamlc -custom
On 10/24/2013 02:11 PM, Alan W. Irwin wrote: On 2013-10-24 09:56-0600 Orion Poplawski wrote: Why does plplot use ocamlc -custom to compile? I'm not sure it is necessary. If I remove it it appears to compile and tests run fine for me. I ask because of this: https://fedoraproject.org/wiki/Packaging:OCaml?rd=Packaging/OCaml#Stripping_binaries [...]Rationale: http://bugs.debian.org/256900 @Orion: This is a decision that Hez should ultimately make, although I would be happy to help with the implementation with some guidance from him. @Hez: Could you take a look at the interesting message thread given by that last URL, especially the posts by upstream OCaml developers? In sum, it appears to me those developers plan to maintain ocamlc -custom indefinitely because they take backwards incompatibility pretty seriously, but at the same time they want to discourage use of that option because of much better build alternatives for what that option was trying to accomplish. My feeling is we should probably implement that better build alternative if we haven't done that already, and then drop the -custom option, but I don't understand the details (i.e., whether or not we already have implemented the better build alternative) so I will need guidance from you if you want me to make some changes in the OCaml subset of our build system. Alan FWIW - I'm still stripping out -custom for the Fedora builds. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] lua test errors
On 08/07/2013 04:54 PM, Orion Poplawski wrote: I'm trying to rebuild the Fedora plplot package for Fedora 20 and am getting the following error: Start 10: examples_lua 10: Test command: /usr/bin/bash -c EXAMPLES_DIR=/builddir/build/BUILD/plplot-5.9.9/fedora/examples SRC_EXAMPLES_DIR=/builddir/build/BUILD/plplot-5.9.9/examples ./plplot-test.sh --verbose --device=psc --front-end=lua 10: Test timeout computed to be: 1500 10: Testing front-end lua 10: x00 10: x01 10: x02 10: x03 10: x04 10: /usr/bin/lua: x04.lua:59: attempt to call field 'log10' (a nil value) 10: stack traceback: 10: x04.lua:59: in function 'plot1' 10: x04.lua:182: in main chunk 10: [C]: in ? 10/16 Test #10: examples_lua .***Failed0.06 sec This is with svn 12281 which is what is currently in Fedora. Current svn fails with the Ada issue mentioned earlier. Looks like math.log10 was removed in lua 5.2 (we have lua 5.2.2 in F20), to be replaced with math.log(x,10). I suppose we are going to need grow some conditionals here. No idea how to handle that in lua. Also still carrying this in Fedora. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Error with cmake 3.1.1
On 02/06/2015 04:34 PM, Phil Rosenberg wrote: Hi Orion AGG is going to be dropped for the next release anyway. I am currently finishing of some changes to the wxWidgets driver that simplify the code base considerably, including ditching agg and wxGraphicsContext backend in favour of a single wxDC backend that can use a wxGCDC to get the same functionality. I kind of figured that would be the case, but I was confused by the new and improved warning messages. I'll leave it off then. Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Error with cmake 3.1.1
On 02/06/2015 11:53 AM, Alan W. Irwin wrote: On 2015-02-06 08:39-0700 Orion Poplawski wrote: And now that I actually check, I see that this is fixed in git. Hi Orion: Glad you found the solution in git master. My apologies as release manager that this fix and other improvements have stayed so long in git master without being released. That issue is going to be rectified on February 28th when git master will be released as PLplot-5.11.0. So if you (or others here) find any issues with git master, please let me know ASAP. Great, thanks. It would be helpful for my testing if git master started calling itself 5.11.0. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Fedora release schedule
FYI - https://fedoraproject.org/wiki/Releases/22/Schedule I think we're going to just miss it. I think we'd want to build it by 2/20. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Error with cmake 3.1.1
Trying to rebuild plplot for Fedora with cmake 3.1.1: CMake Error at cmake/modules/pkg-config.cmake:97 (_pkg_check_modules_internal): _pkg_check_modules_internal Macro invoked with incorrect arguments for macro named: _pkg_check_modules_internal Call Stack (most recent call first): cmake/modules/pango.cmake:23 (pkg_check_pkgconfig) cmake/modules/plplot.cmake:535 (include) CMakeLists.txt:111 (include) -- WARNING: pkg-config does not find pango. Any ideas? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Error with cmake 3.1.1
On 02/06/2015 08:37 AM, Orion Poplawski wrote: On 02/06/2015 08:30 AM, Orion Poplawski wrote: Trying to rebuild plplot for Fedora with cmake 3.1.1: CMake Error at cmake/modules/pkg-config.cmake:97 (_pkg_check_modules_internal): _pkg_check_modules_internal Macro invoked with incorrect arguments for macro named: _pkg_check_modules_internal Call Stack (most recent call first): cmake/modules/pango.cmake:23 (pkg_check_pkgconfig) cmake/modules/plplot.cmake:535 (include) CMakeLists.txt:111 (include) -- WARNING: pkg-config does not find pango. Any ideas? So it does appear (not terribly surprising for something named _pkg_check_modules_internal) the interface changed: 3.0.2: macro(_pkg_check_modules_internal _is_required _is_silent _prefix) cmake-3.1.1/Modules/FindPkgConfig.cmake: macro(_pkg_check_modules_internal _is_required _is_silent _no_cmake_path _no_cmake_environment_path _prefix) Is there some reason that plplot is using its own pkg-config implementation? Is it still necessary? This is with plplot 5.10.0 And now that I actually check, I see that this is fixed in git. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Error with cmake 3.1.1
On 02/06/2015 08:30 AM, Orion Poplawski wrote: Trying to rebuild plplot for Fedora with cmake 3.1.1: CMake Error at cmake/modules/pkg-config.cmake:97 (_pkg_check_modules_internal): _pkg_check_modules_internal Macro invoked with incorrect arguments for macro named: _pkg_check_modules_internal Call Stack (most recent call first): cmake/modules/pango.cmake:23 (pkg_check_pkgconfig) cmake/modules/plplot.cmake:535 (include) CMakeLists.txt:111 (include) -- WARNING: pkg-config does not find pango. Any ideas? So it does appear (not terribly surprising for something named _pkg_check_modules_internal) the interface changed: 3.0.2: macro(_pkg_check_modules_internal _is_required _is_silent _prefix) cmake-3.1.1/Modules/FindPkgConfig.cmake: macro(_pkg_check_modules_internal _is_required _is_silent _no_cmake_path _no_cmake_environment_path _prefix) Is there some reason that plplot is using its own pkg-config implementation? Is it still necessary? This is with plplot 5.10.0 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Find libgnat-5.so
Apparently for gnat version 5.0, the library is named libgnat-5.so. The
attached patch fixes.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
From 920dd4b910b6afda0b44df1e6f54437cee38c0b9 Mon Sep 17 00:00:00 2001
From: Orion Poplawski or...@cora.nwra.com
Date: Fri, 6 Feb 2015 11:42:57 -0700
Subject: [PATCH] Find libgnat-5
---
cmake/modules/ada.cmake | 7 ---
cmake/test_ada/ada.cmake | 7 ---
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/cmake/modules/ada.cmake b/cmake/modules/ada.cmake
index f80f172..88216e9 100644
--- a/cmake/modules/ada.cmake
+++ b/cmake/modules/ada.cmake
@@ -45,10 +45,11 @@ endif(ENABLE_ada)
if(ENABLE_ada)
# Find the gnat version used in order to search for the right version of libgnat
execute_process(COMMAND ${CMAKE_Ada_COMPILER} --version OUTPUT_VARIABLE ADA_OUTPUT)
- string(REGEX MATCH gcc.* [(][^)]*[)] ([0-9]*[.][0-9]*)[.][0-9] ADA_OUTPUT_TRIM ${ADA_OUTPUT})
- set(GNATVERSION ${CMAKE_MATCH_1})
+ string(REGEX MATCH gcc.* [(][^)]*[)] ([0-9]*)([.][0-9]*)[.][0-9] ADA_OUTPUT_TRIM ${ADA_OUTPUT})
+ set(GNATMAJVERSION ${CMAKE_MATCH_1})
+ set(GNATVERSION ${CMAKE_MATCH_1}${CMAKE_MATCH_2})
message(STATUS gnat version = ${GNATVERSION})
- find_library(GNAT_LIB NAMES gnat gnat-${GNATVERSION})
+ find_library(GNAT_LIB NAMES gnat gnat-${GNATVERSION} gnat-${GNATMAJVERSION})
if(NOT GNAT_LIB)
message(STATUS WARNING:
gnat library not found. Disabling ada bindings)
diff --git a/cmake/test_ada/ada.cmake b/cmake/test_ada/ada.cmake
index b5661cb..96dde9b 100644
--- a/cmake/test_ada/ada.cmake
+++ b/cmake/test_ada/ada.cmake
@@ -6,10 +6,11 @@ endif(NOT CMAKE_Ada_COMPILER_WORKS)
# Find the gnat version used in order to search for the right version of libgnat
execute_process(COMMAND ${CMAKE_Ada_COMPILER} --version OUTPUT_VARIABLE ADA_OUTPUT)
-string(REGEX MATCH gcc [(][^)]*[)] ([0-9]*[.][0-9]*)[.][0-9] ADA_OUTPUT_TRIM ${ADA_OUTPUT})
-set(GNATVERSION ${CMAKE_MATCH_1})
+string(REGEX MATCH gcc [(][^)]*[)] ([0-9]*)([.][0-9]*)[.][0-9] ADA_OUTPUT_TRIM ${ADA_OUTPUT})
+set(GNATMAJVERSION ${CMAKE_MATCH_1})
+set(GNATVERSION ${CMAKE_MATCH_1}${CMAKE_MATCH_2})
message(STATUS gnat version = ${GNATVERSION})
-find_library(GNAT_LIB NAMES gnat gnat-${GNATVERSION})
+find_library(GNAT_LIB NAMES gnat gnat-${GNATVERSION} gnat-${GNATMAJVERSION})
if(NOT GNAT_LIB)
message(FATAL_ERROR Required gnat library not found.)
endif(NOT GNAT_LIB)
--
2.1.0
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] libagg?
On 04/20/2014 11:13 PM, Alan W. Irwin wrote: Follow-up: From remarks made by Jim Barry at http://comments.gmane.org/gmane.comp.graphics.agg/5828 the AGG (Anti-Grain Geometry) project has moved its website to agg.sourceforge.net, but it is not clear yet what has been done with the historical releases such as http://www.antigrain.com/agg-2.5.tar.gz which is now a dead link. More later if/when Jim replies to my query about the tarball location(s). Alan FWIW - The Fedora AGG package is applying patches from the mapnik project, which is maintaining its own copy of agg: https://github.com/mapnik/mapnik/tree/master/deps/agg -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Problem with gfortran 4.9.0
Fedora rawhide has just updated to gcc 4.9.0. I'm now seeing the following error: 3: x20f 3: At line 386 of file /builddir/build/BUILD/plplot-5.10.0/examples/f95/x20f.f90 3: Fortran runtime error: End of file Not sure what we're trying to do here: ! Found the line with the sizes, copy this one and the next count = count + 1 read( 10, '(a)', iostat = ierr ) ver(2) read( ver, * ) w, h, num_col allocate( img_f(w,h) ) didn't know you could read from a variable? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Problem with gfortran 4.9.0
On 04/10/2014 11:04 AM, Orion Poplawski wrote: Fedora rawhide has just updated to gcc 4.9.0. I'm now seeing the following error: 3: x20f 3: At line 386 of file /builddir/build/BUILD/plplot-5.10.0/examples/f95/x20f.f90 3: Fortran runtime error: End of file Not sure what we're trying to do here: ! Found the line with the sizes, copy this one and the next count = count + 1 read( 10, '(a)', iostat = ierr ) ver(2) read( ver, * ) w, h, num_col allocate( img_f(w,h) ) didn't know you could read from a variable? Filed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60810 as this does look to be a regression. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Octave 3.8 support
On 02/28/2014 06:28 AM, Andrew Ross wrote: Following some testing on Debian sid, I've managed to get plplot svn working properly with octave 3.8. This requires swig 2.0.12 to work. I've also had to fix our examples and scripts due to some changes in octave 3.8. These changes are all backwards compatible with octave 3.6. I've added the octave changes to the Fedora rawhide package and rebuilt successfully with swig 2.0.12 as well. Thanks. - Orion -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Problem with Tk/wish and Fedora builds
On 02/14/2014 12:45 AM, Alan W. Irwin wrote: On 2014-02-13 18:11-0700 Orion Poplawski wrote: On 02/13/2014 03:22 PM, Orion Poplawski wrote: On 02/13/2014 02:53 PM, Orion Poplawski wrote: So, looks like 5.10.0 executes wish during cmake to determine version info. This fails on the Fedora builders because there is no DISPLAY. So, what to do? -- Looking for wish - found -- TK_WISH = /bin/wish Application initialization failed: no display name and no $DISPLAY environment variable Error in startup script: no display name and no $DISPLAY environment variable while executing load /usr/lib64/libtk8.5.so Tk (package ifneeded Tk 8.5.15 script) invoked from within package require Tk invoked from within puts -nonewline [package require Tk] (file /builddir/build/BUILD/plplot-5.10.0/fedora/CheckTK_VERSION.tcl line 1) -- Looking for Tk version with wish - not found -- WARNING: setting ENABLE_tk to OFF -- WARNING: Because Tk is disabled must disable Itk as well Workaround seems to be: -DPLPLOT_TK_VERSION=8.5.15 -DPLPLOT_ITCL_VERSION=3.4 -DPLPLOT_ITK_VERSION=3.4 though still working on iWidgets but I have to go now. iwidgets appears to need: -DIWIDGETS_VERSIONS_LIST:STRING=4.0.2;3.4;3.4 Yes. You are on the right track for hand-specifying all versions, and I assume that works for your rather specialized case where you are attempting to build PLplot on a computer with no valid display. If you do not specify the versions by hand, the cmake command follows the normal CMake find rules (as affected by the set of environment variables you give it) to find Tcl, Tk, Itcl, Itk, and Iwidgets, and it is necessary/desirable to do sanity checks for version consistency. Those sanity checks test whether wish and tclsh give the same package require version results for Tcl and also there is a similar package require check for a consistent Tk version. Of course, such simple package require command results should not need a display so I am wondering if there is a way to obtain such results under wish when there is no display? Could you check with Fedora experts if that is possible? If so, then you would not have to specify versions by hand like you do above. Alan So, as you confirmed later, that is indeed what I have to do. I've worked up some hacks to determine version in the Fedora spec file so hopefully I'm good to go. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Problem with Tk/wish and Fedora builds
So, looks like 5.10.0 executes wish during cmake to determine version info. This fails on the Fedora builders because there is no DISPLAY. So, what to do? -- Looking for wish - found -- TK_WISH = /bin/wish Application initialization failed: no display name and no $DISPLAY environment variable Error in startup script: no display name and no $DISPLAY environment variable while executing load /usr/lib64/libtk8.5.so Tk (package ifneeded Tk 8.5.15 script) invoked from within package require Tk invoked from within puts -nonewline [package require Tk] (file /builddir/build/BUILD/plplot-5.10.0/fedora/CheckTK_VERSION.tcl line 1) -- Looking for Tk version with wish - not found -- WARNING: setting ENABLE_tk to OFF -- WARNING: Because Tk is disabled must disable Itk as well -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Problem with Tk/wish and Fedora builds
On 02/13/2014 02:53 PM, Orion Poplawski wrote: So, looks like 5.10.0 executes wish during cmake to determine version info. This fails on the Fedora builders because there is no DISPLAY. So, what to do? -- Looking for wish - found -- TK_WISH = /bin/wish Application initialization failed: no display name and no $DISPLAY environment variable Error in startup script: no display name and no $DISPLAY environment variable while executing load /usr/lib64/libtk8.5.so Tk (package ifneeded Tk 8.5.15 script) invoked from within package require Tk invoked from within puts -nonewline [package require Tk] (file /builddir/build/BUILD/plplot-5.10.0/fedora/CheckTK_VERSION.tcl line 1) -- Looking for Tk version with wish - not found -- WARNING: setting ENABLE_tk to OFF -- WARNING: Because Tk is disabled must disable Itk as well Workaround seems to be: -DPLPLOT_TK_VERSION=8.5.15 -DPLPLOT_ITCL_VERSION=3.4 -DPLPLOT_ITK_VERSION=3.4 though still working on iWidgets but I have to go now. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Problem with Tk/wish and Fedora builds
On 02/13/2014 03:22 PM, Orion Poplawski wrote: On 02/13/2014 02:53 PM, Orion Poplawski wrote: So, looks like 5.10.0 executes wish during cmake to determine version info. This fails on the Fedora builders because there is no DISPLAY. So, what to do? -- Looking for wish - found -- TK_WISH = /bin/wish Application initialization failed: no display name and no $DISPLAY environment variable Error in startup script: no display name and no $DISPLAY environment variable while executing load /usr/lib64/libtk8.5.so Tk (package ifneeded Tk 8.5.15 script) invoked from within package require Tk invoked from within puts -nonewline [package require Tk] (file /builddir/build/BUILD/plplot-5.10.0/fedora/CheckTK_VERSION.tcl line 1) -- Looking for Tk version with wish - not found -- WARNING: setting ENABLE_tk to OFF -- WARNING: Because Tk is disabled must disable Itk as well Workaround seems to be: -DPLPLOT_TK_VERSION=8.5.15 -DPLPLOT_ITCL_VERSION=3.4 -DPLPLOT_ITK_VERSION=3.4 though still working on iWidgets but I have to go now. iwidgets appears to need: -DIWIDGETS_VERSIONS_LIST:STRING=4.0.2;3.4;3.4 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Qsatime suffix
On 01/23/2014 08:01 PM, Alan W. Irwin wrote: @Orion and Andrew: I am especially interested in your comments on the implications of effectively dropping the d suffix for most of our distributed library names. Obviously this is a soname change requires a rebuild of all library users. But this is fairly regular with plplot. Perhaps worth tying to some other ABI breakage to avoid multiple breaks just for the sake of changing the name. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Build problems with octave
On 01/03/2014 05:59 PM, Alan W. Irwin wrote:
On 2014-01-03 15:07-0700 Orion Poplawski wrote:
On 12/31/2013 06:50 PM, Alan W. Irwin wrote:
Hi Orion:
Thanks for doing that suggested experiment. More below
in context.
On 2013-12-31 16:52-0700 Orion Poplawski wrote:
On 12/31/2013 11:56 AM, Alan W. Irwin wrote:
On 2013-12-30 13:42-0700 Orion Poplawski wrote:
Ah, you hit the nail on the head - they dropped
OCTAVE_API_VERSION_NUMBER
completely. I've sent an email to the octave developers asking why.
To see if there are any more octave-3.8.0 issues beyond this one, I
suggest you temporarily add
#define OCTAVE_API_VERSION_NUMBER 49
to the generated bindings/octave/plplot_octaveOCTAVE_wrap.cxx
file and see how far you get with
cd /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave
/usr/lib64/ccache/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2
-g -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4
-grecord-gcc-switches -m64
-mtune=generic -fPIC -I/home/orion/fedora/plplot/plplot-5.9.11/include
-I/home/orion/fedora/plplot/plplot-5.9.11/lib/qsastime
-I/home/orion/fedora/plplot/plplot-5.9.11/fedora
-I/home/orion/fedora/plplot/plplot-5.9.11/fedora/include
-I/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave
-I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave
-I/home/orion/fedora/plplot/plplot-5.9.11/bindings/swig-support-o
CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
In member function ‘virtual dim_vector octave_swig_type::dims() const’:
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1183:46:
error: ‘class octave_value’ has no member named ‘is_real_nd_array’
} else if (out.is_matrix_type() || out.is_real_nd_array() ||
out.is_numeric_type() ) {
^
is_real_nd_array is only used in a function that is provided by swig
(as opposed to C++ interface code supplied by PLplot). So I would
summarize this issue as a backwards-incompatible Octave change (or
bug) that is confounding swig very similar to the missing
OCTAVE_API_VERSION_NUMBER #define.
Again, I think the Octave developers should be consulted about this to
see whether this is a bug or an intended backwards-incompatible change
in the Octave C++ library API.
According to the octave folks, is_real_nd_array() was intentionally
removed,
and may indeed have only ever returned false.
octave upstream seems adverse to re-adding OCTAVE_API_VERSION_NUMBER.
I have gotten no response yet to my swig bug:
https://sourceforge.net/p/swig/bugs/1353/
I found via google the octave threads at
http://octave.1599824.n4.nabble.com/Why-no-more-OCTAVE-API-VERSION-NUMBER-td4660468.html
and
http://octave.1599824.n4.nabble.com/Any-documentation-of-changes-to-libinterp-API-td4660492.html
where octave developers replied to your two reports, and I agree with
your conclusion that it looks like they will do nothing to rescind
those backwards incompatibilities.
[out of order]I may be able to put some hacks into the Fedora swig
package to work around
these problems, but I rather avoid it.
Any suggestions for how to proceed?
For the PLplot build system it should be straightforward to create an
Octave version test. Also, I am pretty sure that swig users are
allowed to redefine any core swig functionality. Thus, for any Octave
version greater than 3.6.4, we would want to #define
OCTAVE-API-VERSION-NUMBER and simply copy the the swig core
functionality that currently uses is_real_nd_array() and modify it to
drop that call. But I don't understand OOP well enough to figure out
the code unit that needs to be copied so I hope you or Andrew can
figure that out (or figure out some other simpler means of effectively
dropping that call to is_real_nd_array()).
Have you had any luck with the swig folks?
I haven't tried yet since I think your bug report will need to be
supplemented if we attempt to follow the above plan to modify PLplot
so it will work properly with Octave-3.8.0. Once 3.8.0 works for us,
you should update that bug report with a patch to swig that takes all
measures we discover need to be made in the PLplot case. At that point
I would be willing to bring up your bug report on the swig mailing
list. There is nothing like a patch (no matter how crude/brute force)
to focus and attract discussion.
Alan
I'm afraid I'm going to bow out of being a go between here. Hopefully
the SWIG and Octave folks can work it out. As it stands it seems like
SWIG may drop Octave support if there is no resolution.
For the time being I'm disabling plplot Octave support in Fedora Rawhide
(F21
Re: [Plplot-devel] Build problems with octave
On 12/31/2013 06:50 PM, Alan W. Irwin wrote:
Hi Orion:
Thanks for doing that suggested experiment. More below
in context.
On 2013-12-31 16:52-0700 Orion Poplawski wrote:
On 12/31/2013 11:56 AM, Alan W. Irwin wrote:
On 2013-12-30 13:42-0700 Orion Poplawski wrote:
Ah, you hit the nail on the head - they dropped OCTAVE_API_VERSION_NUMBER
completely. I've sent an email to the octave developers asking why.
To see if there are any more octave-3.8.0 issues beyond this one, I
suggest you temporarily add
#define OCTAVE_API_VERSION_NUMBER 49
to the generated bindings/octave/plplot_octaveOCTAVE_wrap.cxx
file and see how far you get with
cd /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave
/usr/lib64/ccache/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 -g -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m64
-mtune=generic -fPIC -I/home/orion/fedora/plplot/plplot-5.9.11/include
-I/home/orion/fedora/plplot/plplot-5.9.11/lib/qsastime
-I/home/orion/fedora/plplot/plplot-5.9.11/fedora
-I/home/orion/fedora/plplot/plplot-5.9.11/fedora/include
-I/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave
-I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave
-I/home/orion/fedora/plplot/plplot-5.9.11/bindings/swig-support-o
CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
In member function ‘virtual dim_vector octave_swig_type::dims() const’:
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1183:46:
error: ‘class octave_value’ has no member named ‘is_real_nd_array’
} else if (out.is_matrix_type() || out.is_real_nd_array() ||
out.is_numeric_type() ) {
^
is_real_nd_array is only used in a function that is provided by swig
(as opposed to C++ interface code supplied by PLplot). So I would
summarize this issue as a backwards-incompatible Octave change (or
bug) that is confounding swig very similar to the missing
OCTAVE_API_VERSION_NUMBER #define.
Again, I think the Octave developers should be consulted about this to
see whether this is a bug or an intended backwards-incompatible change
in the Octave C++ library API.
According to the octave folks, is_real_nd_array() was intentionally removed,
and may indeed have only ever returned false.
octave upstream seems adverse to re-adding OCTAVE_API_VERSION_NUMBER.
I have gotten no response yet to my swig bug:
https://sourceforge.net/p/swig/bugs/1353/
I may be able to put some hacks into the Fedora swig package to work around
these problems, but I rather avoid it.
Any suggestions for how to proceed? Have you had any luck with the swig folks?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
--
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=84349831iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Build problems with octave
On 12/31/2013 11:56 AM, Alan W. Irwin wrote:
On 2013-12-30 13:42-0700 Orion Poplawski wrote:
Ah, you hit the nail on the head - they dropped OCTAVE_API_VERSION_NUMBER
completely. I've sent an email to the octave developers asking why.
To see if there are any more octave-3.8.0 issues beyond this one, I
suggest you temporarily add
#define OCTAVE_API_VERSION_NUMBER 49
to the generated bindings/octave/plplot_octaveOCTAVE_wrap.cxx
file and see how far you get with
cd /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave
/usr/lib64/ccache/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 -g -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64
-mtune=generic -fPIC -I/home/orion/fedora/plplot/plplot-5.9.11/include
-I/home/orion/fedora/plplot/plplot-5.9.11/lib/qsastime
-I/home/orion/fedora/plplot/plplot-5.9.11/fedora
-I/home/orion/fedora/plplot/plplot-5.9.11/fedora/include
-I/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave
-I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave
-I/home/orion/fedora/plplot/plplot-5.9.11/bindings/swig-support-o
CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
In member function ‘virtual dim_vector octave_swig_type::dims() const’:
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1183:46:
error: ‘class octave_value’ has no member named ‘is_real_nd_array’
} else if (out.is_matrix_type() || out.is_real_nd_array() ||
out.is_numeric_type() ) {
^
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
In function ‘void SWIG_Octave_LinkGlobalValue(std::string)’:
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2052:28:
warning: ‘static octave_value symbol_table::varref(const string,
symbol_table::scope_id, symbol_table::context_id, bool)’ is deprecated
(declared at /usr/include/octave-3.8.0/octave/symtab.h:1322)
[-Wdeprecated-declarations]
symbol_table::varref(name);
^
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
In function ‘void labelfunc_octave(PLINT, PLFLT, char*, PLINT, PLPointer)’:
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2310:13:
warning: unused variable ‘i’ [-Wunused-variable]
int i;
^
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
In function ‘void ct_octave(PLFLT, PLFLT, PLFLT*, PLFLT*, PLPointer)’:
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2336:25:
warning: unused variable ‘i’ [-Wunused-variable]
octave_idx_type i;
^
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
In member function ‘virtual dim_vector octave_swig_type::dims() const’:
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1200:5:
warning: control reaches end of non-void function [-Wreturn-type]
}
^
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
At global scope:
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1859:28:
warning: ‘octave_value_list octave_set_immutable(const octave_value_list,
int)’ defined but not used [-Wunused-function]
static octave_value_list octave_set_immutable(const octave_value_list
args, int nargout) {
^
/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2158:5:
warning: ‘int _arraylen(const octave_value)’ defined but not used
[-Wunused-function]
_arraylen( const octave_value o_obj )
^
make[2]: ***
[bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o]
Error 1
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
--
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=84349831iu=/4140/ostg.clktrk
___
Plplot-devel
Re: [Plplot-devel] Build problems with octave
On 12/30/2013 01:08 PM, Alan W. Irwin wrote:
On 2013-12-29 20:39-0700 Orion Poplawski wrote:
On 12/29/2013 08:25 PM, Orion Poplawski wrote:
On 12/29/2013 01:34 PM, Alan W. Irwin wrote:
Please let me know if my latest PLplot change from config.h to
plplot_config.h (revision 12914) solves this issue. Of course, if it
doesn't solve it, the change was worth doing anyway. And if it does
solve it, I hope your bug report still convinces the Octave developers
to move back to using the quoted form of #include for config.h (or
better yet change the name to octave_config.h). After all, there are
likely quite a few software projects still left out there that do use
the config.h name (at least internally in their build tree as PLplot
did up to now).
Alan
Alan - That does indeed get us further - but now we seem to be into the
meat of the API changes in octave:
/usr/bin/cmake -E cmake_progress_report
/builddir/build/BUILD/plplot-5.9.11/fedora/CMakeFiles 19
[ 13%] Building CXX object
bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o
cd /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave
/usr/bin/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 -g -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -fPIC
-I/builddir/build/BUILD/plplot-5.9.11/include
-I/builddir/build/BUILD/plplot-5.9.11/lib/qsastime
-I/builddir/build/BUILD/plplot-5.9.11/fedora
-I/builddir/build/BUILD/plplot-5.9.11/fedora/include
-I/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave
-I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave
-I/builddir/build/BUILD/plplot-5.9.11/bindings/swig-support-o
CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c
/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx
/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1507:36:
warning: 'Octave_map' is deprecated (declared at
/usr/include/octave-3.8.0/octave/oct-map.h:484) [-Wdeprecated-declarations]
virtual Octave_map map_value() const {
^
/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1507:24:
error: invalid covariant return type for 'virtual Octave_map
octave_swig_type::map_value() const'
virtual Octave_map map_value() const {
^
So much/most of this may be a swig issue. I filed
https://sourceforge.net/p/swig/bugs/1353/ for it.
Looking further, I think this issue is very likely an Octave one. For
example, the above virtual command occurs in the following context
in my version of the generated
/bindings/octave/plplot_octaveOCTAVE_wrap.cxx
#if OCTAVE_API_VERSION_NUMBER = 40
virtual octave_map map_value() const {
return octave_map();
}
#else
virtual Octave_map map_value() const {
return Octave_map();
}
#endif
As you appear to be already aware, this is C++ code generated by swig and not
by any of our
typemaps in bindings/octave/plplot_octaveOCTAVE_wrap.cxx so your first
reaction that it is a swig issue is understandable. But note above
that the capitalized version which causes the issue above, i.e.,
virtual Octave_map map_value() const {
is meant to be used only for very old octave versions. For example,
I get the following result on my system:
irwin@raven find /usr/include/octave-* -type f |xargs grep \
OCTAVE_API_VERSION_NUMBER
/usr/include/octave-3.6.2/octave/version.h:#define OCTAVE_API_VERSION_NUMBER
48
Please try the same command on Fedora. I am pretty sure you will find
that the issue is that octave-3.8.0 has failed to define
OCTAVE_API_VERSION_NUMBER at all (or else used an incorrect low number)
which would be a serious octave-3.8.0 bug.
Alan
Ah, you hit the nail on the head - they dropped OCTAVE_API_VERSION_NUMBER
completely. I've sent an email to the octave developers asking why.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
--
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=84349831iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Build problems with octave
On 12/28/2013 10:49 PM, Alan W. Irwin wrote: On 2013-12-28 16:53-0700 Orion Poplawski wrote: On 06/27/2013 11:44 AM, RCY wrote: Hi, I am trying to build the development version of plplot with octave bindings. However I get numerous errors. Is the version incompatible with later versions of octave? Thanks [ 71%] Building CXX object bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o In file included from /usr/local/include/octave-3.7.5/octave/dim-vector.h:35:0, from /usr/local/include/octave-3.7.5/octave/Array.h:35, from /usr/local/include/octave-3.7.5/octave/boolMatrix.h:27, from /usr/local/include/octave-3.7.5/octave/mx-base.h:32, from /usr/local/include/octave-3.7.5/octave/Matrix.h:30, from /usr/local/include/octave-3.7.5/octave/oct.h:33, from /home/rc/Downloads/plplot/build/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: /usr/local/include/octave-3.7.5/octave/oct-refcount.h:27:3: error: #error The file octave/config.h must be included before oct-refcount.h. In file included from /usr/local/include/octave-3.7.5/octave/mx-base.h:28:0, from /usr/local/include/octave-3.7.5/octave/Matrix.h:30, from /usr/local/include/octave-3.7.5/octave/oct.h:33, from /home/rc/Downloads/plplot/build/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: /usr/local/include/octave-3.7.5/octave/MatrixType.h:36:1: error: variable ‘OCTAVE_API MatrixType’ has initializer but incomplete type /usr/local/include/octave-3.7.5/octave/MatrixType.h:36:1: warning: extended initializer lists only available with -std=c++11 or -std=gnu++11 [enabled by default] /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: expected primary-expression before ‘public’ /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: expected ‘}’ before ‘public’ /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: expected ‘,’ or ‘;’ before ‘public’ /usr/local/include/octave-3.7.5/octave/MatrixType.h:56:20: error: expected constructor, destructor, or type conversion before ‘;’ token /usr/local/include/octave-3.7.5/octave/MatrixType.h:58:21: error: ‘MatrixType’ does not name a type I'm seeing the same now with octave 3.8.0-rc2. Hi Orion and RCY: @RCY: if you want to write further comments to this list discussion (which I presume will be on-going) you are required but also most welcome to subscribe to this list. However, I am sure everyone will be happy to CC you (like I have) if you decide not to subscribe and simply want to read the further discussion without writing comments of your own. @Orion: Thanks for that report for an octave 3.8.0 release candidate. I notice the final version of octave 3.8.0 was released just today. (see ftp://ftp.gnu.org/gnu/octave). Once that version becomes available on Fedora could you confirm you are still seeing the same issue? I was intrigued by the #error The file octave/config.h must be included before oct-refcount.h. message. From our swig-generated code, bindings/octave/plplot_octaveOCTAVE_wrap.cxx, this message is coming from #include octave/oct.h which is _the first_ octave-related include in that source code. So I don't think this error has anything to do with us unless there is a new Octave 3.8.0 requirement (which I think would be unlikely) to include a different octave header before octave/oct.h. For your further information, Andrew's and my extensive tests of our octave bindings and examples for PLplot-5.9.11 were fine. Andrew tested that PLplot release on both Debian unstable and Ubuntu Saucy (both of which have Octave-3.6.4) and I tested on Debian stable (Octave version 3.6.2). Thus, it appears to me that since the above first octave include worked fine for those versions of octave yet errors out for octave-3.8.0, that it is highly probable all the above messages are due to an internal error in octave-3.8.0 itself which might or might not be sorted out by 3.8.0 final. If it is not sorted out by 3.8.0 final, then you might want to try a simple test of compiling code consisting of the single #include statement above. Assuming that errors out the same way, then that simple test could be used as the core of a report to the Octave developers to see what they say about the issue. Alan Still failing with 3.8.0 final: http://koji.fedoraproject.org/koji/getfile?taskID=6340306name=build.log $ g++ -c -fPIC -I/usr/include/octave-3.8.0/octave/.. -I/usr/include/octave-3.8.0/octave -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -pthread test.cc $ cat test.cc #include octave/oct.h $ cat /usr/include/octave-3.8.0/octave/oct.h /* Copyright (C) 1996-2013 John W. Eaton
Re: [Plplot-devel] Build problems with octave
On 12/29/2013 11:00 AM, Alan W. Irwin wrote: On 2013-12-29 08:41-0700 Orion Poplawski wrote: On 12/28/2013 10:49 PM, Alan W. Irwin wrote: On 2013-12-28 16:53-0700 Orion Poplawski wrote: On 06/27/2013 11:44 AM, RCY wrote: Hi, I am trying to build the development version of plplot with octave bindings. However I get numerous errors. Is the version incompatible with later versions of octave? Thanks [ 71%] Building CXX object bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o In file included from /usr/local/include/octave-3.7.5/octave/dim-vector.h:35:0, from /usr/local/include/octave-3.7.5/octave/Array.h:35, from /usr/local/include/octave-3.7.5/octave/boolMatrix.h:27, from /usr/local/include/octave-3.7.5/octave/mx-base.h:32, from /usr/local/include/octave-3.7.5/octave/Matrix.h:30, from /usr/local/include/octave-3.7.5/octave/oct.h:33, from /home/rc/Downloads/plplot/build/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: /usr/local/include/octave-3.7.5/octave/oct-refcount.h:27:3: error: #error The file octave/config.h must be included before oct-refcount.h. In file included from /usr/local/include/octave-3.7.5/octave/mx-base.h:28:0, from /usr/local/include/octave-3.7.5/octave/Matrix.h:30, from /usr/local/include/octave-3.7.5/octave/oct.h:33, from /home/rc/Downloads/plplot/build/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: /usr/local/include/octave-3.7.5/octave/MatrixType.h:36:1: error: variable ‘OCTAVE_API MatrixType’ has initializer but incomplete type /usr/local/include/octave-3.7.5/octave/MatrixType.h:36:1: warning: extended initializer lists only available with -std=c++11 or -std=gnu++11 [enabled by default] /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: expected primary-expression before ‘public’ /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: expected ‘}’ before ‘public’ /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: expected ‘,’ or ‘;’ before ‘public’ /usr/local/include/octave-3.7.5/octave/MatrixType.h:56:20: error: expected constructor, destructor, or type conversion before ‘;’ token /usr/local/include/octave-3.7.5/octave/MatrixType.h:58:21: error: ‘MatrixType’ does not name a type I'm seeing the same now with octave 3.8.0-rc2. Hi Orion and RCY: @RCY: if you want to write further comments to this list discussion (which I presume will be on-going) you are required but also most welcome to subscribe to this list. However, I am sure everyone will be happy to CC you (like I have) if you decide not to subscribe and simply want to read the further discussion without writing comments of your own. @Orion: Thanks for that report for an octave 3.8.0 release candidate. I notice the final version of octave 3.8.0 was released just today. (see ftp://ftp.gnu.org/gnu/octave). Once that version becomes available on Fedora could you confirm you are still seeing the same issue? I was intrigued by the #error The file octave/config.h must be included before oct-refcount.h. message. From our swig-generated code, bindings/octave/plplot_octaveOCTAVE_wrap.cxx, this message is coming from #include octave/oct.h which is _the first_ octave-related include in that source code. So I don't think this error has anything to do with us unless there is a new Octave 3.8.0 requirement (which I think would be unlikely) to include a different octave header before octave/oct.h. For your further information, Andrew's and my extensive tests of our octave bindings and examples for PLplot-5.9.11 were fine. Andrew tested that PLplot release on both Debian unstable and Ubuntu Saucy (both of which have Octave-3.6.4) and I tested on Debian stable (Octave version 3.6.2). Thus, it appears to me that since the above first octave include worked fine for those versions of octave yet errors out for octave-3.8.0, that it is highly probable all the above messages are due to an internal error in octave-3.8.0 itself which might or might not be sorted out by 3.8.0 final. If it is not sorted out by 3.8.0 final, then you might want to try a simple test of compiling code consisting of the single #include statement above. Assuming that errors out the same way, then that simple test could be used as the core of a report to the Octave developers to see what they say about the issue. Alan Still failing with 3.8.0 final: http://koji.fedoraproject.org/koji/getfile?taskID=6340306name=build.log $ g++ -c -fPIC -I/usr/include/octave-3.8.0/octave/.. -I/usr/include/octave-3.8.0/octave -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -pthread test.cc $ cat test.cc #include octave
Re: [Plplot-devel] Build problems with octave
(SWIG_Octave_InstallFunction);
^
/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:21891:35:
error: 'unwind_protect_int' was not declared in this scope
unwind_protect_int(error_state);
^
/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:21893:47:
error: 'unwind_protect_bool' was not declared in this scope
unwind_protect_bool(discard_error_messages);
^
/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:21913:5:
error: 'run_frame' is not a member of 'unwind_protect'
unwind_protect::run_frame(SWIG_Octave_InstallFunction);
^
/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
In member function 'virtual dim_vector octave_swig_type::dims() const':
/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1200:5:
warning: control reaches end of non-void function [-Wreturn-type]
}
^
/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
At global scope:
/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1859:28:
warning: 'octave_value_list octave_set_immutable(const
octave_value_list, int)' defined but not used [-Wunused-function]
static octave_value_list octave_set_immutable(const octave_value_list
args, int nargout) {
^
/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2158:5:
warning: 'int _arraylen(const octave_value)' defined but not used
[-Wunused-function]
_arraylen( const octave_value o_obj )
^
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
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=84349831iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Build problems with octave
On 12/29/2013 08:25 PM, Orion Poplawski wrote:
On 12/29/2013 01:34 PM, Alan W. Irwin wrote:
Please let me know if my latest PLplot change from config.h to
plplot_config.h (revision 12914) solves this issue. Of course, if it
doesn't solve it, the change was worth doing anyway. And if it does
solve it, I hope your bug report still convinces the Octave developers
to move back to using the quoted form of #include for config.h (or
better yet change the name to octave_config.h). After all, there are
likely quite a few software projects still left out there that do use
the config.h name (at least internally in their build tree as PLplot
did up to now).
Alan
Alan - That does indeed get us further - but now we seem to be into the
meat of the API changes in octave:
/usr/bin/cmake -E cmake_progress_report
/builddir/build/BUILD/plplot-5.9.11/fedora/CMakeFiles 19
[ 13%] Building CXX object
bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o
cd /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave
/usr/bin/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 -g -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -fPIC
-I/builddir/build/BUILD/plplot-5.9.11/include
-I/builddir/build/BUILD/plplot-5.9.11/lib/qsastime
-I/builddir/build/BUILD/plplot-5.9.11/fedora
-I/builddir/build/BUILD/plplot-5.9.11/fedora/include
-I/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave
-I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave
-I/builddir/build/BUILD/plplot-5.9.11/bindings/swig-support-o
CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c
/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx
/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1507:36:
warning: 'Octave_map' is deprecated (declared at
/usr/include/octave-3.8.0/octave/oct-map.h:484) [-Wdeprecated-declarations]
virtual Octave_map map_value() const {
^
/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1507:24:
error: invalid covariant return type for 'virtual Octave_map
octave_swig_type::map_value() const'
virtual Octave_map map_value() const {
^
So much/most of this may be a swig issue. I filed
https://sourceforge.net/p/swig/bugs/1353/ for it.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
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=84349831iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Build problems with octave
On 06/27/2013 11:44 AM, RCY wrote: Hi, I am trying to build the development version of plplot with octave bindings. However I get numerous errors. Is the version incompatible with later versions of octave? Thanks [ 71%] Building CXX object bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o In file included from /usr/local/include/octave-3.7.5/octave/dim-vector.h:35:0, from /usr/local/include/octave-3.7.5/octave/Array.h:35, from /usr/local/include/octave-3.7.5/octave/boolMatrix.h:27, from /usr/local/include/octave-3.7.5/octave/mx-base.h:32, from /usr/local/include/octave-3.7.5/octave/Matrix.h:30, from /usr/local/include/octave-3.7.5/octave/oct.h:33, from /home/rc/Downloads/plplot/build/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: /usr/local/include/octave-3.7.5/octave/oct-refcount.h:27:3: error: #error The file octave/config.h must be included before oct-refcount.h. In file included from /usr/local/include/octave-3.7.5/octave/mx-base.h:28:0, from /usr/local/include/octave-3.7.5/octave/Matrix.h:30, from /usr/local/include/octave-3.7.5/octave/oct.h:33, from /home/rc/Downloads/plplot/build/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: /usr/local/include/octave-3.7.5/octave/MatrixType.h:36:1: error: variable ‘OCTAVE_API MatrixType’ has initializer but incomplete type /usr/local/include/octave-3.7.5/octave/MatrixType.h:36:1: warning: extended initializer lists only available with -std=c++11 or -std=gnu++11 [enabled by default] /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: expected primary-expression before ‘public’ /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: expected ‘}’ before ‘public’ /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: expected ‘,’ or ‘;’ before ‘public’ /usr/local/include/octave-3.7.5/octave/MatrixType.h:56:20: error: expected constructor, destructor, or type conversion before ‘;’ token /usr/local/include/octave-3.7.5/octave/MatrixType.h:58:21: error: ‘MatrixType’ does not name a type I'm seeing the same now with octave 3.8.0-rc2. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- 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=84349831iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] rpmlint issues
On 10/16/2013 08:42 PM, Orion Poplawski wrote: plplot-ocaml.x86_64: W: unstripped-binary-or-object /usr/lib64/ocaml/stublibs/dllplplot_stubs.so plplot-ocaml.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/ocaml/stublibs/dllplplot_stubs.so ['/usr/lib64/ocaml', '/builddir/build/BUILD/plplot-5.9.10/fedora/src'] plplot-ocaml.x86_64: W: unstripped-binary-or-object /usr/lib64/ocaml/stublibs/dllplcairo_stubs.so plplot-ocaml.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/ocaml/stublibs/dllplcairo_stubs.so ['/usr/lib64', '/builddir/build/BUILD/plplot-5.9.10/fedora/src'] I'm assuming these are arising because cmake does not natively handle ocaml? We need to have the .so installed with the execute bit set (like other .so's on rpm systems) and rpath stripped. Seems to be an upstream ocaml bug: http://caml.inria.fr/mantis/view.php?id=5943 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Why ocamlc -custom
Why does plplot use ocamlc -custom to compile? I'm not sure it is necessary. If I remove it it appears to compile and tests run fine for me. I ask because of this: https://fedoraproject.org/wiki/Packaging:OCaml?rd=Packaging/OCaml#Stripping_binaries Stripping binaries Binaries should be stripped, as per ordinary Fedora packaging guidelines. There is one exception where a binary should not be stripped. If the package was compiled with ocamlc -custom then the package contains bytecode which strip will remove, thus rendering the binary inoperable. It is easy to test for this: If after stripping, any attempt to run the binary results in the message No bytecode file specified then the binary is compiled like this and should not be stripped. Rationale: http://bugs.debian.org/256900 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] rpmlint issues
On 10/17/2013 8:19 PM, Alan W. Irwin wrote:
Hi Orion:
This is part 4 and the last part of my reply.
On 2013-10-16 20:42-0600 Orion Poplawski wrote:
plplot-octave.x86_64: W: unstripped-binary-or-object
/usr/lib64/octave/site/oct/x86_64-redhat-linux-gnu/plplot_octave.oct
similar to the above, needs to be installed with execute bit set.
No, as stated in part 3 just treat this like you do all the
rest of our libraries which all have the same non-execute permissions
by default.
Nope, you are setting the permissions explicitly:
plplot-5.9.10/bindings/octave/CMakeLists.txt:
# Have to be specific about permissions for some reason (probably oct
suffix).
set(PERM_MODULES
OWNER_READ
OWNER_WRITE
GROUP_READ
WORLD_READ
)
install(TARGETS plplot_octave
EXPORT export_plplot
LIBRARY
DESTINATION ${OCTAVE_OCT_DIR}
PERMISSIONS ${PERM_MODULES}
)
If I remove the PERMISSIONS line, all is fine. The .oct is installed
executable.
Also, if there is any question about the above permissions complaints
for all of these *.in files, we deliberately set them to be executable
in our source tree and also in the installed examples tree. They
aren't actually meant to be executed so these execute permissions are
technically incorrect (as noticed by rpmlint), but that permission
automatically means the configured versions in both cases also have
the appropriate execute permissions which is the result we want.
There is probably a nicer way to get this result without setting
technically incorrect execute bits on the *.in files, but I am
not sure what it is. I will ask on the CMake list about this.
Thanks.
plplot-tk.x86_64: E: non-executable-script
/usr/share/plplot5.9.10/examples/tk/tk03 0644L /bin/sh
plplot-tk.x86_64: E: non-executable-script
/usr/share/plplot5.9.10/examples/tk/tk02 0644L
/usr/share/plplot5.9.10/examples/tk/xtk02
plplot-tk.x86_64: E: non-executable-script
/usr/share/plplot5.9.10/examples/tk/tk01 0644L
/usr/share/plplot5.9.10/examples/tk/xtk01
plplot-tk.x86_64: E: non-executable-script
/usr/share/plplot5.9.10/examples/tk/tk04 0644L
/usr/share/plplot5.9.10/examples/tk/xtk04
If these are meant to be executed directly (which the presence of a #!
suggests), they should have the execute bit set.
This is what I have here:
software@raven pushd $prefix/share/plplot5.9.10/examples/tk
where $prefix is my install prefix.
software@raven ls -lt *tk0*
-rwxr-xr-x 1 software software 3766 Oct 17 13:26 tk01*
-rwxr-xr-x 1 software software 3707 Mar 18 2013 tk01.in*
-rwxr-xr-x 1 software software 4243 Oct 17 13:26 tk02*
-rwxr-xr-x 1 software software 4184 Mar 18 2013 tk02.in*
-rwxr-xr-x 1 software software 6294 Oct 17 13:26 tk03*
-rwxr-xr-x 1 software software 6262 Mar 18 2013 tk03.in*
-rwxr-xr-x 1 software software 2821 Oct 17 13:26 tk04*
-rwxr-xr-x 1 software software 2762 Mar 18 2013 tk04.in*
-rw-r--r-- 1 software software 12881 Mar 18 2013 xtk01.c
-rw-r--r-- 1 software software 9103 Mar 18 2013 xtk02.c
-rw-r--r-- 1 software software 5697 Mar 18 2013 xtk04.c
Ah, sorry, I have:
#Don't pull in script interpreters for example binaries
chmod -x $RPM_BUILD_ROOT%{_datadir}/plplot%{version}/examples/tk/tk*
..
I was confused a bit by the rpmlint mention of xtk0[124] files.
However, that turns out to be just a mail wrap to an additional line
of the rpmlint output that expresses what is found after #! for each
of the configured tk0[124] files. Obviously, those xtk0[124] files
should not be built except by interested users after rpm installation
who want to test the system by trying the traditional or CMake-based
build systems for the installed examples.
And that's why I did the chmod - otherwise rpm adds a dependency on
/usr/share/plplot5.9.9/examples/tk/xtk01 (which is no good).
There's a better way to handle this now in rpm though.
plplot.x86_64: E: script-without-shebang
/usr/share/plplot5.9.10/examples/python/plplot_py_demos.py
Not sure the point of this guy, but if it is meant to be executed
directly it should have #!/usr/bin/python2 at the top, otherwise no
execute bit.
Again, it appears we differ in the permissions:
irwin@raven ls -l plplot_py_demos.py
-rw-r--r-- 1 software software 41 Oct 4 17:39 plplot_py_demos.py
What do you get for these permissions (in the installed examples tree)?
That file is just a python module and not a python script so the
above permissions are the correct ones.
In sum, we appear to have different permissions for some
of the files in the installed examples tree. It is obviously
important that we figure out the cause of this.
This seems to be the cause:
set(
python_SCRIPTS
${python_SCRIPTS}
...
plplot_py_demos.py
And:
set(PERM_SCRIPTS
OWNER_READ
OWNER_WRITE
OWNER_EXECUTE
GROUP_READ
GROUP_EXECUTE
WORLD_READ
WORLD_EXECUTE
)
install(FILES ${python_SCRIPTS}
${CMAKE_CURRENT_BINARY_DIR
Re: [Plplot-devel] rpmlint issues
On 10/17/2013 3:33 PM, Alan W. Irwin wrote: This is part 2 of my response concerning the overlinked libraries that rpmlint has turned up: On 2013-10-16 20:42-0600 Orion Poplawski wrote: [out of order] These libraries are unnecessarily linked with the specified library. I started to reply in detail showing the ldd --unused results, for a number of these libraries, but in all cases where that command differed from your results with rpmlint, ldd had indicated a library was unnnecessarily linked which actually (according to nm --undefined-only) had to be linked. That is, there were man ldd --unused false positives. So here I am going to ignore the results from that command, and concentrate on the rpmlint results, what make VERBOSE=1 says is actually linked, and nm --undefined-only results to attempt to confirm the rpmlint results. plplot-libs.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplotf95d.so.10.0.0 /lib64/libm.so.6 plplot-libs.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplotf95d.so.10.0.0 /lib64/libgcc_s.so.1 plplot-libs.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplotf95d.so.10.0.0 /lib64/libquadmath.so.0 These are not brought in by CMake directly. Instead, they are the result of using the gfortran command to link (which is necessary because that brings in libraries that are needed). So unless Debian and Fedora change gfortran, rpmlint will continue to signal overlinking issues for libplplotf95d which should be ignored. == nothing to do here at the PLplot level. Agreed. plplot-libs.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplotcxxd.so.11.0.0 /lib64/libm.so.6 plplot-libs.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplotcxxd.so.11.0.0 /lib64/libgcc_s.so.1 These are not brought in by CMake directly. Instead, they are the result of using the g++ command to link (which is necessary because that brings in libraries that are needed). So unless Debian and Fedora change g++, rpmlint will continue to signal overlinking issues for libplplotcxxd which should be ignored. == nothing to do here at the PLplot level. Agreed. plplot-qt.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplotqtd.so.1.0.0 /lib64/libQtXml.so.4 I presume libQtXml is explicitly linked in because we use the CMake find(Qt4) command without any components specified. It is possible to use that command with explicit components, e.g., find(Qt4 QtCore QtGui QtXml) or find(Qt4 QtCore QtGui) But I haven't tried that because I am positive dropping QtXml would be a disaster for the svgqt device whose file format is XML, after all. In other words, I am virtually positive that libQtXml is an rmplint false positive. Funny thing about library linkage - only if the plplotqtd code calls the QtXml library *directly* does it need to link to it. So I'm still not completely convinced. And the actual way to disable QtXml would normally be to set QT_USE_QTXML 0. However - the FindQt4 module enforces the linkage to QtXml if QtSvg is used, so it isn't a plplot issue. If I hack up cmake's UseQt4 to drop the QtXml dep everything still compiles and runs fine. plplot-tk.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplottcltkd.so.10.0.0 /lib64/libSM.so.6 plplot-tk.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplottcltkd.so.10.0.0 /lib64/libICE.so.6 plplot-tk.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplottcltkd.so.10.0.0 /lib64/libXext.so.6 These three overlinking issues have been fixed as of revision 12603. Thanks. plplot-wxGTK.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplotwxwidgetsd.so.0.0.0 /lib64/libfreetype.so.6 plplot-wxGTK.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplotwxwidgetsd.so.0.0.0 /lib64/libm.so.6 plplot-wxGTK.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplotwxwidgetsd.so.0.0.0 /lib64/libpthread.so.0 I think these are likely real overlinking issues, but I am going to put off dealing with these because the on-going discussions on this list about how we might change the interface between PLplot and wxwidgets might result in a substantially simplified implementation that which might reduce or elminate some of the overlinking issues above. ### Makes sense. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id
Re: [Plplot-devel] rpmlint issues
On 10/17/2013 6:23 PM, Alan W. Irwin wrote: To Hez and Orion: This is part 3 of my reply to Orion's post. But as a result I found an rpath deficiency in our OCaml build which leads to questions for Hez below which is why this is primarily directed to both Hez and Orion. On 2013-10-16 20:42-0600 Orion Poplawski wrote: plplot-ocaml.x86_64: W: unstripped-binary-or-object /usr/lib64/ocaml/stublibs/dllplplot_stubs.so plplot-ocaml.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/ocaml/stublibs/dllplplot_stubs.so ['/usr/lib64/ocaml', '/builddir/build/BUILD/plplot-5.9.10/fedora/src'] plplot-ocaml.x86_64: W: unstripped-binary-or-object /usr/lib64/ocaml/stublibs/dllplcairo_stubs.so plplot-ocaml.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/ocaml/stublibs/dllplcairo_stubs.so ['/usr/lib64', '/builddir/build/BUILD/plplot-5.9.10/fedora/src'] I'm assuming these are arising because cmake does not natively handle ocaml? @Orion: We do have a home-brew system to build what is needed for OCaml, but on the permissions issue we were careful to follow what is done for our other non-ocaml libraries that are built by more conventional CMake means. We need to have the .so installed with the execute bit set (like other .so's on rpm systems) No. The problem is other Linux distros (e.g., Debian) do not agree on this issue. By historical accident we decided to adopt the Debian convention so the above files conform to that as well as our normal PLplot libraries. So for the above files you just have to do what you did for other PLplot libraries. (Unless I am missing something.) Well, I do nothing special for the Fedora builds. I would assume then that cmake is able to determine the proper permission to use on Fedora for most libraries, but for some reason this is not being applied to the OCaml libraries. and rpath stripped. I think you meant symbols stripped. Which is what you have to do with all our libraries. No, I mean rpath - rpmlint is complaining about the /usr/lib64 rpath in the library. However, your mentioning of rpath and ocaml lead to me opening up a can of worms which is that I discovered rpath is not mentioned at all in bindings/ocaml/CMakeLists.txt or bindings/ocaml/plcairo/CMakeLists.txt. So the rest of this is primarily directed to Hez: @Hez: rpath not being used in the build tree is contrary to what CMake does by default in the build tree for normal libraries which is to use rpath everwhere to keep track of the wide variety of different build-tree locations that occur for Linux. This deficiency for the OCaml part of our build system should (although it doesn't, see my question for you below) affect everybody's attempts to test our ocaml bindings in the build tree. Here is the current situation in the build tree. software@raven ldd bindings/ocaml/dllplplot_stubs.so [...] libplplotd.so.12 = not found [...] software@raven ldd bindings/ocaml/plcairo/dllplcairo_stubs.so [...] libplplotd.so.12 = not found [...] which means that dllplplot_stubs.so and dllplcairo_stubs.so are completely unusable in the build tree by the run-time loader. How come we haven't run into any test issues because libplplotd cannot be found when the run-time loader attempts to load our ocaml libraries ? Are dllplplot_stubs.so and dllplcairo_stubs.so never actually used by our build-tree tests? Or might these not be normal libraries so the run-time loader would never be expected to load them? Now we move to a different part of the can of worms which is that no rpath is set in the install tree either. We don't use the CMake default for this (no rpath in install tree). Instead, for our other libraries and only if USE_RPATH is ON (which it isn't for Fedora or Debian package building since there is a normal package installation prefix in that case) we normally set rpath appropriately for whatever install prefix is set. So here are the current results for the install tree location: software@raven ldd /home/software/plplot_svn/installcmake/lib/ocaml/stublibs/dllplplot_stubs.so [...] libplplotd.so.12 = not found [...] software@raven ldd /home/software/plplot_svn/installcmake/lib/ocaml/stublibs/dllplcairo_stubs.so [...] libplplotd.so.12 = not found [...] @Hez: Same question as above but in this case for the installed version. This is the end of part 3 of my reply (which mostly ended up as questions for Hez). There is at least one more part to come. 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
Re: [Plplot-devel] The forthcoming PLplot-5.9.10 release
On 09/23/2013 11:01 AM, Alan W. Irwin wrote: I plan to release PLplot-5.9.10 in 5 days time on September 28th to make the large amount of work we have put into PLplot for the last two years more readily available to our users. The PLplot core developers are still working on one last issue (propagating plcolorbar changes to the Ada, D, and OCaml bindings and examples). For the rest of you, today and possibly tomorrow (but not later this week) is your last chance to get any simple, non-intrusive fixes into this release. So please take this opportunity to send us (on the plplot-devel mailing list) any of your simple PLplot patches (whether old patches which you would like to draw to our attention again or new patches). Also, please take this opportunity to try out the PLplot svn trunk version (using the new Allura location, http://svn.code.sf.net/p/plplot/code/trunk, which is what is going to turn into 5.9.10) and report those bugs either to the plplot-devel mailing list or the bug tracker. With revision 12530 things are looking good on Fedora Rawhide. Only diff in examples is: 25: ocaml 25: Missing examples: 25: Differing postscript output : 16 33 25: Missing stdout : 25: Differing stdout: -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Time for a release? pen width issues
On 08/23/2013 04:54 PM, Alan W. Irwin wrote:
On 2013-08-23 15:08-0600 Orion Poplawski wrote:
So, I've updated plplot in (yet to be released) Fedora 20 to svn12479. This
contains the change of wid - width for pen width. This is breaking my gdl
build because it is still trying to use wid() which is all of a sudden gone.
And now I have nothing like a version number change to key this on.
So:
- Is it intentional for plstream-wid() to be removed completely already?
At the C level plwid is still available if the builder specifies
-DPL_DEPRECATED=ON, but I suspect nobody has bothered to propagate
that deprecated version to other languages. So IIRC we have a gradual
change possible from plwid to plwidth for C, but an abrupt change for
the bindings. That was not intentional, but it is also not a bad
outcome since integer line widths are pretty old-fashioned and the fix
is easy (see below).
- Time for a release?
My opinion is this is long overdue. We still need to propagate the
plcolorbar changes to the OCaml and Ada bindings and examples and
document plcolorbar in doc/docbook/src/api.xml, but I think those
relatively minor issues are all that is currently blocking us from a
release.
- other suggestions?
You are probably aware of this already, but the gdl breakage should be
trivial to fix. Replace all instances of plstream-wid( integer
width) with plstream-plwidth(floating width). One could test plplot
to see if plwid or plwidth was available and key the change on that.
However, I agree it would make life much easier for you and others to
have a PLplot version number to key such a change.
Thus, getting out a PLplot release out soon is important not only for
this reason but many others.
Great.
FWIW - I'm doing something like the following in gdl for now:
iff -up gdl-0.9.3/CMakeLists.txt.plwidth gdl-0.9.3/CMakeLists.txt
--- gdl-0.9.3/CMakeLists.txt.plwidth2013-08-27 16:55:33.806600443 -0600
+++ gdl-0.9.3/CMakeLists.txt2013-08-27 16:55:36.589590528 -0600
@@ -23,6 +23,7 @@ include(CheckLibraryExists)
include(CheckFunctionExists)
include(CheckSymbolExists)
include(CheckCSourceRuns)
+include(CheckCXXSourceCompiles)
include(FindPkgConfig)
include(FindPackageHandleStandardArgs)
@@ -302,6 +303,18 @@ if(PLPLOT_FOUND)
message(STATUS warning, due to old plplot library, [XYZ]TICKFORMAT
option for plot ax
is will not be supported.\n
you should upgrade to plplot version 5.9.6)
endif(HAVE_PLPLOT_SLABELFUNC)
+ set(CMAKE_REQUIRED_INCLUDES ${PLPLOT_INCLUDE_DIR})
+ set(CMAKE_REQUIRED_LIBRARIES ${PLPLOT_LIBRARIES})
+ check_cxx_source_compiles(
+#include plplot/plstream.h
+int main(int argc, char **argv) {
+ plstream *p = new plstream();
+ PLFLT w = 0.5;
+ p-width(w);
+} HAVE_PLPLOT_WIDTH)
+ if(HAVE_PLPLOT_WIDTH)
+ set(HAVE_PLPLOT_WIDTH 1)
+ endif(HAVE_PLPLOT_WIDTH)
check_library_exists(${PLPLOT_LIBRARIES} plstrl
PLPLOT_PRIVATE_NOT_HIDDEN)
if(PLPLOT_PRIVATE_NOT_HIDDEN)
set(PLPLOT_PRIVATE_NOT_HIDDEN 1)
diff -up gdl-0.9.3/config.h.cmake.plwidth gdl-0.9.3/config.h.cmake
--- gdl-0.9.3/config.h.cmake.plwidth2013-08-27 16:55:33.808600436 -0600
+++ gdl-0.9.3/config.h.cmake2013-08-27 16:55:36.589590528 -0600
@@ -28,6 +28,7 @@
#cmakedefine HAVE_NEXTTOWARD 1
#cmakedefine HAVE_OLDPLPLOT 1
#cmakedefine HAVE_PLPLOT_SLABELFUNC 1
+#cmakedefine HAVE_PLPLOT_WIDTH 1
#cmakedefine PLPLOT_PRIVATE_NOT_HIDDEN 1
#cmakedefine PLPLOT_HAS_LEGEND
#ifndef HAVE_STDINT_H
Then keying off of HAVE_PLPLOT_WIDTH.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Extra DESTDIR
On 08/09/2013 06:04 PM, Alan W. Irwin wrote: On 2013-08-09 09:55-0600 Orion Poplawski wrote: On 08/09/2013 09:24 AM, Alan W. Irwin wrote: Anyhow, I will test both the doxygen install and docbook install cases and figure out what to do. Specifically, the plplotdoc.info files ended up with the duplicated DESTDIR. Not sure about anything else I'm afraid. To Orion and Andrew: Please try revision 12479 with cmake options -DBUILD_DOX_DOC=ON -DBUILD_DOC=ON (which should build both the doxygen and docbook documentation). That case works without errors for me when I run make DESTDIR=whatever install on Debian wheezy. I would also advise using -DBUILD_DOX_DOC=ON when generating Fedora rpm's or Debian packages. Of course, both our doxygen-generated and docbook-generated documentation needs work (see my recent comments about some of the bit rot that is showing up for the doxygen documentation, and Lord knows it is long past time to move our docbook generation completely over to docbook XML tools rather than partially relying on historical docbook SGML tools which are no longer maintained). Nevertheless, despite these known issues, the results we now have for both doxygen and docbook are well worth distributing. Therefore, since both of you already distribute the docbook results, I think you will probably both want to distribute the doxygen results as well. - 12479 installs fine. - The doxygen documentation is huge ~88MB - I don't think the docbook documentation builds anymore on Fedora: -- DSSSL Style Sheet DTD found -- DocBook HTML Stylesheet found -- DocBook Print Stylesheet found -- WARNING: DocBook DTD not found -- WARNING: Not building print documentation - dtd files / style sheets are missing -- WARNING: Not building html documentation - dtd files / style sheets are missing jadeout.log.x: /usr/bin/openjade:/usr/share/sgml/docbook/xml-dtd-4.5/ent/isogrk4.ent:42:30:E: 1D6C2 is not a character number in the document character set /usr/bin/openjade:/usr/share/sgml/docbook/xml-dtd-4.5/ent/isogrk4.ent:43:30:E: 1D6C3 is not a character number in the document character set /usr/bin/openjade:/usr/share/sgml/docbook/xml-dtd-4.5/ent/isogrk4.ent:44:30:E: 1D6D8 is not a character number in the document character set . This may be a Fedora issue... -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Extra DESTDIR
On 08/12/2013 10:57 AM, Orion Poplawski wrote: - I don't think the docbook documentation builds anymore on Fedora: -- DSSSL Style Sheet DTD found -- DocBook HTML Stylesheet found -- DocBook Print Stylesheet found -- WARNING: DocBook DTD not found -- WARNING: Not building print documentation - dtd files / style sheets are missing -- WARNING: Not building html documentation - dtd files / style sheets are missing jadeout.log.x: /usr/bin/openjade:/usr/share/sgml/docbook/xml-dtd-4.5/ent/isogrk4.ent:42:30:E: 1D6C2 is not a character number in the document character set /usr/bin/openjade:/usr/share/sgml/docbook/xml-dtd-4.5/ent/isogrk4.ent:43:30:E: 1D6C3 is not a character number in the document character set /usr/bin/openjade:/usr/share/sgml/docbook/xml-dtd-4.5/ent/isogrk4.ent:44:30:E: 1D6D8 is not a character number in the document character set . This may be a Fedora issue... https://bugzilla.redhat.com/show_bug.cgi?id=703472 seems to point to the fact of sgml being dead and needing to use xmlto. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Extra DESTDIR
On 08/09/2013 09:24 AM, Alan W. Irwin wrote:
On 2013-08-08 10:01-0600 Orion Poplawski wrote:
Okay, next issue :)
r12284 | airwin | 2013-01-07 22:26:34 -0700 (Mon, 07 Jan 2013) | 13 lines
Insert \$ENV{DESTDIR} appropriately (with the $ escaped because you
want the environment variable DESTDIR to be read at install time
rather than cmake time) for all install(CODE ... signatures usage.
This change should let make DESTDIR=whatever install work
correctly at install time whenever the doxygen documentation and the
docbook documentation are being installed.
Only the doxygen install change has been tested, but the
corresponding change to the docbook install should also work
since the same CMake rules should apply.
This ends up adding an extra DESTDIR in the path since cmake automatically
handles adding DESTDIR to the paths. This is with -DBUILD_DOC:BOOL=ON. I
have not tested with PREBUILT_DOC.
Reverting this commit fixes the install for me (unsurprising since 12281 was
working fine for me before).
From the above commit message I explicitly tested that this worked
for the doxygen case. Is that case also fine for you, i.e., is
the docbook cases the only ones where DESTDIR is applied twice?
I also notice (now) that the docbook case uses the file(INSTALL...)
signature inside the install(CODE...) command. Normally,
install(CODE...) needs explicit DESTDIR (which my above commit
supplied), but one interpretation of the documentation would imply the
case where file(INSTALL...) is used inside install(CODE...) is an
exception to that rule which would mean DESTDIR would be applied twice
but only for the docbook cases and not for the doxgyen case.
Anyhow, I will test both the doxygen install and docbook install
cases and figure out what to do.
Specifically, the plplotdoc.info files ended up with the duplicated DESTDIR.
Not sure about anything else I'm afraid.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Extra DESTDIR
Okay, next issue :)
r12284 | airwin | 2013-01-07 22:26:34 -0700 (Mon, 07 Jan 2013) | 13 lines
Insert \$ENV{DESTDIR} appropriately (with the $ escaped because you
want the environment variable DESTDIR to be read at install time
rather than cmake time) for all install(CODE ... signatures usage.
This change should let make DESTDIR=whatever install work
correctly at install time whenever the doxygen documentation and the
docbook documentation are being installed.
Only the doxygen install change has been tested, but the
corresponding change to the docbook install should also work
since the same CMake rules should apply.
This ends up adding an extra DESTDIR in the path since cmake automatically
handles adding DESTDIR to the paths. This is with -DBUILD_DOC:BOOL=ON. I
have not tested with PREBUILT_DOC.
Reverting this commit fixes the install for me (unsurprising since 12281 was
working fine for me before).
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] plwid - plwidth broke Ada bindings
So, svn commit 12288: r12288 | airwin | 2013-01-29 21:40:35 -0700 (Tue, 29 Jan 2013) | 13 lines Replace plwid everywhere by plwidth, and store pen width arguments as PLFLT's everywhere (that I can find them). These changes allow width parameters 1. to work for cairo devices, e.g., examples/c/x03c.c -dev xcairo -width 0.3 gives extremely thin line results. Further discussion on list of what else there is to do. --- bindings/ada/plplot.adb (revision 12287) +++ bindings/ada/plplot.adb (working copy) @@ -3311,10 +3311,10 @@ -- Set pen width. --- plwid +-- plwidth procedure Set_Pen_Width(Pen_Width : Integer) is begin -plwid(Pen_Width); +plwidth(Pen_Width); end Set_Pen_Width; appears to have broken the ada bindings. I get: [ 13%] Building Ada object bindings/ada/CMakeFiles/plplotadad.dir/plplot.o cd /export/home/orion/fedora/plplot/plplot-5.9.9/fedora/bindings/ada /usr/bin/gnatgcc -fPIC -c /export/home/orion/fedora/plplot/plplot-5.9.9/bindings/ada/plplot.adb -o CMakeFiles/plplotadad.dir/plplot.o plplot.adb:3317:17: expected type Standard.Long_Float plplot.adb:3317:17: found type Standard.Integer Now, I was about to simply change the argument to Set_Pen_Width to be a Long_Float, but this changes the API/ABI. So, should the ada bindings grow a new interface (Set_Pen_Width_Float?) that takes a Long_Float and calls plwidth? That seems the most appropriate to me. Comments? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plwid - plwidth broke Ada bindings
On 08/07/2013 04:00 PM, Alan W. Irwin wrote: Hi Orion: Thanks for your report. I cannot reproduce this for irwin@raven gnatgcc --version gnatgcc (Debian 4.6.3-14) 4.6.3 So I suspect you have a newer version of gnatgcc which is being more careful about types than 4.6.3. Using 4.8.1, so that is probably true :) -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] lua test errors
I'm trying to rebuild the Fedora plplot package for Fedora 20 and am getting the following error: Start 10: examples_lua 10: Test command: /usr/bin/bash -c EXAMPLES_DIR=/builddir/build/BUILD/plplot-5.9.9/fedora/examples SRC_EXAMPLES_DIR=/builddir/build/BUILD/plplot-5.9.9/examples ./plplot-test.sh --verbose --device=psc --front-end=lua 10: Test timeout computed to be: 1500 10: Testing front-end lua 10: x00 10: x01 10: x02 10: x03 10: x04 10: /usr/bin/lua: x04.lua:59: attempt to call field 'log10' (a nil value) 10: stack traceback: 10: x04.lua:59: in function 'plot1' 10: x04.lua:182: in main chunk 10: [C]: in ? 10/16 Test #10: examples_lua .***Failed0.06 sec This is with svn 12281 which is what is currently in Fedora. Current svn fails with the Ada issue mentioned earlier. Looks like math.log10 was removed in lua 5.2 (we have lua 5.2.2 in F20), to be replaced with math.log(x,10). I suppose we are going to need grow some conditionals here. No idea how to handle that in lua. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Probably gcc 4.8 ada issue
On 01/31/2013 12:48 AM, Jerry wrote: Orion: I checked the 18 places that you reported an error and in every line, there is a conversion of Long_Float to Integer using the Integer( ) function with a Long_Float as an argument. It appears extremely likely that in each case the exception is being raised at the first attempt to make the conversion in a given example. I don't think there is anything that I can do for this situation. If you are sure that you don't have a hardware problem re (2) above then someone should file a bug report, but, as far as I'm concerned, my note to comp.lang.ada suffices since there are a number of gurus on the list and I assume the GNAT folks monitor the list although if so they are surely quiet or anonymous. Thanks. I filed: https://bugzilla.redhat.com/show_bug.cgi?id=906516 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Probably gcc 4.8 ada issue
On 01/29/2013 03:21 AM, Jerry wrote: Hi Orion, This is puzzling. I can't see what could possibly be causing this. (By this I mean the x02.adb example, as I haven't looked any of the others.) I have not set ranges for any of the entities involved. (In Ada, you can specify an allowed range for a variable. For instance, one could specify that r1 is constrained between 0.0 and 1.0 and any attempt to assign a value outside that range would raise an overflow (I think) exception.) So I don't see where there is an opportunity to overflow either r1, a 64-bit float or r( ), a 32-bit integer. FWIW, GNAT does something a little controversial--it defaults to disabling overflow checking. The controversy is that this compiler is then, by default, not an Ada compiler. But I don't see how that is apropos to this situation. Can you try running this program and report the results? with Ada.Text_IO; use Ada.Text_IO; procedure Test_Overflow is r : Integer; r1 : Long_Float := 0.3; begin Put_Line(Running); r := Integer((r1 * 255.001) - 0.499); end Test_Overflow; Compile and run: $ gnatmake Test_Overflow.adb $./test_overflow I also tried it with overflow checking turned on: $ gnatmake -gnato Test_Overflow.adb $./test_overflow It works either way on my system. [orion@vmrawhide ~]$ gnatmake Test_Overflow.adb gcc -c Test_Overflow.adb Test_Overflow.adb:2:11: warning: file name does not match unit name, should be test_overflow.adb gnatbind -x Test_Overflow.ali gnatlink Test_Overflow.ali [orion@vmrawhide ~]$ ./Test_Overflow Running raised CONSTRAINT_ERROR : Test_Overflow.adb:7 overflow check failed [[orion@vmrawhide ~]$ rm Test_Overflow Test_Overflow.o Test_Overflow.ali [orion@vmrawhide ~]$ gnatmake -gnato Test_Overflow.adb gcc -c -gnato Test_Overflow.adb Test_Overflow.adb:2:11: warning: file name does not match unit name, should be test_overflow.adb gnatbind -x Test_Overflow.ali gnatlink Test_Overflow.ali [orion@vmrawhide ~]$ ./Test_Overflow Running raised CONSTRAINT_ERROR : Test_Overflow.adb:7 overflow check failed -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Probably gcc 3.8 ada issue
Fedora rawhide has moved to gcc 3.8 and I'm seeing: $ ./x02a -dev psc -o x02a.psc raised CONSTRAINT_ERROR : x02a.adb:138 overflow check failed I'm taking that this is due to some increased checking with ada in 3.8. Thoughts? 98 procedure demo2 is 99 -- Set up cmap0 100 -- Use 100 custom colors in addition to base 16 101 r, g, b: Integer_Array_1D(0..115); 102 103 -- Min max lightness values 104 lmin : Long_Float := 0.15; 105 lmax : Long_Float := 0.85; 106 h, l, s : Long_Float; 107 r1, g1, b1 : Long_Float; 108 begin 109 plbop; 110 111 -- Divide screen into 100 regions. 112 plssub(10, 10); 113 114 for i in 0..99 loop 115 116 -- Bounds on HLS, from plhlsrgb() commentary 117 -- hue[0., 360.] degrees 118 -- lightness [0., 1.] magnitude 119 -- saturation [0., 1.] magnitude 120 121 -- Vary hue uniformly from left to right 122 h := (360.0 / 10.0 ) * Long_Float( i mod 10 ); 123 124 -- Vary lightness uniformly from top to bottom, between min max. 125 l := lmin + (lmax - lmin) * Long_Float(i / 10) / 9.0; 126 127 -- Use max saturation. 128 s := 1.0; 129 130 plhlsrgb(h, l, s, r1, g1, b1); 131 132 -- Ada converts floats to integers by rounding while C does so by 133 -- truncation. There is no fool-proof way to fix that but this is pretty 134 -- close: Add a bit less than 1/2 to the float before converting. A good 135 -- number to use appears to be about 0.5 - 10^-16 which _might_ 136 -- be an exact fix for 64-bit floats since they have about 16 digits 137 -- of accuracy. 138 r(i+16) := Integer((r1 * 255.001) - 0.499); 139 g(i+16) := Integer((g1 * 255.001) - 0.499); 140 b(i+16) := Integer((b1 * 255.001) - 0.499); 141 end loop; 142 143 -- Load default cmap0 colors into our custom set. 144 for i in 0..15 loop 145 plgcol0(i, r(i), g(i), b(i)); 146 end loop; 147 148 -- Now set cmap0 all at once (faster, since fewer driver calls). 149 plscmap0(r, g, b); 150 151 draw_windows(100, 16); 152 153 pleop; 154 end demo2; -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Probably gcc 4.8 ada issue
On 01/28/2013 07:54 PM, Alan W. Irwin wrote: On 2013-01-28 17:01-0700 Orion Poplawski wrote: Fedora rawhide has moved to gcc 3.8 and I'm seeing: $ ./x02a -dev psc -o x02a.psc raised CONSTRAINT_ERROR : x02a.adb:138 overflow check failed I'm taking that this is due to some increased checking with ada in 3.8. Thoughts? Hi Orion: I am virtually positive you meant the gcc-4.8 development effort which (as far as I can tell) has not had a single release yet. So I am changing the subject line accordingly. But please confirm that is what you meant. If you meant gcc-4.8, there is always the chance that the symptom you are seeing is a general problem caused by some recently introduced version incompatibilty between gcc and Ada that still needs to be worked out, i.e., a compiler inconsistency issue that has nothing to do with PLplot development. On the other hand, it might be a PLplot Ada issue that has been detected by (presumably) better error checking for the latest versions of gcc/Ada as you have suggested. To help decide between those two possibilities, could you give more details? For example, if you use the make -k option (to keep going despite errors) are you able to compile all the Ada examples other than the second one? If the issue is confined to just one of our examples, then it is much more likely a PLplot Ada issue with that example (or the API tested with that example) as you have suggested. Sorry, yes it is 4.8. Fedora is very tight with gcc development so we get things early - fun! The example compiles fine, it just doesn't run. Some others don't run either (see below). It looks very much like a floating point overflow condition is being triggered. With a debug statement it aborts at the start of the loop: i = 0 r1 = 3.00E-01 I suspect that: 138 r(i+16) := Integer((r1 * 255.001) - 0.499); Has too many digits to be properly expressed. The comments indicate that it is dealing with some rounding/truncating differences. I suspect that gcc in 4.8 traps these conditions by default. Others: raised CONSTRAINT_ERROR : x02a.adb:141 overflow check failed raised CONSTRAINT_ERROR : x03a.adb:92 overflow check failed raised CONSTRAINT_ERROR : plplot_thin.adb:179 overflow check failed raised CONSTRAINT_ERROR : x12a.adb:105 overflow check failed raised CONSTRAINT_ERROR : x13a.adb:73 overflow check failed raised CONSTRAINT_ERROR : x14a.adb:218 overflow check failed raised CONSTRAINT_ERROR : plplot_thin.adb:179 overflow check failed raised CONSTRAINT_ERROR : x18a.adb:156 overflow check failed raised CONSTRAINT_ERROR : x19a.adb:192 overflow check failed raised CONSTRAINT_ERROR : plplot_thin.adb:241 overflow check failed raised CONSTRAINT_ERROR : plplot_auxiliary.adb:40 overflow check failed raised CONSTRAINT_ERROR : xthick02a.adb:136 overflow check failed raised CONSTRAINT_ERROR : xthick03a.adb:92 overflow check failed raised CONSTRAINT_ERROR : xthick12a.adb:104 overflow check failed raised CONSTRAINT_ERROR : xthick13a.adb:73 overflow check failed raised CONSTRAINT_ERROR : xthick14a.adb:218 overflow check failed raised CONSTRAINT_ERROR : xthick18a.adb:155 overflow check failed raised CONSTRAINT_ERROR : xthick19a.adb:192 overflow check failed -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Fwd: [Bug 893972] New: the plplot-devel rpm is missing dependencies
On 01/11/2013 12:03 AM, Alan W. Irwin wrote:
On 2013-01-10 21:02-0700 Orion Poplawski wrote:
In Fedora we package up plplot into lots of sub-packages for the
different interfaces. However this appears to be causing problems for
users of the export_plplot cmake module because it wants to be able to
find all of the plplot modules, even if they are not needed for the
project.
I know very little about the expected ways to use cmake to find and use
plplot. Perhaps this isn't even the way one is supposed to do it.
What is needed from a packaging perspective is a way for users of plplot
to specify which interface(s) they want and only load/check for those.
Is this currently available?
Thoughts/comments? Thanks!
To Orion and Andrew:
It's a small world! I was unaware of this issue until now, but David
Howells, the author of this bug report is collaborating with me on
ephcom and te_gen development, and te_gen needs PLplot for the subset of
its tests
that make residual plots. He probably decided to bother you with this
rather than me because I am in the last day or so of releases for
ephcom and te_gen. However, I wouldn't mind a break, and I am the
sole author of this part of the CMake build system for PLplot (which
David is
probably unware of) so I will take the time to answer this in detail.
(I have included David in the cc list, but, David, if your reply
includes the plplot-devel mailing list address, your reply will
just bounce since I don't think you are subscribed.)
Every PLplot library and shared object exports its CMake data via one
set of export files for all of Plplot. The generic name of that set
is export_plplot. So to look closer at what is going on, look for
export_plplot in the PLplot source tree with a bit of context included in
the grep. Here are those results:
software@raven find . -type f |grep -v svn |xargs grep -B1 export_plplot
./lib/qsastime/CMakeLists.txt-install(TARGETS qsastime
./lib/qsastime/CMakeLists.txt: EXPORT export_plplot
--
./lib/nistcd/CMakeLists.txt- install(TARGETS nistcd
./lib/nistcd/CMakeLists.txt:EXPORT export_plplot
--
./lib/nn/CMakeLists.txt- install(TARGETS csironn
./lib/nn/CMakeLists.txt:EXPORT export_plplot
--
./lib/csa/CMakeLists.txt- install(TARGETS csirocsa
./lib/csa/CMakeLists.txt:EXPORT export_plplot
--
./bindings/tk/CMakeLists.txt- install(TARGETS plserver
./bindings/tk/CMakeLists.txt:EXPORT export_plplot
--
./bindings/c++/CMakeLists.txt- install(TARGETS plplotcxx${LIB_TAG}
./bindings/c++/CMakeLists.txt:EXPORT export_plplot
--
./bindings/octave/CMakeLists.txt- install(TARGETS plplot_octave
./bindings/octave/CMakeLists.txt:EXPORT export_plplot
--
./bindings/qt_gui/pyqt4/CMakeLists.txt-TARGETS plplot_pyqt4
./bindings/qt_gui/pyqt4/CMakeLists.txt:EXPORT export_plplot
--
./bindings/qt_gui/CMakeLists.txt- install(TARGETS plplotqt${LIB_TAG}
./bindings/qt_gui/CMakeLists.txt:EXPORT export_plplot
--
./bindings/f77/CMakeLists.txt- install(TARGETS plplotf77c${LIB_TAG}
./bindings/f77/CMakeLists.txt:EXPORT export_plplot
--
./bindings/f77/CMakeLists.txt- install(TARGETS plplotf77${LIB_TAG}
./bindings/f77/CMakeLists.txt:EXPORT export_plplot
--
./bindings/tcl/CMakeLists.txt-install(TARGETS tclmatrix${LIB_TAG}
./bindings/tcl/CMakeLists.txt:EXPORT export_plplot
--
./bindings/tcl/CMakeLists.txt-install(TARGETS plplottcltk${LIB_TAG}
./bindings/tcl/CMakeLists.txt:EXPORT export_plplot
--
./bindings/python/CMakeLists.txt-TARGETS plplot_widgetmodule
_plplotcmodule
./bindings/python/CMakeLists.txt:EXPORT export_plplot
--
./bindings/wxwidgets/CMakeLists.txt- install(TARGETS
plplotwxwidgets${LIB_TAG}
./bindings/wxwidgets/CMakeLists.txt:EXPORT export_plplot
--
./bindings/ada/CMakeLists.txt- install(TARGETS plplotada${LIB_TAG}
./bindings/ada/CMakeLists.txt:EXPORT export_plplot
--
./bindings/lua/CMakeLists.txt- install(TARGETS plplotluac
./bindings/lua/CMakeLists.txt:EXPORT export_plplot
--
./bindings/d/CMakeLists.txt- install(TARGETS plplotdmd${LIB_TAG}
./bindings/d/CMakeLists.txt:EXPORT export_plplot
--
./bindings/gnome2/lib/CMakeLists.txt- install(TARGETS
plplotgnome2${LIB_TAG}
./bindings/gnome2/lib/CMakeLists.txt:EXPORT export_plplot
--
./bindings/gnome2/python/CMakeLists.txt-TARGETS gcwmodule
./bindings/gnome2/python/CMakeLists.txt:EXPORT export_plplot
--
./bindings/gnome2/python/CMakeLists.txt-TARGETS cplplotcanvasmodule
./bindings/gnome2/python/CMakeLists.txt:EXPORT export_plplot
--
./bindings/f95/CMakeLists.txt- install(TARGETS plplotf95c${LIB_TAG}
./bindings/f95/CMakeLists.txt:EXPORT export_plplot
--
./bindings/f95/CMakeLists.txt- install(TARGETS plplotf95${LIB_TAG}
./bindings/f95/CMakeLists.txt:EXPORT export_plplot
--
./drivers/CMakeLists.txt-install(TARGETS ${SOURCE_ROOT_NAME}
./drivers/CMakeLists.txt: EXPORT export_plplot
[Plplot-devel] Fwd: [Bug 893972] New: the plplot-devel rpm is missing dependencies
In Fedora we package up plplot into lots of sub-packages for the different interfaces. However this appears to be causing problems for users of the export_plplot cmake module because it wants to be able to find all of the plplot modules, even if they are not needed for the project. I know very little about the expected ways to use cmake to find and use plplot. Perhaps this isn't even the way one is supposed to do it. What is needed from a packaging perspective is a way for users of plplot to specify which interface(s) they want and only load/check for those. Is this currently available? Thoughts/comments? Thanks! Original Message Subject: [Bug 893972] New: the plplot-devel rpm is missing dependencies Date: Thu, 10 Jan 2013 12:18:15 + From: bugzi...@redhat.com To: or...@cora.nwra.com Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=893972 Bug ID: 893972 Summary: the plplot-devel rpm is missing dependencies Product: Fedora Version: 17 Component: plplot Severity: unspecified Priority: unspecified Reporter: dhowe...@redhat.com Created attachment 676277 -- https://bugzilla.redhat.com/attachment.cgi?id=676277action=edit Test script Description of problem: I'm trying to build te_gen from the time-ephemeris project with full testing enabled. This includes running cmake in the te_gen directory and telling it where to find the cmake export files for plplot development as te_gen uses plplot as part of its testing. This doesn't work, however, as the /usr/share/plplot5.9.9/examples/cmake/modules/export_plplot-noconfig.cmake file has a bunch of dependencies on plplot subpackages that the plplot-devel rpm doesn't know about. Version-Release number of selected component (if applicable): plplot-devel-5.9.9-7.svn12202.fc17.x86_64 How reproducible: 100% Steps to Reproduce: This is slightly complicated as ephcom2 has to be built first and data has to be supplied. I will attach a pair of source tarballs and a script to download the data and do all the building. 1. Unpack the ephcom2 and te_gen tarballs. 2. Configure the script. This means altering the paths at the top of it. JPL_DATA_DIR needs to point to where the data should be downloaded. INPOP_DATA_DIR can just point to /tmp - we don't need that data. EPHCOM_DIR and TE_GEN_DIR need to point to the sources you unpacked in step 1. INSTALL_DIR and INSTALL_BUILD_DIR are just a pair of scratch directories. PLPLOT_MODULE_PATH should point to where the plplot cmake modules are installed. 3. Run the script. Actual results: cmake fails with things like this: CMake Error at /usr/share/plplot5.9.9/examples/cmake/modules/export_plplot- noconfig.cmake:359 (MESSAGE): The imported target tclmatrixd references the file /usr/lib64/libtclmatrixd.so.9.2.0 Indicating plplot-tk is not installed. CMake Error at /usr/share/plplot5.9.9/examples/cmake/modules/export_plplot- noconfig.cmake:359 (MESSAGE): The imported target plplot_octave references the file /usr/lib64/octave/site/oct/x86_64-redhat-linux-gnu/plplot_octave.oct Indicating plplot-octave is not installed. CMake Error at /usr/share/plplot5.9.9/examples/cmake/modules/export_plplot- noconfig.cmake:359 (MESSAGE): The imported target plplotwxwidgetsd references the file /usr/lib64/libplplotwxwidgetsd.so.0.0.0 Indicating plplot-wxGTK is not installed. CMake Error at /usr/share/plplot5.9.9/examples/cmake/modules/export_plplot- noconfig.cmake:359 (MESSAGE): The imported target plplotadad references the file /usr/lib64/libplplotadad.so.0.0.0 Indicating plplot-ada is not installed. CMake Error at /usr/share/plplot5.9.9/examples/cmake/modules/export_plplot- noconfig.cmake:359 (MESSAGE): The imported target plplotluac references the file /usr/lib64/lua/5.1/plplot/plplotluac.so Indicating plplot-lua is not installed. Expected results: cmake shouldn't show up such errors. Additional info: -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] DESTDIR needs to be used for install(CODE... ?
On 01/07/2013 12:57 PM, Alan W. Irwin wrote:
To Andrew and Orion:
One of my testers for ephcom is David Howells who works as a developer
for RedHat. He found that rpm's for ephcom that he implemented could
not be built without using DESTDIR for all install(CODE logic in the
ephcom build system. For example ephcom's doc/CMakeLists.txt file now
has this code fragment (which was originally copied without DESTDIR
from doc/CMakeLists.txt in PLplot).
doc/CMakeLists.txt: install(CODE message(STATUS \Installing:
${DOC_DIR}/doxygen/html tree\)\nexecute_process(COMMAND
${CMAKE_COMMAND} -E copy_directory
${CMAKE_CURRENT_BINARY_DIR}/doxygen/html
${DESTDIR}${CMAKE_INSTALL_DOCDIR}/doxygen/html))
Do you agree that DESTDIR should also be used in the equivalent PLplot
file? How have you guys been getting around this potential issue
for Debian and Fedora packaging of PLplot?
I really don't think you ever want to specify ${DESTDIR} in *any* cmake
scripts. cmake will automatically do the right things behind the scenes
to handle DESTDIR.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] ABI compatibility
On 12/19/2012 02:05 AM, Alan W. Irwin wrote: On 2012-12-18 21:14-0700 Orion Poplawski wrote: Just writing to highlight some ABI incompatibility between plplot 5.9.9 and current svn, see: http://upstream-tracker.org/versions/plplot.html I'm not sure when the changes were introduced or if they can be fixed before a final release. Hi Orion: I actually think that is a pretty good report. The only severe issues involve plcolorbar which had deliberate changes in its API during this release cycle. So there is nothing to fix here, but it might be worthwhile mentioning in the release notes that the plcolorbar API (which I believe we mentioned was an experimental API for the last release) has undergone some improvements and has now (I believe) been stabilized. Okay, sounds good. Thanks. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] ABI compatibility
Just writing to highlight some ABI incompatibility between plplot 5.9.9 and current svn, see: http://upstream-tracker.org/versions/plplot.html I'm not sure when the changes were introduced or if they can be fixed before a final release. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] CMAKE_INSTALL_LIBDIR
cmake has a new module GNUInstallDirs that defines CMAKE_INSTALL_LIBDIR
as either lib or lib64 as needed. plplot currently defines it as
${CMAKE_INSTALL_PREFIX}/lib. Perhaps plplot could be updated to the new
convention?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] octave 3.6.0 issues
On 02/08/2012 11:25 AM, Alan W. Irwin wrote: On 2012-02-08 07:44- Andrew Ross wrote: On Tue, Feb 07, 2012 at 09:28:27PM -0700, Orion Poplawski wrote: On 01/28/2012 12:27 PM, Andrew Ross wrote: On Sat, Jan 28, 2012 at 08:02:17AM -0700, Orion Poplawski wrote: On 01/28/2012 01:04 AM, Andrew Ross wrote: Orion - the changes were committed to svn last week. Have you tried since then? If so and it still fails, can you provide details? Sorry, forgot to check. But split is still used in test_octave.sh.in and test_octave_interactive.sh.in. Orion, No problem. Thanks for spotting the test scripts. I'd overlooked that one. Now fixed as well. Andrew Finally was able to build (due to other Fedora issues). All looks good now. Thanks. Glad to hear it. Orion, it is good that you can now build octave, but what is the run-time story? To discover that you have to run the test targets for octave. You can find those from make help |grep test_octave which on my system produces ... test_octave_psc ... test_octave_qtwidget ... test_octave_tk ... test_octave_wxwidgets ... test_octave_xcairo ... test_octave_xwin Considering all the trouble we had with API changes in octave in the old days from one version to the next, I would be surprised but quite pleased if all those (especially the interactive ones after test_octave_psc) worked for you. For my Octave 3.2.4 version from Debian squeeze (which is the oldest version of Octave we currently support) I have just now tried all these test targets. test_octave_wxwidgets (the wxGC version of the wxwidgets device driver) generated a segfault. Apparently from the comments in the scripts, that always happens whenever multiple plots are tried. So that adds a non-octave issue hat needs to be fixed for the wxwidgets device driver. But the rest of the devices are well maintained, and for them I got no segfaults or any other obvious run-time errors and mostly consistent interactive results. Do you get similar good interactive results (except for test_octave_wxwidgets) for 3.6.0? Same question for you, Andrew, for whatever version of Octave you are testing at the moment. If all three of us can produce good interactive results for octave, then it is probably time to consider making the above interactive tests (except for test_octave_wxwidgets) a dependency of the test_interactive target. (I didn't do that before because in the old days a lot of those interactive tests failed.) Since all the p?? examples appear to be working now for the interactive case, it may also be time to expand the list of examples that are tried for test_octave_psc. Currently that is i=[1:6 8 9 13 15 21]. Of course, since test_octave_psc is already a dependency of the test_noninteractive target, adding such examples should be done with some caution. Alan Not sure I follow everything here, but here's what I've done. Every build runs: ctest -V -E 'compare|qt' and that completed fine. In the installed packages I see plplot-test.sh claims to have an --interactive_octave option, but: [root@vmf17 examples]# ./plplot-test.sh --interactive_octave Never heard of an interactive device called psc. Either this is not a legitimate interactive device for PLplot or else plplot-test.sh.cmake needs some maintenance to include this interactive device in the list of possible PLplot interactive devices. - Orion -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] octave 3.6.0 issues
On 01/28/2012 12:27 PM, Andrew Ross wrote: On Sat, Jan 28, 2012 at 08:02:17AM -0700, Orion Poplawski wrote: On 01/28/2012 01:04 AM, Andrew Ross wrote: Orion - the changes were committed to svn last week. Have you tried since then? If so and it still fails, can you provide details? Sorry, forgot to check. But split is still used in test_octave.sh.in and test_octave_interactive.sh.in. Orion, No problem. Thanks for spotting the test scripts. I'd overlooked that one. Now fixed as well. Andrew Finally was able to build (due to other Fedora issues). All looks good now. Thanks. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] octave 3.6.0 issues
On 01/16/2012 06:25 PM, Alan W. Irwin wrote: On 2012-01-16 14:46-0700 Orion Poplawski wrote: - split has now be removed from octave in favor of strsplit: 6: error: `split' undefined near line 3 column 5 I believe this has been raised before but was decided to stay with split at the time for octave 3.0 support. Thanks for bringing this up, Orion. The rest of this is primarily to Andrew. Hi Andrew: Out of curiosity I looked up that discussion, and the 2010-07-26 conclusion by you was strsplit was only introduced in octave3.2 so I do not (yet) want to switch to it. Octave 3.0 is still widely used. Everything else in plplot just requires 3.0. Of course, now is almost a year and a half later, and I therefore think now would be a good time (especially since split is causing obvious problems for the most recent octave release) for you to replace split with strsplit and mention in the release notes that the minimum version of octave we now support is 3.2. From what Orion says, EPEL (Extra Packages for Enterprise Linux) users apparently only have access to Octave 3.0, and I assume that most enterprise distros also have similar Octave version constraints. But I don't think we have to be too concerned about such cases since older PLplot versions should satisfy most enterprise needs. Furthermore, with regard to modern (i.e., non-enterprise) distros, probably Debian stable is the oldest of those, and it installs Octave 3.2.4-8 where split was already deprecated in favour of strsplit. Could this get addressed soon? plplot currently cannot be rebuilt for octave 3.6.0 in Fedora rawhide. Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] octave 3.6.0 issues
Two issues arose trying to build plplot with octave 3.6.0: - octave needs to be passed --no-window-system if DISPLAY is not set, which I need to due when building the fedora package. The attached patch allows me to set the $otaveopts variable to do this. - split has now be removed from octave in favor of strsplit: 6: error: `split' undefined near line 3 column 5 I believe this has been raised before but was decided to stay with split at the time for octave 3.0 support. Octave 3.0 is still in EPEL 5, though no idea who is using that, and in our case we won't be building a newer plplot in EPEL 5 anyway. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com diff -up plplot-5.9.9/plplot_test/test_octave.sh.in.octave plplot-5.9.9/plplot_test/test_octave.sh.in --- plplot-5.9.9/plplot_test/test_octave.sh.in.octave 2011-10-12 18:43:01.0 -0600 +++ plplot-5.9.9/plplot_test/test_octave.sh.in 2012-01-16 08:29:46.551852247 -0700 @@ -35,7 +35,7 @@ echo $TOPDIR export LD_LIBRARY_PATH=$TOPDIR/src:$TOPDIR/lib/csa:$TOPDIR/lib/nn # Launch an Octave script that exercises all the demos -$octave -f -q -p $octavedir EOF 2 test.error +$octave -f -q $octaveopts -p $octavedir EOF 2 test.error # Check verbose_test variable if (strcmp(getenv(verbose_test),on) == 1) -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Unnecessary library linkage
On 01/04/2012 07:30 PM, Alan W. Irwin wrote: On 2012-01-04 14:02-0700 Orion Poplawski wrote: Hmm, examples build okay now, but I still have the rpaths. Hi Orion: Just to review, rpath should be set for all languages and all examples, libraries, and dlls in the build tree regardless of the value of USE_RPATH. In contrast rpath should be/not be set for all languages and all examples, libraries, and dlls in the install tree depending on whether the cmake option USE_RPATH is set to ON or OFF. That option is usally left at the default value (ON) but package maintainers normally use -DUSE_RPATH=OFF to leave rpath unset for the install tree. It appeared from your original e-mail that rpath was being set for two of the ocaml components in the install tree (dllplplot_stubs.so and dllplplott_stubs.so). Also, I am virtually positive you are using -DUSE_RPATH=OFF, but will you confirm that? If so, then obviously there is an rpath problem here, but it will be quite a while until I can deal with such an issue because I have exhausted the simple possibilities, and I am tied up with three other time-consuming projects at the moment. The rpaths are present in the install tree. I am setting USE_RPATH=OFF. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Unnecessary library linkage
On 01/05/2012 06:02 AM, Andrew Ross wrote: On Wed, Jan 04, 2012 at 10:29:02AM -0800, Alan Irwin wrote: Hi Orion: Sorry your previous post fell through the cracks. I think Andrew is the best guy to evaluate your patch so I won't comment on that, but I will respond to two of your questions not involving the patch. Orion, I've applied your post. I'm a bit worried about the AGG part. It seems to me that this is only available as a static library, so your patch should be ok. I do wonder why though? Also a lot of the wxwidgets AGG code is commented out as it doesn't work. Finally the last release of AGG was 2006 so it hardly looks like it is a well used and supported library. Does anyone actually use these features? Andrew On fedora, agg is a shared library. There are a couple other projects in Fedora that use agg, the most surprising of which is gnash. I have no idea about the usefulness of agg in plplot. I enable it because it is there. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] java example segfault
On 01/05/2012 05:01 AM, Andrew Ross wrote: Orion, There have been intermittent crashes with some java compilers / jre and not with others. These have been hard to pin down since debugging the java / native code is not easy. I have not had trouble with openjdk (in fact it has been my compiler of choice for this reason). I have been using openjdk-6 though. I tried openjdk-7 on debian unstable and I could not reproduce your crash. This does not necessarily mean anything though as these things can be a little random. Is the crash reproducible for you? I've taken a look at the swig code for this and I think there is an issue with referencing a variable which is out of scope. This might or might not work depending on the compiler and what else is going on. The latest svn takes an alternative approach which should fix this. This fix works for me, but so did the old code. Can you test and see if this makes any difference? Nice catch! That fixed it for me. It was completely reproducible before. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] gnat 4.7
Fedora rawhide has updated to gcc 4.7, so here is my updated gnat patch. There really has to be a better way for this. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com diff -up plplot-5.9.9/cmake/modules/ada.cmake.gnat plplot-5.9.9/cmake/modules/ada.cmake --- plplot-5.9.9/cmake/modules/ada.cmake.gnat 2011-10-12 18:43:01.0 -0600 +++ plplot-5.9.9/cmake/modules/ada.cmake 2012-01-04 08:58:11.501470982 -0700 @@ -43,7 +43,7 @@ if(ENABLE_ada) endif(ENABLE_ada) if(ENABLE_ada) - find_library(GNAT_LIB NAMES gnat gnat-4.5 gnat-4.4 gnat-4.3 gnat-4.2 gnat-4.1) + find_library(GNAT_LIB NAMES gnat gnat-4.7 gnat-4.6 gnat-4.5 gnat-4.4 gnat-4.3 gnat-4.2 gnat-4.1) if(NOT GNAT_LIB) message(STATUS WARNING: gnat library not found. Disabling ada bindings) -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
