Undefined Reference to 'gdopen'

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:

--with-zlib=$ZLIB_DIR --with-jpeg=$JPEG_DIR --with-szlib=$SZIP_DIR --prefix=$HDF4_DIR --enable-fortran

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:

--prefix=$HDFEOS_DIR CC=h4cc --with-szlib=$SZIP_DIR --enable_fortran

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,

h4fc -fno-underscoring -L$(HDFEOS_DIR)/lib read_hdfeos.f90 -lhdfeos -lGctp -o read_hdfeos.exe

Would you please try HDF4 version 4.2.10?

From doc/README:

The HDF-EOS2 library requires HDF4 library version 4.2.10 or later.

See also:
hdf4/release_notes/HISTORY.txt at master · HDFGroup/hdf4 (github.com)

The problem still persists, unfortunately.

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:

h4fc -c read_hdfeos.f90
nm read_hdfeos.o | grep gdopen

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.

1 Like

Thank you for these tips!

I did the tests that you suggested and here are the results

  1. 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).

  1. 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.

  1. With HDF 4.2.10 and without -fno-underscoring
    This has the same results as (1).

  2. With HDF 4.2.10 and with -fno-underscoring
    This has the same results as (2).

  3. The library providing gdopen is libhdfeos.a built with HDF 4.2.16-2
    nm libhdfeos.a | grep gdopen
    0000000000012d70 T gdopen_

  4. The library providing gdopen is libhdfeos.a built with HDF 4.2.10
    nm libhdfeos.a | grep gdopen
    0000000000012f60 T gdopen_

So the library does contain 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.

Thank you for this information!

I have been trying to open the HDF-EOS file to no success. The file is in the same directory as my executable file.

According to the Function Reference of HDF-EOS2 (HDF-EOS2 v3.0 Function Reference Guide - SDPS Public Documentation - Earthdata Wiki), DFACC_READ has a value of 1 for read-only, which I used in my code. I have also tried hard-coding 1 in the second argument of gdopen.

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?

MOD04_L2 is swath.

Please see this MATLAB example that calls HDF-EOS2 Swath API:


You should use swopen():


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 

     tag = 1965; reference = 2;
     name = mod04; class = SWATH;
     number of entries = 3;
   number of attributes = 0 
     #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
    attr1: name=_FV_Latitude type=5 count=1 size=4
    attr2: name=_FV_Scan_Start_Time type=6 count=1 size=8
    attr3: name=_FV_Solar_Zenith type=22 count=1 size=2

Yes. I did realise that the MODIS HDF-EOS file I currently have is swath. I have changed gdopen to swopen but still returns a -1.

program read_hdfeos
	implicit none
	! Declares Variable(s): declares variable(s) required by the program.
	integer :: swopen
	integer, parameter :: DFACC_READ = 1
	integer :: swathfile_id
	character(len = 256) :: filename
	filename = "MOD04_L2.A2023098.0125.061.2023134085325.hdf"
	swathfile_id = swopen(trim(filename), DFACC_READ)
end program read_hdfeos

Would you please try this Makefile?

Here’s a sample Fortran code:

Here’s GitHub Action that passes the test on Ubuntu 20.04:

1 Like

Thank you!

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.

character(len = 256) :: filename

filename = 'MOD04_L2.A2023098.0125.061.2023134085325.hdf'

swathfile_id = swopen(filename, DFACC_READ)

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.

Again, thank you very much!