[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 970925: Problem with Purify & netcdf C++

>To: address@hidden
>From: address@hidden (Gary Horton)
>Subject: Problem with Purify
>Organization: .
>Keywords: 199709251911.NAA01122

Hi Gary,

>  Congratulations on a nicely working C++ interface to netCDF. I was able
> to spin up on it and produce a working module on very short order. One
> of my "wrap-up" steps in new modules involves using a product called 
> "Purify", an object-linker that checks for memory leaks, bounds violations,
> etc. Perhaps you've heard of it or certainly of products like it. In 
> either event, in attempting to link my code (which of course uses 
> libnetcdf_c++.a), I use this statement:
> 
> empcc -c_compiler /opt/pure/purify-3.2/purify -usemalloc -noshlib gcc 
> ../obj/airs.o ../obj/view_windows.o ../obj/project.o  ../obj/GUI-motif.o 
> ../obj/query.o ../obj/dbio.o ../obj/forms.o -L /home/local/dev/airs/motif/obj 
> -L /home/local/dev/airs/empress/obj -L/opt/gnu/lib  
> -L/home/local/dev/airs/util/obj -L /home/local/dev/airs/empress/obj -lg++ 
> -lempress -lmotif -lutil -lempress -lraf -lnetcdf_c++ -lnetcdf -lXm -lXt 
> -lX11 -lm -o ../bin/airs.pure
> 
> ...where empcc is a precompiler for Empress database libraries, and purify is
> the bounds-checking linker. I give you this link stmt in hopes it may shed 
> some
> light on the problem: numerous "Undefined symbols", all "first referenced in
> file ncvalues.o". The symbols in question:
> 
> __13strstreambaseiPcii
> _vt.7ostream.3ios
> __ls__7ostreamPCc
> ends__FR7ostream
> _vt.10ostrstream.3ios
> __ls__7ostreamc    
> __ls__7ostreamd
> __ls__7ostreami
> _vt.3ios
> 
> Does any of this ring a bell, or does the ordering in my link statement
> tell you something? Thanks in advance for any help,

I think this may be a libg++ problem; it doesn't look like a netCDF
problem.

We've been using Purify for a couple of years, and in fact you will see
the target "nctst.pure" is in the netcdf/cxx/Makefile for building a
Purify test.  I just made this and ran the result on a SunOS 5.5.1/sparc
Ultra-2 platform:

 $ make nctst.pure
 ...
 CC -o nctst -I../libsrc  -DNDEBUG -O  nctst.o libnetcdf_c++.a -L../libsrc 
-lnetcdf 
 purify CC  -I../libsrc  -DNDEBUG  nctst.o libnetcdf_c++.a -L../libsrc -lnetcdf 
 -o nctst.pure
 Purify 4.0.1 Solaris 2, Copyright (C) 1992-1996 Pure Atria Corp. All rights 
reserved. 
 Instrumenting: nctst.o libnetcdf_c++.a..  Linking

 $ ./nctst.pure

    Finished  nctst.pure           (   0 errors,    0 leaked bytes)
      Purify instrumented ./nctst.pure (pid 13334 at Thu Sep 25 13:22:44 1997)
      Current file descriptors in use: 12
      Memory leaked: 0 bytes (0%); potentially leaked: 0 bytes (0%)
      Program exited with status code 0.

So at least on our somewhat skimpy C++ interface test, things look OK.

Please let me know if you don't get the same problem using other I/O
programs with g++/libg++ and Purify.  I could try that combination here,
but I'm not sure we have a current version of libg++ installed, and I
don't know for sure whether Purify is designed to work with libg++.

--Russ