Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Hi Stephen, > I've noticed that when building statically linked executables the order > of the link options is important. For instance: > > $ g++ -static -L... -I... foo.c -lnetcdf -lhdf5 -lhdf5_hl -lm -lz -o foo > /usr/local/lib/libhdf5_hl.a(H5LT.o): In function `H5LT_dtype_to_text': > H5LT.c:(.text+0x26e4): undefined reference to `H5Tget_cset' > H5LT.c:(.text+0x290b): undefined reference to `H5Tset_cset' > H5LT.c:(.text+0x2a55): undefined reference to `H5Tset_cset' > H5LT.c:(.text+0x2c4f): undefined reference to `H5Tget_tag' > /usr/local/QC/lib/libhdf5_hl.a(H5LTparse.o): In function `H5LTyyparse': > H5LTparse.c:(.text+0xe85): undefined reference to `H5Tset_tag' > H5LTparse.c:(.text+0x1077): undefined reference to `H5Tset_cset' > collect2: ld returned 1 exit status > > However this works: > $ g++ -static -L... -I... foo.c -lnetcdf -lhdf5_hl -lhdf5 -lm -lz -o foo > > Is this expected and if so is it documented anywhere? Yes this is to be expected, gcc expects the linking order to be in the order of dependency. gcc expects symbols from each specified library to be defined in this library itself or in one of the later specified libraries. It will not search all libraries for undefined symbols (which, AFAIK, Visual Studio does). For documentation, see: http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html All the best, Mario > Thanks, > Stephen. > > --- > Stephen Pascoe +44 (0)1235 445980 > British Atmospheric Data Centre > Rutherford Appleton Laboratory > > > -- > Scanned by iCritical. > > _______________________________________________ > netcdfgroup mailing list > netcdfgroup@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/
netcdfgroup
archives: