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: