MET Compiling Issues: C compiler cannot create executables

[jhicks14]

Good evening,

I've been trying to get MET installed once again and am running into some more issues when trying to compile. Looking at the config.log file, the error seems to be: "configure:3879: error: C compiler cannot create executables". There is another error above this that says:

configure:3830: gcc -I/nawcf/home/nawcf1/v7.15.0/gempak/include -I/nawcf/home/nawcf1/v
7.15.0/os/linux3.10.0_x86_64/include -DLinux -DUNDERSCORE -I/usr/X11R6/include -DG_6
4BIT -Wl,--disable-new-dtags -Wl,-rpath,/cpc/home/jhicks/METplus4.1.2/external_libs/l
ib:/cpc/home/jhicks/METplus4.1.2/external_libs/lib:/cpc/home/jhicks/METplus4.1.2/exter
nal_libs/lib:/cpc/home/jhicks/METplus4.1.2/external_libs/lib:/cpc/home/jhicks/METplus4
.1.2/external_libs/lib:/cpc/home/jhicks/METplus4.1.2/external_libs/lib -Wl,-rpath, -
L/cpc/home/jhicks/METplus4.1.2/external_libs/lib conftest.c -lhdf5_hl -lhdf5 -lz >&5
/bin/ld: cannot find -lhdf5_hl
/bin/ld: cannot find -lhdf5
collect2: error: ld returned 1 exit status
configure:3834: $? = 1
configure:3872: result: no

I'm not sure if the issue with the c-compiler not being able to find the "hdf5" library is leading to the first error I showed. I'm not too sure how to proceed from here! I'll attach my install file with the environmental variables as well as the config.log file for reference.

Thanks!
config.log
install_met_env.cpc.txt

[jprestop]

Hi @jhicks14. I do believe that these lines are the source of the problem:

/bin/ld: cannot find -lhdf5_hl
/bin/ld: cannot find -lhdf5

However, the compile_MET_all.sh script should account for that problem with this line:

export LIBS="${LIBS} -lhdf5_hl -lhdf5 -lz"

I can see that is being set because I see the following in your config.log file (thank you so much for including your file):

LIBS=' -lhdf5_hl -lhdf5 -lz'

Perhaps there was a problem with the HDF5 installation? I see that you have set:

MET_HDF5='/cpc/home/jhicks/METplus4.1.2/external_libs'

Can you please check in '/cpc/home/jhicks/METplus4.1.2/external_libs/lib' to see if you have libhdf5_* files in that directory?

Thanks!

[jprestop]

Hi @jhicks14. It's great that you discovered that there was an old version of "netcdf.h" in an included directory and found a way around it!

Unfortunately, once again, I am a bit stumped by this error:

/cpc/home/jhicks/MET11/MET-11.0.0-beta3/external_libs/lib/libz.so: undefined reference to memcpy@GLIBC_2.14

I have not encountered this error previously. Looking online I see a post in Stack Overflow, which indicates that the mempcy@GLIBC_2.14 is called a versioned symbol and the GLIBC uses it. Please take a look at the post and solution and see if it is helpful to you. If not, once again, I have to encourage you to follow up with Unidata for help with this issue. If you'd like to copy me and would like me to follow up if they don't follow up, please let me know and I'd be happy to give them a nudge. Since Unidata is part of UCAR, maybe follow up from a fellow UCAR employee would be helpful.

[jprestop]

Hi @jhicks14. I just wanted to follow up and see if you've had any luck in resolving this issue. I'd be happy to follow up with any correspondence with Unidata if you'd like.

[jhicks14]

Hi @jprestop

I followed up with Unidata but haven't yet heard back, so I just sent them a second email. I also just forwarded you the email I previously sent them and will make sure you're included in any further email chain!

[jprestop]

Hi @jhicks14. I just wanted to follow up on this Discussion. Did we end up resolving these issues via the email that started with your correspondence with Unidata?

[jhicks14]

Hi @jprestop

Yes, everything seems to work now! Thanks again for your help!

[jprestop]

Great! Thanks, @jhicks14. I'll post a summary here, mark it as the answer, and then lock this conversation. Please feel free to start a new ticket with any new problems.

To summarize, this issue was resolved with specific problems coming from the user's environment. The issues included:

• An old "netcdf.h" header file was being read in when the source files were run
• Specifying the correct compiler in the the configuration file (two GNU compilers were present - one on the system and one in the conda environemnt)
• Ensuring HDF5 and NetCDF4 could find the zlib library
• Resolving a "Internal Error: get_unit(): Bad internal unit KIND" error caused by conflicting library files (libgfortran.so.3 and libgfortran.so.4)