I am trying to build HDF-EOS2 for an Ubuntu 20.04 system and for Fortran, and have been following the steps presented in here How to build HDF-EOS.
All of the dependencies of HDF-EOS2 were built from source and are installed in a non-default directory. The version of the dependencies for HDF4 that I use are the following:
ZLIB (1.2.11)
SZIP (2.1.1)
JPEG (9e)
No additional options were added upon installing these–the only option that I used was the --prefix.
For installing HDF4 2.16-2, I used the following options:
I am trying to build it with --enable-shared but without much success, I am told by the error log to disable Fortran if I were to generate a shared library. Finally, I built HDF-EOS2 3.0 with the following options:
Comparing with the tutorial above, I have removed the -Df2cFortran option for the CC variable because it doesn’t seem to do anything and the enable-install-include option is unrecognized. The installation was successful. However, when I try to call gdopen from a Fortran code, it returns an undefined reference to 'gdopen' error.
I have no idea why this occurs because I have linked the hdfeos library (which defines gdopen) when compiling the Fortran code (let’s call it read_hdfeos.f90). The options for compilation are shown below,
You will need to do some of your own debugging. I suggest use the “nm” command line tool to examine that symbol, both provided and requested. For example:
Repeat with -fno-underscoring added, because I am suspicious of that one.
Repeat for the library file that you think should provide gdopen.
Repeat for the alternate version of HDF4, if you get that far.
From “nm”, “U” indicates a requested symbol. “T” indicates a provided symbol. They must match exactly, including any underscores.
I did the tests that you suggested and here are the results
With HDF 4.2.16-2 and without the -fno-underscoring nm read_hdfeos.o | grep gdopen U gdopen_
The code did compile, however it seems that it cannot successfully open any HDF-EOS file–gdopen returns an ID of -1 (I am still calling gdopen rather than gdopen_, and the latter returns an error upon compilation).
With HDF 4.2.16-2 and with the -fno-underscoring nm read_hdfeos.o | grep gdopen U gdopen
As I understand it, the symbol gdopen is being requested, but is still undefined.
With HDF 4.2.10 and without -fno-underscoring
This has the same results as (1).
With HDF 4.2.10 and with -fno-underscoring
This has the same results as (2).
The library providing gdopen is libhdfeos.a built with HDF 4.2.16-2 nm libhdfeos.a | grep gdopen 0000000000012d70 T gdopen_
The library providing gdopen is libhdfeos.a built with HDF 4.2.10 nm libhdfeos.a | grep gdopen 0000000000012f60 T gdopen_
Your original problem is now solved: “Undefined Reference to ‘gdopen’”. Do not use “-fno-underscoring” when compiling a fortran program with h4fc.
Under the hood, a single trailing underscore is added to fortran symbols. There are historical reasons for this which I do not recall. It is rather a mess. Expect this with fortran compilers in general.
Now move on to your next error. Gdopen returns fid = -1. The ref manual says this means “FAIL”. There is no additional status information or explanation. My guess is this is simply a “file not found”. It could also be a write permissions problem or an overwrite protection. This depends on your setting of the access parameter in the function call. Try making a copy of the HDF4 HDF-EOS file in your local directory, and open it in read-only mode. Refer to gdopen docs in the HDF-EOS2 reference manual.
program read_hdfeos
implicit none
! Declares Variable(s): declares variable(s) required by the program.
integer :: gdopen
integer, parameter :: DFACC_READ = 1
integer :: gridfile_id
character(len = 256) :: filename
filename = "MOD04_L2.A2023098.0125.061.2023134085325.hdf"
gridfile_id = gdopen(filename, DFACC_READ)
print *, gridfile_id
end program read_hdfeos
The ID still returns -1. I have also tried opening it as a swath, i.e. through swopen, and employing trim thinking that the trailing spaces might be the cause, and it still returns -1.
I have tried opening the HDF-EOS file in Panoply and Matlab, but it can be successfully opened through those.
Maybe your file is pure HDF and doesn’t have some EOS required objects? Could you please try to use hdp command-line tool using dumpsds and dumpvg flags and post the output here?
The outputs are kind of large: the dumpsds output is 106 MB in size and here are the first few lines,
File name: MOD04_L2.A2023098.0125.061.2023134085325.hdf
File attributes:
Attr0: Name = HDFEOSVersion
Type = 8-bit signed char
Count= 12
Value = HDFEOS_V2.19
And here are the first few lines of the output for dumpvg
File name: MOD04_L2.A2023098.0125.061.2023134085325.hdf
Vgroup:0
tag = 1965; reference = 2;
name = mod04; class = SWATH;
number of entries = 3;
number of attributes = 0
Entries:-
#0 (Vgroup)
tag = 1965; reference = 3;
number of entries = 2;
name = Geolocation Fields; class = SWATH Vgroup
number of attributes = 0
#1 (Vgroup)
tag = 1965; reference = 8;
number of entries = 79;
name = Data Fields; class = SWATH Vgroup
number of attributes = 0
#2 (Vgroup)
tag = 1965; reference = 176;
number of entries = 72;
name = Swath Attributes; class = SWATH Vgroup
number of attributes = 143
attr0: name=_FV_Longitude type=5 count=1 size=4
-999.000000
attr1: name=_FV_Latitude type=5 count=1 size=4
-999.000000
attr2: name=_FV_Scan_Start_Time type=6 count=1 size=8
-999.000000
attr3: name=_FV_Solar_Zenith type=22 count=1 size=2
-9999
I was able to open the file successfully with your code.
From your example, I re-configured the Makefile and the Fortran code to match exactly what I wrote before and it returns to my previous error if I call the file through a variable, i.e.
yet the file will be opened successfully if the file name is hard-coded into swopen. At least I know now that the problem is not how the HDF4 and HDF-EOS were compiled.
Edit: it seems that calling the file through a variable adds leading whitespaces, so adding trim and adjustl works.
