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

Mark Borges: Re: netCDF-3 compatability issues

Steve,

I'm forwarding this, because we may want to use it for future reference
in dealing with such compatibility questions.

--Russ

------- Forwarded Message

Date:    01 Aug 1997 17:03:33 -0600
From:    Mark Borges <address@hidden>
To:      Russ Rew <address@hidden>
Subject: Re: netCDF-3 compatability issues

>> On Fri, 01 Aug 1997 14:31:01 -0600,
>> Russ Rew(RR) wrote:

RR> Precompiled code would continue to work if it was statically
RR> linked to the old libraries.

Yes. The evils of dynamically shared libs.

RR> fails in a couple of minor places.  The same test on the FORTRAN
RR> interface (linking the fortran/ftest.o file against the netCDF
RR> 3.3.x library) fails in more places, in particular in creating new
RR> files with NCCRE).

Yes, that's consistent with what we found

>> One thought I had -- many of the existing apps use the shared version
>> of the library, libnetcdf.so, which (rightly or wrongly) has also been 
>> placed in /usr/lib/libnetcdf.so. So, I think I could leave the old
>> v2.4 lib in there, and direct new compiles to link in the new v3.3.1
>> library in /usr/local/lib/libnetcdf.so (via -L and -R switches in
>> Solaris). 

RR> Yes, that *should* work.  Please let us know if it doesn't.

It appears to be working as advertised. To make it a bit more
transparent, we've set LD_RUN_PATH in global shell startup
files. Under Solaris-2.5, LD_RUN_PATH effectively provides a default
`-R' switch, so users don't have to change their normal compilation
procedure to rebuild new applications. As a side effect, we can tell
by the output of ldd which app is using the old library and which is
linking the v3.3 libs.

Thanks.


  (1) Have /usr/lib/libnetcdf.so point to the old v2.4 shared
      library, so that existing precompiled binaries continue to
      work. This is currently true because there are some people,
      e.g., Wes Berg, that I cannot get ahold of and who may be
      running cron jobs that create netcdf files. For wes, at least, I
      think this is a distinct possibility, and some of his raw source
      data is transient.

  (2) Define LD_RUN_PATH=/usr/local/lib in the global shell script
      startup files (//etc//.cshrc, /etc/profile, ...). This would
      insure that future builds would pick up the current v3.3.1
      netcdf libs and libnetopen.a that are consistent with the
      currently installed include files. Users would *not* have to
      change their existing makefiles for this to work.

  (3) Of course, users who never log out would not pick up this
      change, so an announcement will still be necessary, I think. Or
      perhaps a nightly reboot of all the interactive machines? ;-).

  (4) The remaining loophole that I see is for users who explicitly
      provide the `-R' switch in their makefile. But, presumably,
      these users know what they're are doing and are overriding the
      default intentionally to something other than the default (i.e.,
      using `-R/usr/lib' would lead to lossage, but other uses would
      be OK).

Under this strategy, eventually all the old existing apps requiring
the v2.4 libs will be converted over to v3.3 as they are rebuilt at
the users discretion. At some future time we could remove the
/usr/lib/libnetcdf.so link after (relatively) quickly identifying
those apps still choosing the /usr/lib/libnetcdf.so.

------- End of Forwarded Message