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

Re: 20030721:netCDF C - RedHat Linux 9.0 _ctype_b error fix/workaround for RedH (fwd)

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