link a c-library to gdal.lib

[tinax@…]

Dear Frank:
    I tried to add a new imge format using the hdf5.lib into gdal, when i use 
the nmake command line on the path of ..gdal\frmts\MyHdf and ..gdal\frmts, it 
was compiled sucessfully, but when i compiled the makefile on the path of 
gdalroot , i had get some LNK2001 errors. What i need do for the makefile(on 
the path: ..gdal\ and gdal\frmts and gdal\frmt\MyHdf) when i add my format by 
useing the HDF5.lib (already been compiled ) into gdal, and what i should adapt 
in the relational files?

[warmerdam]

Hi,

Are you writing a whole new HDF 5 based driver?  There is an HDF driver already
but it is for HDF 4 and would (I gather) be fundamentally incompatible with
the HDF 5 libraries.  

If you include the full link errors I may be able to provide some suggestions,
but there isn't enough information here yet to suggest much.

Best regards,

[tinax@…]

Hi, Frank:
    I am so sorry to engross your golden time! 
    After been compiled and set into ..gdalroot\frmts\o, those *.obj related to 
hdf5.lib had passed sucessfully.But , then , i used nmake to compile on the 
path of ...gdalroot, the compiler told me that H5FDsec2.obj (and 
H5FDstdio.obj): error LNK2001:unsolved external symbol_ftruncate;The symbol 
ftruncate were defined in the three objects about hdf5.lib.Except for above 
tows, another is H5FDmpiposix.obj which had recognized the symbol!The code 
definded the symbol in the three files are same as below:
#ifdef H5_HAVE_LSEEK64
#   define file_offset_t	off64_t
#   define file_seek	lseek64
#   define file_truncate	ftruncate64
#elif defined (WIN32) && !defined(__MWERKS__)
# /*MSVC*/
#   define file_offset_t __int64
#   define file_seek _lseeki64
#   define file_truncate	_ftruncatei64
#else
#   define file_offset_t	off_t
#   define file_seek	HDlseek
#   define file_truncate	HDftruncate
#endif
    So , i think , due to difference in  the file storage models between hdf5 
and gdal, the errors came into being.
   Long for your help!  

[tinax@…]

Hi, Frank:
    I had forgotten to get your purpose about the three files.
    For H5FDstdio.c: 
    This is the Posix stdio.h I/O subclass of H5Flow.
    It also serves as an example of coding a simple file driver,
    therefore, it should not use any non-public definitions.
    
    For H5FDsec2.c:
    The POSIX unbuffered file driver using only the HDF5 public
    API and with a few optimizations: the lseek() call is made
    only when the current file position is unknown or needs to be
    changed based on previous I/O through this driver (don't mix
    I/O from this driver with I/O from other parts of the
    application to the same file).
    
    And for H5FDmpiposix.c:
    This is a "combination" MPI-2 and posix I/O driver.
    It uses MPI for coordinating the actions of several processes
    and posix I/O calls to do the actual I/O to the disk.
    
    Thanks!

[warmerdam]

Tian Xin,

I assume you are building with MSVC?  According to the comments in the
#ifdef's the second (WIN32 and not MWERKS) case should be used.  This case
should redefine file_truncate to _ftruncate64 but oddly that is not what
is coming up missing.  I am not sure what is going on here. 

By the way, you didn't answer my question about whether you are writing
a whole new HDF5 driver, or if you are attempting to link the HDF4 driver
with HDF5 libraries. 

>So , i think , due to difference in  the file storage models between hdf5 
>and gdal, the errors came into being.

I'm not sure what you mean by "storage model".  If you are writing an HDF5
driver, then the only code that should touch the hdf5 file would be what you
use in your driver, with the exception of the initial header read to populate
the GDALOpenInfo object.  

I suspect that the problem is using different standard C libraries for the bulk
of GDAL and the HDF5 libraries.  Certainly with the HDF4 static libraries I
always found it was necessary to build GDAL with particular C library linkage
options (

[tinax@…]

Hi,Frank:  
    Firstly , please forgive my poor ability in consulting you by English.I am 
a chinese boy , I should be ashamed to express my puzzle in English.Sorry for 
this.   
    What I do for my driver is just to compile the c files(coded by NCSA) into 
*.obj, then gather them into hdf5.lib and link it to gdal.After this, I can 
define some api-functions based on hdf5.lib for my driver.But,I defined the 
LINKER_FLAGS as /NODEFAULTLIB:LIBC in your..gdalroot\nmake.opt to link the 
hdf5.lib , so did the tow errors come?
    The storage models, in my former mail, are the data formats which mapped to 
different storage mechanisms, including single disk files, multiple files 
(family of files), and memory representations.That is , the Storage Model is a 
standard representation for the objects of the Abstract Data Model.The Storage 
Model consists of many file drivers ,such as Unbuffered Posix I/O (H5FD_SEC2), 
which uses Posix file-system functions like read and write to perform I/O to a 
single file, and Buffered single file (H5FD_STDIO) that This driver uses 
functions from the Unix/Posix `stdio.h' to perform buffered I/O to a single 
file.So , could you direct me whether both of them are supported in gdal?
    Then, if gdal can do, what is the reason for the two errors? The different 
standard C libraries for the bulk of GDAL and the HDF5 libraries ?And what 
should I do for the linkage options,and how?  
    At last, I am puzzled by why the H5FDmpiposix.obj could be passed 
sucessfully.
    Thanks, it is lucky that my dumpishness was treated with your mercy!

[warmerdam]

sorry for not getting back on this in a timely manner Tian.  I really
don't know why you are running into the problems you are, but they aren't
really core GDAL problems so I am closing this bug report.