This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>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