NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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: