NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Greetings all, I've been having issues installing the later versions of Gempak on Ubuntu, but I've managed to figure out a work-around. It's not ideal, but I figured I'd post what I found in case it helps others or in case someone's found a better way. For reference, this is Gempak 7.5.1 on Ubuntu 18.04 using a source code installation. Version 7.4.2 was already installed so technically this was an upgrade, and as such I didn't need to worry about any other package installations for this. Since this is on Ubuntu, I made Makeinc.linux64_gfortran a symlink to Makeinc.linux64_gfortran_ubuntu; I've never had to further edit the Ubuntu makeinc file in the past. What happens is 'make all' fails to build many of the Gempak binaries. Running 'grep failed make.out' shows a whole bunch of targets failed to get made, including (but not limited to) device drivers (ps, xw, gf, gif, etc.), Gempak programs and decoders; some made fine though while some didn't. My solution to get it working is to run the 'make all' command once, then add "LIBBZ2 = $(OS_LIB)/libbz2.a -ldl" to the bottom of the Ubuntu Makeinc file, and run 'make all' again; the key piece of that is the "-ldl" option. The first run without that edit will make and build the dependencies that Gempak comes with and requires (i.e. extlibs), while almost all of what failed before will work after adding that line. Additional details: The symptom that I first noticed was running my Gempak scripts after the install would yield "[GEMPLT -21] NODEVC - Invalid device selected." I then realized the device drivers weren't being made, nor were many other things as noted above. Digging into make.out I'd find messages such as this: /home/gempak/GEMPAK7.5.1/os/linux64/lib/libhdf5.a(H5PL.o): In function `H5PL_term_interface': H5PL.c:(.text+0x2c4): undefined reference to `dlclose' /home/gempak/GEMPAK7.5.1/os/linux64/lib/libhdf5.a(H5PL.o): In function `H5PL_load': H5PL.c:(.text+0x7bc): undefined reference to `dlsym' H5PL.c:(.text+0x93e): undefined reference to `dlerror' H5PL.c:(.text+0x94b): undefined reference to `dlclose' H5PL.c:(.text+0x958): undefined reference to `dlclose' H5PL.c:(.text+0xa78): undefined reference to `dlclose' H5PL.c:(.text+0xb67): undefined reference to `dlopen' H5PL.c:(.text+0xb82): undefined reference to `dlsym' collect2: error: ld returned 1 exit status Makefile:75: recipe for target 'gif' failed Michael James had made a github issue for Gempak with nearly identical output: https://github.com/Unidata/gempak/issues/42 I believe he had noticed the same problem, but hadn't gotten to an actual fix. He highlighted, however, "-ldl" should be and is getting supplied for making NETCDF, but maybe things further downstream aren't getting the message? I'm not terribly experienced with software engineering at this level, but in doing some more digging I found that adding "-ldl" to specific Makefiles' LIBINC section would get that specific binary to build correctly. Not wanting to go through every Makefile individually I wondered if adding that to the higher-up Makeinc would have the same effect. I noticed that libbz2 was one of the last in a list of things to be appended to the gfortran commands shown in make.out, so by making the above edit to the Ubuntu Makeinc file (derived from Makeinc.common_linux) it would essentially append "-ldl" to the end of those gfortran commands, thus allowing the binaries to build correctly. However, having that line there will prevent the extlibs from building correctly (or at least libbz2), so it needs to be added after a first-pass. Clearly this is not an ideal solution. All I know is that it works, and I haven't had any issues with Gempak after the install. But has anyone been able to find a more appropriate fix? Perhaps adding "-ldl" to all of the individual Makefiles is the right thing to do? Best, -Mike ====================== Mike Zuranski Meteorology Support Analyst College of DuPage - Nexlab Weather.cod.edu <http://weather.cod.edu/> ======================
gembud archives: