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/
