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.
> Hi Ed, > > Success! That definitely fixed it. I just did a successful full build of the whole thing but not with shared libraries. I didn't install yet, though. I thought > I might ask your advice. Originally, I did this because I wanted to be able to run a simulation code that used netCDF for its dump files, and the static > libraries should suffice for that. But it's a pretty nice package so I'll probably use it for many things and as a way of saving simulation data myself. Great. There are lots of visualization tools available as well. > > So what's your advice on the shared libraries? Should I go back to configuer and have it make the DLLs, as well? What would be the advantage of that? Nope, just go with what you've got. You will never notice the difference. Here's a FAQ that explains about shared libraries: http://www.unidata.ucar.edu/software/netcdf/docs/faq.html#shared_intro > Perhaps the ability to use other tools you guys have? I'll also install the full documentation. > > I keep feeling like I need to appologize. I had forgotten that my environment had gotten a little messed up. When I first installed Cygwin, I ran into these > problems that occur when you install Cygwin on Vista. I was doing this on my own and it ended up taking a week or a little longer to get it to work right > because of these weird issues with having to run "rebaseall" and x-windows complaining about /tmp/.X11-unix not having being owned by root (XWin.exe > automatically sets the "sticky" bit so xterm doesn't think it can update the window handle, but that's only when it hasn't been rebased). So I spent a lot > of time experimenting and searching the Cygwin mailing list archives to find different peoples' responses to the same and similar problems. In the > process, I edited the default profile that I had copied into /etc (a no-no) and accidentally lost where it appended the binary directories to the PATH. > Ultimately, I ended up compensating, for the most part, by getting those directories in my Windows $Path variable, following somebody's stupid answer > for some related problem they had encountered from the mailing list. > > So tonight, I restored the default profile (which automatically gets updated when you update Cygwin) to /etc, added the library paths to $PATH (which is > where you have to put them in Cygwin) using my local .bashrc file and got rid of any Cygwin directories in my Windows $Path. This is a whole lot saner > and I expect a few other things will work better now. And now the /usr/bin directory automatically comes before Windows when you're running Cygwin so > it netCDF built with no problems. > > Still, I think this may provide you with some useful information for your support work. You now know that, at least on the newer distributions, you > MUST have /usr/bin before the Windows system directory to even build the netCDF libraries. It's not just a matter of linking fortran code to the library. > If you don't have the Cygwin binary paths first, libtool will choke on and give the error I saw because it uses uses the DOS "sort" command in it's error > handling when its trying to use the unix "sort". If people haven't messed up their Cygwin paths the way I did, this shouldn't occur. But it's pretty easy to > mess up, given that the Cygwin folks haven't automated or very well-documented yet what you have to do to get Cygwin's X-windows to work on Vista. > > Bye, > -Mike I'm glad it all worked out in the end! Ed Ticket Details =================== Ticket ID: MPL-618419 Department: Support netCDF Priority: High Status: Closed