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.
Tim, > Could the multiple forks that make can split into cause > a race condition, such that the installation of the new netcdf library is > beaten > by the attempt to link to it? > > I notice my make has make[1], make[2], and make[3], which I'm guessing from > hazy > memory might be forks. I think those are just recursive levels of make, when the top level make (make[1]) invokes make for subdirectories (make[2]), etc. If I just "make all" for netcdf, I never get more than two levels. If the netCDF make is invoked recursively from inside the EPIC Makefile, that would add one more level. I don't think you get parallel make by default with the gnu make on Linux, but I could be wrong. --Russ ------- Forwarded Message Date: Tue, 22 Jul 2003 11:23:26 -0400 From: "Timothy E. Dowling" <address@hidden> To: Russ Rew <address@hidden> cc: address@hidden Subject: Re: 20030721:netCDF C - RedHat Linux 9.0 _ctype_b error fix/workaround for RedHat 9 Russ, Could the multiple forks that make can split into cause a race condition, such that the installation of the new netcdf library is beaten by the attempt to link to it? I notice my make has make[1], make[2], and make[3], which I'm guessing from hazy memory might be forks. My EPIC make structure is using the same sequence I described as "by hand" below, which causes me to think it might be some kind of a race condition. Alternatively, I am just erroneously linking before the installation for some other reason. Still looking. Tim > Russ, > > I have a partial understanding of this __ctype_b error. It has > to do with properly installing the new libnetcdf.a into netcdf/lib > before linking to it. > > My context is the EPIC atmospheric model, which makes netcdf first as > part of its build. I just discovered I get different behavior > depending on what is residing in $EPIC_PATH/netcdf/lib. > > A. If I first copy an old, pre Red Hat 9 libnetcdf.a into > $EPIC_PATH/netcdf/lib, then > a from-scratch EPIC-model make generates the error > > /home/dowling/epic/netcdf/lib/libnetcdf.a(string.o)(.text+0x37): In > function `NC_check_name': > : undefined reference to `__ctype_b' > > which is the original problem. > > B. If I first 'rm $EPIC_PATH/netcdf/lib/*' then a from-scratch EPIC-model > make generates the error > > /usr/bin/ld: cannot find -lnetcdf > > I notice that netcdf's 'make distclean' does not empty the > contents of netcdf/lib. I think this may be a contributing factor > to the obscurity of the problem, because > the __ctype_b error would be a different error if netcdf/lib got emptied > by 'make distclean,' potentially one that is less of a red herring. > For me, it would have been the 'cannot find -lnetcdf' error above. > > C. If I create a fresh netcdf/lib/libnetcdf.a by doing the following > sequence by hand > > cd $EPIC_PATH/netcdf/src (which is > /home/dowling/epic/netcdf/netcdf-3.5.0/src) > make distclean > configure > make install > > which is the sequence I thought the EPIC make was doing, > followed by a from-scratch EPIC make, I get no errors, and a new > libnetcdf.a > is installed into netcdf/lib, newer than the one I just made by hand. > > So, it seems my EPIC makefile is linking to the netcdf library > in netcdf/lib before the new one is installed. I'm not sure why yet, but > I'll send you this email and then try to figure it out. > > Sincerely, > > Tim Dowling > > > > -- Prof. Timothy E. Dowling, Director office: (502) 852-3927 Comparative Planetology Laboratory fax: (502) 852-6053 200 Sackett Hall email: address@hidden University of Louisville URL: www.louisville.edu/research/cpl Louisville, KY 40292 ------- End of Forwarded Message