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.

Re: [gembud] Gempak Ubuntu Installation

Hi!

I also had the same problems and used the same solution...

Christian

On Mon, Jan 27, 2020 at 9:19 PM Mike Zuranski <zuranski.wx@xxxxxxxxx> wrote:

> 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/>
> ======================
> _______________________________________________
> NOTE: All exchanges posted to Unidata maintained email lists are
> recorded in the Unidata inquiry tracking system and made publicly
> available through the web.  Users who post to any of the lists we
> maintain are reminded to remove any personal information that they
> do not want to be made public.
>
>
> gembud mailing list
> gembud@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe,  visit:
> https://www.unidata.ucar.edu/mailing_lists/
>
  • 2020 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the gembud archives: