Bug#725957: Bug#751718: RFP: Python GDL module - Python / GNU Data Language bridge
Hi Axel, On 04/07/14 00:13, Axel Beckert wrote: Sylwester Arabas wrote: Could you please try if using CMake gives the same linking error? Is it expected that to build it with CMake, I also need libncurses-dev and libeigen3-dev as build-dependencies despite I don't seem to need them when building with autotools? The autotools build was de-facto obsoleted and not maintained since some time, so I believe this is simply a wont-fix bug in the cofigure.in in GDL (which will be shipped in "obsolete" subdirectory with the upcoming release). Sorry, you misunderstood me (or I misunderstand you :-): CMake wants additional packages to be installed despite it builds fine without when using autotools, at least on Linux x86 architectures. So my question is not about the autotools variant, but about the CMake variant: Why does using CMake request additional build-dependencies? Is this on purpose (i.e. different stuff enabled by default) or is this unexpected. I'm sorry - of course I misunderstood it. You are right: - configure enables Eigen if found, otherwise not - CMake requires it to be explicitly disabled to be skipped Enabling Eigen support is highly recommended! I'm pretty sure ncurses were a build-dependency of GDL for a long time, and a quick look into the configure.in/CMakeLists.txt does not really give me a hint why this behavior changed? HTH, thanks! Sylwester -- http://www.igf.fuw.edu.pl/~slayoo/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725957: Bug#751718: RFP: Python GDL module - Python / GNU Data Language bridge
Axel, Thanks a lot for revisiting the GDL package. On 30/06/14 00:22, Axel Beckert wrote: Axel Beckert wrote: Sylwester Arabas wrote: Could you please try if using CMake gives the same linking error? Is it expected that to build it with CMake, I also need libncurses-dev and libeigen3-dev as build-dependencies despite I don't seem to need them when building with autotools? The autotools build was de-facto obsoleted and not maintained since some time, so I believe this is simply a wont-fix bug in the cofigure.in in GDL (which will be shipped in "obsolete" subdirectory with the upcoming release). Best, Sylwester -- http://www.igf.fuw.edu.pl/~slayoo/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725957: Bug#751718: RFP: Python GDL module - Python / GNU Data Language bridge
Hi Axel, Thanks for your reply. On 27/06/14 17:07, Axel Beckert wrote: (I'm also not 100% sure if the problem is inside GDL - it's a linking issue that appears on two out of >10 arch only, the error messages point to code that was present in the previous version). Do you know anyone using Debian with kfreebsd or powerpc that we could ask to look into it? Basically any Debian developer has access to machines of any architectures. I do have kfreebsd-i386 at home (with GDL installed btw.) and a powerpc machine, too, but that one's currently offline (needs a new harddisk), so I'd use one of Debian's official porterboxes there. Could you please try if using CMake gives the same linking error? The GDL configure script has some linking options hardcoded in it which are probably chosen in a more OS-aware way when using CMake. The autotools-based build will be removed from GDL in the next release, so this is anyhow worth trying. Thanks, Sylwester -- http://www.igf.fuw.edu.pl/~slayoo/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#660260: Fwd: GDL seems to use non public symbols from plplot (Debian Wheezy freeze on Saturday)
Hi Axel, On 28/06/12 12:19, Axel Beckert wrote: > ... /home/abe/gnudatalanguage/gnudatalanguage/src/plotting_xyouts.cpp:260: undefined reference to `plP_mmpcy' /home/abe/gnudatalanguage/gnudatalanguage/src/plotting_xyouts.cpp:332: undefined reference to `plstrl' /home/abe/gnudatalanguage/gnudatalanguage/src/plotting_xyouts.cpp:345: undefined reference to `plP_mmpcx' /home/abe/gnudatalanguage/gnudatalanguage/src/plotting_xyouts.cpp:292: undefined reference to `plstrl' collect2: error: ld returned 1 exit status ... are the above critical for this week? Well, it's way easier to get it into Wheezy if I upload the package before the Freeze on Saturday evening. I can try to get it in later, but I can't promise it, I'm sorry. If more time helps to get the thing fixed for sure, I can ask the release team in advance for a freeze exception. But again no promises. I've just asked on plplot mailing list about it: https://sourceforge.net/projects/plplot/forums/forum/132889/topic/5389011 Both plstrl and plP_mmpcx are used in GDL to handle the WIDTH keyword to the XYOUTS procedure. That's surely not a vital feature of GDL so perhaps you can simply comment it out from the GDL source code for Debian packaging while waiting for a proper solution. Such patch would basically undo this commit: http://gnudatalanguage.cvs.sf.net/viewvc/gnudatalanguage/gdl/src/plotting.cpp?hideattic=0&r1=1.127&r2=1.128 HTH, Sylwester -- http://www.igf.fuw.edu.pl/~slayoo/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#660260: Fwd: GDL seems to use non public symbols from plplot (Debian Wheezy freeze on Saturday)
Hi All, On 27/06/12 18:59, Sylwester Arabas wrote: Here's a fix suggested by Joel: On 05/06/12 14:09, gal...@cox.net wrote: > I would suggest replacing: > > lib::mesh_nr(xVec1, yVec1, z1, (long int) xEl, 1,1); > > in plotting.cpp by > > plmesh(xVec1, yVec1, z1, (long int) xEl, 1,1); > > I think the plplot library now has the functionality that was > missing before. > > If we remove the call to mesh_nr then we no longer have to include > plot3d_nr.cpp which was causing the problem. I'll try to test it and commit to the repository today or tomorrow. That's now in the CVS. Please test if it fixes the issue. Best, Sylwester -- http://www.igf.fuw.edu.pl/~slayoo/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#660260: Fwd: GDL seems to use non public symbols from plplot (Debian Wheezy freeze on Saturday)
Hi Axel, CC: Joel, Alain, Marc, Debian bug-tracker On 27/06/12 18:07, Axel Beckert wrote: ... http://sourceforge.net/tracker/?func=detail&aid=3529264&group_id=97659&atid=618683 GDL unfortunately will not be part of the next Debian stable release if this can't be fixed soon. Here's a fix suggested by Joel: On 05/06/12 14:09, gal...@cox.net wrote: > I would suggest replacing: > > lib::mesh_nr(xVec1, yVec1, z1, (long int) xEl, 1,1); > > in plotting.cpp by > > plmesh(xVec1, yVec1, z1, (long int) xEl, 1,1); > > I think the plplot library now has the functionality that was > missing before. > > If we remove the call to mesh_nr then we no longer have to include > plot3d_nr.cpp which was causing the problem. I'll try to test it and commit to the repository today or tomorrow. Sorry for the delay and big thanks for the reminders! Best, Sylwester -- http://www.igf.fuw.edu.pl/~slayoo/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
