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.
> >> # Correct the global symbol > >> vi v2i.c > >> # Change const char *cdf_routine_name; to const char *cdf_routine_name = > >> ""; > > > >Can you tell me why you had to do this? Why is this more correct? > > Ignore, I'm using the -fno_common to fix this. The issue arises from: > > Common symbols > If you get errors in linking complaining about common symbols: > ld: common symbols not allowed with MH_DYLIB output format > mac-binaries/fred.o definition of common ArrayError (size 4) > Then it means that you've got a global variable in the library which > has not been assigned a value. E.g. in this case if fred.c has "int > ArrayError;" then change it to "int ArrayError = 0;" to remove this > problem. > Turns out none of this was actually being used anyway, by any real code. So I have just removed it all and everything tests fine, including the fortran 77 v2 API (which is what this code is part of). So the next beta release will no longer include this code and, when you get to netCDF 3.6.2, you won't have this problem. Thanks for pointing it out!! Ed Ticket Details =================== Ticket ID: QBR-903817 Department: Support netCDF Priority: High Status: Open