On 2009-04-24 23:00-0500 Geoffrey Furnish wrote:
> So, thanks to all for the help today.
>
> This note is to summarize what I have learned about the fabled Tk segfault.
>
> When I finally managed to find a way to exhibit the problem under gdb, I
> found that the program was inside a pthread op. T
On 2009-04-24 21:40-0500 Geoffrey Furnish wrote:
> Andrew Ross writes:
> > On Fri, Apr 24, 2009 at 02:54:43PM -0500, Geoffrey Furnish wrote:
> > > Werner Smekal writes:
> > > > I usually debug in the build tree. Add the "-DBUILD_TEST=ON" to the
> > > > cmake options and all examples will be comp
So, thanks to all for the help today.
This note is to summarize what I have learned about the fabled Tk segfault.
When I finally managed to find a way to exhibit the problem under gdb, I
found that the program was inside a pthread op. That was at a different
computer than where I am now. As I r
Alan W. Irwin writes:
> When running into a component problem like this where you are not interested
> in the component (and also for speed) just disable the componenent, e.g.,
> -DENABLE_f95=OFF
I did, and kept going.
> Thanks for that fortran 95 error report.
>
> However, I don't think w
Andrew Ross writes:
> On Fri, Apr 24, 2009 at 02:54:43PM -0500, Geoffrey Furnish wrote:
> > Werner Smekal writes:
> > > I usually debug in the build tree. Add the "-DBUILD_TEST=ON" to the
> > > cmake options and all examples will be compiled in the built tree.
> >
> > Well, I must be mis
Werner Smekal writes:
> Geoffrey Furnish wrote:
> > Werner Smekal writes:
> > > make VERBOSE=1
> >
> > I found a cmake var for this too.
> >
> true, but then you've always verbose output. Using VERBOSE=1 for the
> make command only prints out verbose information when you want without
On 2009-04-24 22:00+0100 Andrew Ross wrote:
>> Andrew, that change should be reverted. I tried the same thing here until I
>> realized exit is very different from call exit(status).
>
> Done. Actually a large part of my change was converting calls to exit to
> setting
> the error flag and return
On Fri, Apr 24, 2009 at 01:49:25PM -0700, Alan Irwin wrote:
> On 2009-04-24 20:58+0100 Andrew Ross wrote:
>
> > On Fri, Apr 24, 2009 at 02:36:16PM -0500, Geoffrey Furnish wrote:
> > Content-Description: message body text
> >> Werner Smekal writes:
> >> > make VERBOSE=1
> >>
> >> I found a cmake va
On 2009-04-24 20:58+0100 Andrew Ross wrote:
> On Fri, Apr 24, 2009 at 02:36:16PM -0500, Geoffrey Furnish wrote:
> Content-Description: message body text
>> Werner Smekal writes:
>> > make VERBOSE=1
>>
>> I found a cmake var for this too.
>>
>> >> Well, I go to the installed examples dir, and run x
On 2009-04-24 14:36-0500 Geoffrey Furnish wrote:
> Werner Smekal writes:
> > make VERBOSE=1
>
> I found a cmake var for this too.
>
> > > Well, I go to the installed examples dir, and run xtk01 under gdb, and it
> > > tells me there is no debugging info available.
> > >
> > I usually debug in the
On Fri, Apr 24, 2009 at 02:54:43PM -0500, Geoffrey Furnish wrote:
> Werner Smekal writes:
> > I usually debug in the build tree. Add the "-DBUILD_TEST=ON" to the
> > cmake options and all examples will be compiled in the built tree.
>
> Well, I must be missing something. When I add this, I do
On Fri, Apr 24, 2009 at 02:36:16PM -0500, Geoffrey Furnish wrote:
Content-Description: message body text
> Werner Smekal writes:
> > make VERBOSE=1
>
> I found a cmake var for this too.
>
> > > Well, I go to the installed examples dir, and run xtk01 under gdb, and it
> > > tells me there is no
Werner Smekal writes:
> I usually debug in the build tree. Add the "-DBUILD_TEST=ON" to the
> cmake options and all examples will be compiled in the built tree.
Well, I must be missing something. When I add this, I don't find the tk
examples in the build tree. There is an examples/tk directo
Hi Geoffrey,
Geoffrey Furnish wrote:
> Werner Smekal writes:
> > make VERBOSE=1
>
> I found a cmake var for this too.
>
true, but then you've always verbose output. Using VERBOSE=1 for the
make command only prints out verbose information when you want without
reconfiguring.
> > > Well, I go
Hi Geoffrey,
> I do have another question: How do I accomplish what we might call a "debug
> build" ?
>
cmake -DCMAKE_BUILD_TYPE=Debug ...
In case you don't know:
http://www.cmake.org/Wiki/CMake_Useful_Variables#Compilers_and_Tools
Regards,
Werner
> I want all compilation units compile
Geoffrey Furnish writes:
> I do have another question: How do I accomplish what we might call a "debug
> build" ?
>
> I want all compilation units compiled with -g, and linked appropriately to
> allow running under the debugger. Is there a simple way to pull that off?
Well, sorry. I just
Hi Geoffrey,
> Well, sorry. I just found the needed trick in the wiki. So I redid the
> cmake (from a completely empty dir :-) with CMAKE_BUILD_TYPE=Debug. This did
> result in a line in the cmake output reflecting that it is a debug build.
> However, I can't see how the files were actually comp
On 2009-04-24 13:59-0500 Geoffrey Furnish wrote:
> I do have another question: How do I accomplish what we might call a "debug
> build" ?
>
> I want all compilation units compiled with -g, and linked appropriately to
> allow running under the debugger. Is there a simple way to pull that off?
Ye
Hi Vadim,
> Sorry for not thinking to check the latest svn, I did update to r9840 and
> most of the warnings are indeed gone. The remaining ones are
>
Yes, I also found the numerous warnings of VC++ 2005/2008 annoying so I
"fixed" them. Except the warnings below, since the qsastime library
wa
On 2009-04-24 01:13-0700 Alan W. Irwin wrote:
> As outlined above, addressing the library tag issue for the enhancement
> libraries is straightforward but needs care since it touches quite a few
> files. If somebody else wants to deal with this issue before this release,
> I would prefer it be do
Andrew Ross writes:
> Just one thought. I use CMAKE_INSTALL_PREFIX all the time and it has
> always just worked for me. Are you sure you are working in a completely
> clean build tree? Resetting CMAKE_INSTALL_PREFIX in an old tree does not
> automatically update all the other CMAKE_INSTALL_xxx
On 2009-04-24 09:35+0200 Werner Smekal wrote:
> Hi Alan,
>>
>> My tests indicate the normal qt devices and this important additional
>> ability to access the PLPlot API from Qt applications are now in good shape
>> for our early May release. However, it's a good idea to broaden the tests
>> to a
On Fri, Apr 24, 2009 at 12:58:53PM -0500, Geoffrey Furnish wrote:
> Hi guys,
>
> I'm having some problems building. Trying not to look too stupid here...
>
> I've built Tcl and Tk and installed them to $HOME/plplot/t4/install. Then I
> configure plplot thusly:
>
> % cmake -DCMAKE_INSTALL_PREFI
Woops, one part badly worded, correction below.
Geoffrey Furnish writes:
> BTW #2: It doesn't seem to me like you should have to set
> CMAKE_LIBRARY_PATH if you want something other than
xx "unless"
> CMAKE_INSTALL_PREFIX/lib. Why isn't CMAKE_INSTALL_PREFIX/lib the def
Hi guys,
I'm having some problems building. Trying not to look too stupid here...
I've built Tcl and Tk and installed them to $HOME/plplot/t4/install. Then I
configure plplot thusly:
% cmake -DCMAKE_INSTALL_PREFIX=$HOME/plplot/t4/install
-DCMAKE_LIBRARY_PATH=$HOME/plplot/t4/install/lib -DENA
On Fri, Apr 24, 2009 at 02:29:33AM +0200, Vadim Zeitlin wrote:
> On Thu, 23 Apr 2009 19:18:56 +0100 Andrew Ross
> wrote:
>
> AR> Thanks for your bug report. Are you using plplot 5.9.2? Most of these
> AR> warnings have already been fixed in the latest svn version of plplot.
> AR> Could you try
On 2009-04-24 16:40, Vadim Zeitlin wrote:
> On Fri, 24 Apr 2009 02:29:33 +0200 I wrote:
>
> VZ> src\ltdl_win32.c(67) : warning C4133: 'function' : incompatible types -
> from 'char *' to 'LPCWSTR'
>
> Sorry for yet another false alert, this was due to a local modification to
> CMakeLists.txt
On Fri, 24 Apr 2009 02:29:33 +0200 I wrote:
VZ> src\ltdl_win32.c(67) : warning C4133: 'function' : incompatible types -
from 'char *' to 'LPCWSTR'
Sorry for yet another false alert, this was due to a local modification to
CMakeLists.txt and not a PLplot problem at all. To summarize, the current
On Fri, 24 Apr 2009 00:16:05 -0700 (PDT) "Alan W. Irwin"
wrote:
AWI> Thanks for your LIB_TAG bug report which was caused by some of our
AWI> visibility logic assuming LIB_TAG was always "d". I have now fixed that
bug
AWI> (revision 9843). Please try out that revision to make sure it works for
Werner Smekal wrote:
> Mac OS X
>
>
> * I installed the latest Qt SDK 4.5.1 and added the instructions to
> the wiki (http://www.miscdebris.net/plplot_wiki/index.php?title=Qt).
> * Everything compiles without troubles.
> * If I run an example (qtwidget) with one plot a window pops up wh
On 2009-04-24 09:32+0200 Werner Smekal wrote:
>>>
>>> I would prefer the following logic instead:
>>>
>>> if(PL_DOUBLE AND NOT DEFINED LIB_TAG)
>>> set(LIB_TAG "d")
>>> endif(PL_DOUBLE AND NOT DEFINED LIB_TAG)
>>>
>>> In other words, if somebody specifies a library name suffix on the command
>>
On Fri, Apr 24, 2009 at 12:16:05AM -0700, Alan Irwin wrote:
>
> I would prefer the following logic instead:
>
> if(PL_DOUBLE AND NOT DEFINED LIB_TAG)
> set(LIB_TAG "d")
> endif(PL_DOUBLE AND NOT DEFINED LIB_TAG)
>
> In other words, if somebody specifies a library name suffix on the command
> line
Hi Alan,
one more thought:
>
> I would prefer the following logic instead:
>
> if(PL_DOUBLE AND NOT DEFINED LIB_TAG)
> set(LIB_TAG "d")
> endif(PL_DOUBLE AND NOT DEFINED LIB_TAG)
>
> In other words, if somebody specifies a library name suffix on the
> command
> line including the null string, l
Hi Alan,
>
> My tests indicate the normal qt devices and this important additional
> ability to access the PLPlot API from Qt applications are now in
> good shape
> for our early May release. However, it's a good idea to broaden the
> tests
> to additional platforms and configurations so I ask
>>
>> I would prefer the following logic instead:
>>
>> if(PL_DOUBLE AND NOT DEFINED LIB_TAG)
>> set(LIB_TAG "d")
>> endif(PL_DOUBLE AND NOT DEFINED LIB_TAG)
>>
>> In other words, if somebody specifies a library name suffix on the
>> command
>> line including the null string, let us assume they
On 2009-04-24 09:16, Alan W. Irwin wrote:
> Hi Vadim:
>
> Thanks for your LIB_TAG bug report which was caused by some of our
> visibility logic assuming LIB_TAG was always "d". I have now fixed that
> bug
> (revision 9843). Please try out that revision to make sure it works for
> you
> (with a
Hi Vadim:
Thanks for your LIB_TAG bug report which was caused by some of our
visibility logic assuming LIB_TAG was always "d". I have now fixed that bug
(revision 9843). Please try out that revision to make sure it works for you
(with an additional suffix of "d", see below).
A question for all
37 matches
Mail list logo
