Patchwork Add gctp

login
register
mail settings
Submitter Thomas Danckaert
Date June 17, 2016, 12:40 p.m.
Message ID <20160617.144017.336729442489418576.post@thomasdanckaert.be>
Download mbox | patch
Permalink /patch/13167/
State New
Headers show

Comments

Thomas Danckaert - June 17, 2016, 12:40 p.m.
Hi guix-devel,

this is a patch to add the GCTP library. It seems the library is no 
longer maintained separately (“official” sources are gone), so this 
package downloads the HDF-EOS5 source, which contains GCTP, and 
patches the build to only build and install GCTP. (I'm packaging 
HDF-EOS5 later on)

It's not very elegant... An alternative solution would be to get the 
source package from, e.g. Debian, and build that (might involve less 
patching).

Thomas
Leo Famulari - June 18, 2016, 1:39 a.m.
On Fri, Jun 17, 2016 at 02:40:17PM +0200, Thomas Danckaert wrote:
> this is a patch to add the GCTP library. It seems the library is no longer
> maintained separately (“official” sources are gone), so this package
> downloads the HDF-EOS5 source, which contains GCTP, and patches the build to
> only build and install GCTP. (I'm packaging HDF-EOS5 later on)

Should we package GCTP separately in that case? Is it used by anything
besides HDF-EOS5? Or, should we just package HDF-EOS5?

We usually don't accept bundled code, but it sounds like GCTP no longer
exists as an independent project. Is that right?

Otherwise, it looks like we are forking GCTP and creating a new
distribution.

> It's not very elegant... An alternative solution would be to get the source
> package from, e.g. Debian, and build that (might involve less patching).

We do fetch a few things from Debian.

Here are some comments:

> Subject: [PATCH] gnu: Add gctp

We prefer to use complete sentences, with punctuation, even when they
are only 2 words long ;)

> * gnu/packages/maths.cm (gctp): New variable
> 
> * guix/packages.scm (decompression-type): Modify by adding ".Z" suffix
>   for gzipped files.

I believe this was addressed in commit 5257ab6de. Can you check?

> * gnu/packages/patches/gct-build-shared.patch: patch build system for
>   shared builds.

We also capitalize the beginning of our sentences :)

> * gnu/packages/patches/gctp-remove-hdf-eos5.patch: don't build the
>   hdf-eos5 library contained in the same archive.
> 
> * gnu/packages/patches/gctp-fix-soname.patch: use a lower case soname.
> ---
>  gnu/packages/maths.scm                          |  39 ++
>  gnu/packages/patches/gctp-build-shared.patch    |  84 +++++
>  gnu/packages/patches/gctp-fix-soname.patch      |  31 ++
>  gnu/packages/patches/gctp-remove-hdf-eos5.patch | 482 ++++++++++++++++++++++++
>  4 files changed, 636 insertions(+)
>  create mode 100644 gnu/packages/patches/gctp-build-shared.patch
>  create mode 100644 gnu/packages/patches/gctp-fix-soname.patch
>  create mode 100644 gnu/packages/patches/gctp-remove-hdf-eos5.patch
> 

> diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
> index 3b860a9..9cd0554 100644
> --- a/gnu/packages/maths.scm
> +++ b/gnu/packages/maths.scm
> @@ -42,6 +42,8 @@
>    #:use-module (guix build-system gnu)
>    #:use-module (guix build-system r)
>    #:use-module (gnu packages algebra)
> +  #:use-module (gnu packages autotools)
> +  #:use-module (gnu packages base)
>    #:use-module (gnu packages bison)
>    #:use-module (gnu packages boost)
>    #:use-module (gnu packages check)
> @@ -408,6 +410,43 @@ plotting engine by third-party applications like Octave.")
>      (license (license:fsf-free
>                "http://gnuplot.cvs.sourceforge.net/gnuplot/gnuplot/Copyright"))))
>  
> +(define-public gctp
> +  (package
> +    (name "gctp")
> +    (version "1.0")

Is this the upstream version or is it arbitrary? I see that the HDF-EOS5
tarball is at version 1.15.

> +    (source (origin
> +              (method url-fetch)
> +              (uri (string-append "ftp://edhs1.gsfc.nasa.gov/edhs/hdfeos5/latest_release/HDF-EOS5.1.15.tar.Z"))
> +              (sha256
> +               (base32
> +                "1p83333nzzy8rn5chxlm0hrkjjnhh2w1ji8ac0f9q4xzg838i58i"))
> +              (patches (search-patches "gctp-build-shared.patch" "gctp-remove-hdf-eos5.patch" "gctp-fix-soname.patch"))
> +              ))

Some of these lines are too long. We like to keep them shorter than 80
characters whenever possible.

> +    (native-inputs
> +     `(("autoconf" ,autoconf)
> +       ("automake" ,automake)
> +       ("libtool" ,libtool)
> +       ("coreutils" ,coreutils)))
> +    (build-system gnu-build-system)
> +    (arguments
> +     `(#:configure-flags '("--enable-install-include")
> +       #:phases
> +       (modify-phases %standard-phases
> +         (add-before
> +             'configure 'autogen
> +           (lambda _
> +             (and (zero? (system* "chmod" "-R" "u+w" ".")) ; archive is read-only...

We have a Scheme procedure for chmod. There are examples in
'gnu/packages'. Is this what required coreutils as a native-input?

> diff --git a/gnu/packages/patches/gctp-build-shared.patch b/gnu/packages/patches/gctp-build-shared.patch

In general, I think these patches need some more comments and
explanation of the various changes.

> new file mode 100644
> index 0000000..1139fbb
> --- /dev/null
> +++ b/gnu/packages/patches/gctp-build-shared.patch
> @@ -0,0 +1,84 @@
> +Allow shared build.
> +
> +---
> + Makefile.am             |  6 ------
> + configure.ac            | 12 ------------
> + include/HE5_HdfEosDef.h |  1 +
> + src/Makefile.am         |  3 ++-
> + 4 files changed, 3 insertions(+), 19 deletions(-)
> +

> +diff --git a/Makefile.am b/Makefile.am
> +index 363bcfb..01ed024 100644
> +--- a/Makefile.am
> ++++ b/Makefile.am
> +@@ -3,13 +3,7 @@
> + # Include boilerplate
> + include $(top_srcdir)/config/include.am
> + 
> +-# List of subdirectories.
> +-# Only build the testdrivers directory if configure detected that it's present.
> +-if TESTDRIVERS_CONDITIONAL
> +-TESTDRIVERS=testdrivers
> +-else
> + TESTDRIVERS=
> +-endif

What is the effect of this?

> + 
> + if INSTALL_INCLUDE_CONDITIONAL
> + INCLUDE=include

> +diff --git a/configure.ac b/configure.ac
> +index 5d48b43..cfa9d4e 100644
> +--- a/configure.ac
> ++++ b/configure.ac
> +@@ -13,9 +13,6 @@ AC_CONFIG_AUX_DIR([config])
> + AM_INIT_AUTOMAKE([foreign])
> + AM_MAINTAINER_MODE
> + 
> +-# Disable shared libraries (for now)
> +-AC_DISABLE_SHARED

Okay.

> +-
> + AM_PROG_LIBTOOL
> + 
> + dnl ----------------------------------------------------------------------
> +@@ -597,13 +594,4 @@ AC_CONFIG_FILES([Makefile
> +                  gctp/src/Makefile
> +                  samples/Makefile])
> + 
> +-if test "X$TESTDRIVERS_DIR" = "Xyes"; then
> +-  AC_CONFIG_FILES([ testdrivers/Makefile
> +-                 testdrivers/grid/Makefile
> +-                 testdrivers/point/Makefile
> +-                 testdrivers/swath/Makefile
> +-                 testdrivers/threads/Makefile
> +-                 testdrivers/za/Makefile])
> +-fi
> +-

It's related to an earlier diff, but can you explain?

> + AC_OUTPUT

> +diff --git a/include/HE5_HdfEosDef.h b/include/HE5_HdfEosDef.h
> +index 9ed7881..abf0a90 100755
> +--- a/include/HE5_HdfEosDef.h
> ++++ b/include/HE5_HdfEosDef.h
> +@@ -24,6 +24,7 @@
> + #ifndef HE5_HDFEOSDEF_H_
> + #define HE5_HDFEOSDEF_H_
> + 
> ++#define H5_USE_16_API 1

What is the significance of this definition?

> + #include <hdf5.h>
> + 
> + #ifdef H5_USE_16_API

> +diff --git a/src/Makefile.am b/src/Makefile.am
> +index 76b1d4c..daf7ad8 100644
> +--- a/src/Makefile.am
> ++++ b/src/Makefile.am
> +@@ -10,7 +10,8 @@ INCLUDES=-I$(top_srcdir)/include/
> + 
> + # Set LDFLAGS to allow the HDF-EOS library to use extern variables from
> + # HDF5
> +-LDFLAGS=-Wl,-single_module
> ++LDFLAGS+= -shrext .so
> ++LIBS+= -lhdf5_hl -lhdf5 -lm

Okay.

> + 
> + # Build HDF-EOS5
> + lib_LTLIBRARIES=libhe5_hdfeos.la
> +-- 
> +2.5.0
> +

> diff --git a/gnu/packages/patches/gctp-fix-soname.patch b/gnu/packages/patches/gctp-fix-soname.patch
> new file mode 100644
> index 0000000..5a32970
> --- /dev/null
> +++ b/gnu/packages/patches/gctp-fix-soname.patch
> @@ -0,0 +1,31 @@
> +Make library name all-lowercase.

Is this a stylistic change or does it have some other effect?

> +
> +---
> + gctp/src/Makefile.am | 4 ++--
> + 1 file changed, 2 insertions(+), 2 deletions(-)
> +

> +diff --git a/gctp/src/Makefile.am b/gctp/src/Makefile.am
> +index 76ecf1c..97c2438 100755
> +--- a/gctp/src/Makefile.am
> ++++ b/gctp/src/Makefile.am
> +@@ -4,7 +4,7 @@
> + include $(top_srcdir)/config/include.am
> + 
> + # Library to build
> +-lib_LTLIBRARIES = libGctp.la
> ++lib_LTLIBRARIES = libgctp.la
> + 
> + ## Normally DEFAULT_INCLUDES is supplied by Automake, but one of the
> + ## directories included by default is $(top_builddir)/include, which
> +@@ -17,7 +17,7 @@ DEFAULT_INCLUDES = -I. -I$(srcdir)
> + INCLUDES=-I$(srcdir)/../include/
> + 
> + # Library source files
> +-libGctp_la_SOURCES = gctp.c alberfor.c alberinv.c alconfor.c alconinv.c      \
> ++libgctp_la_SOURCES = gctp.c alberfor.c alberinv.c alconfor.c alconinv.c      \
> +           azimfor.c aziminv.c bceafor.c bceainv.c br_gctp.c ceafor.c         \
> +           ceainv.c cproj.c eqconfor.c eqconinv.c equifor.c equiinv.c         \
> +           for_init.c gnomfor.c gnominv.c goodfor.c goodinv.c gvnspfor.c      \
> +-- 
> +2.5.0
> +

> diff --git a/gnu/packages/patches/gctp-remove-hdf-eos5.patch b/gnu/packages/patches/gctp-remove-hdf-eos5.patch
> new file mode 100644
> index 0000000..4601c5f
> --- /dev/null
> +++ b/gnu/packages/patches/gctp-remove-hdf-eos5.patch
> @@ -0,0 +1,482 @@
> +From c206a99fc4692ef9ea48a11bbb9de8a7dd44a7f8 Mon Sep 17 00:00:00 2001
> +From: Thomas Danckaert <thomas.danckaert@gmail.com>
> +Date: Fri, 17 Jun 2016 07:55:58 +0200
> +Subject: [PATCH 1/2] Build only GCTP.
> +
> +---
> + Makefile.am  |   2 +-
> + configure.ac | 430 +----------------------------------------------------------
> + 2 files changed, 2 insertions(+), 430 deletions(-)

430 deletions: If it works, then okay :)
Thomas Danckaert - June 18, 2016, 9:05 a.m.
From: Leo Famulari <leo@famulari.name>

Subject: Re: [PATCH] Add gctp
Date: Fri, 17 Jun 2016 21:39:26 -0400

> On Fri, Jun 17, 2016 at 02:40:17PM +0200, Thomas Danckaert wrote:

>> this is a patch to add the GCTP library. It seems the library is 

>> no longer

>> maintained separately (“official” sources are gone), so this 

>> package

>> downloads the HDF-EOS5 source, which contains GCTP, and patches 

>> the build to

>> only build and install GCTP. (I'm packaging HDF-EOS5 later on)

>

> Should we package GCTP separately in that case? Is it used by 

> anything

> besides HDF-EOS5? Or, should we just package HDF-EOS5?


The only other use I'm aware of is in HDF-EOS2, which is a separate 
library from HDF-EOS5, built on HDF4 instead of HDF5, and which also 
bundles gctp. I intend to package HDF-EOS2 as well, once HDF4 is 
included.

> We usually don't accept bundled code, but it sounds like GCTP no 

> longer

> exists as an independent project. Is that right?


That is my impression, too (broken urls and undeliverable e-mails). 
The package is quite small anyway, so perhaps bundling with the 2 
HDF-EOS libraries is acceptable?

> Here are some comments:


[ Style issues noted, I will take care of that. ]

>> +(define-public gctp

>> +  (package

>> +    (name "gctp")

>> +    (version "1.0")

>

> Is this the upstream version or is it arbitrary? I see that the 

> HDF-EOS5

> tarball is at version 1.15.


The archive does not contain an explicit version number or changelog 
(it just says it's the “new C version of the GCTP” -- before that, it 
seems there were some Fortran routines).  I've also found a gctpc2.0 
archive, which *does* have a changelog, and on closer inspection 
(comparing the source of this package with comments from the 
changelog from 2.0), it seems that this code corresponds to version 
1.3... (though e.g. Debian also calls it 1.0).  It's quite messy 
actually. I'll see if HDF-EOS5 builds against gctp-2.0 (for which a 
I've found a cleaner archive), and maybe package that instead...

> We have a Scheme procedure for chmod. There are examples in

> 'gnu/packages'. Is this what required coreutils as a native-input?


That's the reason indeed. I wasn't aware of the chmod procedure, I'll 
adapt my package definition .

> In general, I think these patches need some more comments and

> explanation of the various changes.


I'll resubmit an improved patch.

Before I do that, though, I'll await your opinion on whether an 
independent gctp package is actually needed or not.

Some other explanations in-line:

>> +diff --git a/Makefile.am b/Makefile.am

>> +index 363bcfb..01ed024 100644

>> +--- a/Makefile.am

>> ++++ b/Makefile.am

>> +@@ -3,13 +3,7 @@

>> + # Include boilerplate

>> + include $(top_srcdir)/config/include.am

>> +

>> +-# List of subdirectories.

>> +-# Only build the testdrivers directory if configure detected 

>> that it's present.

>> +-if TESTDRIVERS_CONDITIONAL

>> +-TESTDRIVERS=testdrivers

>> +-else

>> + TESTDRIVERS=

>> +-endif

>

> What is the effect of this?

>


About this and the other “TESTDRIVERS”-related stuff:
When we run automake after patching the build, it needs the 
“testdrivers” directory.  This is a set of additional 
tests/demonstration programs (HDF-EOS5 already contains tests in the 
src/samples directory), which are distributed in a separate tarball 
(the configure script will test if the testdrivers are there or not, 
so they are optional in a “standard” build scenario). In order to 
allow automake to complete, I removed all references to the 
testdrivers in my patch.  The alternative solution would be to 
download 2 tarballs (source + testdrivers) and extract them in the 
build directory. Removing the testdrivers was the easiest solution.

>> + AC_OUTPUT

>

>> +diff --git a/include/HE5_HdfEosDef.h b/include/HE5_HdfEosDef.h

>> +index 9ed7881..abf0a90 100755

>> +--- a/include/HE5_HdfEosDef.h

>> ++++ b/include/HE5_HdfEosDef.h

>> +@@ -24,6 +24,7 @@

>> + #ifndef HE5_HDFEOSDEF_H_

>> + #define HE5_HDFEOSDEF_H_

>> +

>> ++#define H5_USE_16_API 1

>

> What is the significance of this definition?

>


Actually this only affects the HDF-EOS5 package, and I now realize it 
can be removed from this patchset.  I was using the same patch for 
shared library compilation in my HDF5 and GCTP packages... lazyness.

(The HDF5 API changed in version 1.8. Code written against previous 
version (such as HDF-EOS5) needs this #define to link with newer 
versions of HDF5.)

>> diff --git a/gnu/packages/patches/gctp-fix-soname.patch 

>> b/gnu/packages/patches/gctp-fix-soname.patch

>> new file mode 100644

>> index 0000000..5a32970

>> --- /dev/null

>> +++ b/gnu/packages/patches/gctp-fix-soname.patch

>> @@ -0,0 +1,31 @@

>> +Make library name all-lowercase.

>

> Is this a stylistic change or does it have some other effect?

>


Otherwise the library is installed as “libGctp.so.0”, which seems 
like an unconventional capitalization (?). Like this, users switching 
from Debian & Co. will have a seamless experience ;-)

Thomas
Leo Famulari - June 25, 2016, 5:21 p.m.
On Sat, Jun 18, 2016 at 11:05:40AM +0200, Thomas Danckaert wrote:
> From: Leo Famulari <leo@famulari.name>
> Date: Fri, 17 Jun 2016 21:39:26 -0400
> > Should we package GCTP separately in that case? Is it used by anything
> > besides HDF-EOS5? Or, should we just package HDF-EOS5?
> 
> The only other use I'm aware of is in HDF-EOS2, which is a separate library
> from HDF-EOS5, built on HDF4 instead of HDF5, and which also bundles gctp. I
> intend to package HDF-EOS2 as well, once HDF4 is included.
> 
> > We usually don't accept bundled code, but it sounds like GCTP no longer
> > exists as an independent project. Is that right?
> 
> That is my impression, too (broken urls and undeliverable e-mails). The
> package is quite small anyway, so perhaps bundling with the 2 HDF-EOS
> libraries is acceptable?

It sounds like you've tried emailing the authors for advice. Is that
right?

> The archive does not contain an explicit version number or changelog (it
> just says it's the “new C version of the GCTP” -- before that, it seems
> there were some Fortran routines).  I've also found a gctpc2.0 archive,
> which *does* have a changelog, and on closer inspection (comparing the
> source of this package with comments from the changelog from 2.0), it seems
> that this code corresponds to version 1.3... (though e.g. Debian also calls
> it 1.0).  It's quite messy actually. I'll see if HDF-EOS5 builds against
> gctp-2.0 (for which a I've found a cleaner archive), and maybe package that
> instead...

It looks like this gctp-2.0 is bundled with wgrib2 [0]. If there is no
independent repository for GCTP, I'd assume that GCTP is altered
independently for each application that it's bundled with. If so, I
think it makes sense to use the bundled copy of GCTP.

Otherwise, we are basically forking GCTP and creating a new distribution
of it, and that would require us to maintain it and test its integration
with HDF-EOS5.

What do people think? Should we use the bundled GCTP in HDF-EOS5 and,
later, HDF-EOS2?

[0]
http://www.nco.ncep.noaa.gov/pmb/codes/nwprod/util/sorc/wgrib2.cd/grib2/wgrib2/Introduction.txt
Thomas Danckaert - June 27, 2016, 7:07 p.m.
From: Leo Famulari <leo@famulari.name>
Subject: Re: [PATCH] Add gctp
Date: Sat, 25 Jun 2016 13:21:31 -0400

> It sounds like you've tried emailing the authors for advice. Is that
> right?

I tried 2 addresses that I found in the source distributions, but 
both addresses bounced.

> It looks like this gctp-2.0 is bundled with wgrib2 [0]. If there is 
> no
> independent repository for GCTP, I'd assume that GCTP is altered
> independently for each application that it's bundled with. If so, I
> think it makes sense to use the bundled copy of GCTP.
>
> Otherwise, we are basically forking GCTP and creating a new 
> distribution
> of it, and that would require us to maintain it and test its 
> integration
> with HDF-EOS5.

Indeed, I believe GCTP is not maintained anymore, and each project 
using it makes a few small adjustments. From the changelog, it seems 
GCTP was last changed March 1998.

If there's not much interest to include HDF-EOS right now, I could 
also maintain the libraries as a custom packages somewhere, for the 
few people who need them. I think one of the great things about Guix 
is that packages defined by users or third parties integrate so 
easily with the main repository.

best,

Thomas
Leo Famulari - July 1, 2016, 8:33 p.m.
On Mon, Jun 27, 2016 at 09:07:54PM +0200, Thomas Danckaert wrote:
> Indeed, I believe GCTP is not maintained anymore, and each project using it
> makes a few small adjustments. From the changelog, it seems GCTP was last
> changed March 1998.

In this case, I think it's appropriate to use the bundled GCTP. What do
others think?

> If there's not much interest to include HDF-EOS right now, I could also
> maintain the libraries as a custom packages somewhere, for the few people
> who need them. I think one of the great things about Guix is that packages
> defined by users or third parties integrate so easily with the main
> repository.

I do think we should include HDF-EOS! If we choose to use the bundled
GCTP, are your earlier patches easily adaptable?
Thomas Danckaert - July 7, 2016, 7:40 a.m.
From: Leo Famulari <leo@famulari.name>
Subject: Re: [PATCH] Add gctp
Date: Fri, 1 Jul 2016 16:33:12 -0400

> On Mon, Jun 27, 2016 at 09:07:54PM +0200, Thomas Danckaert wrote:
>> Indeed, I believe GCTP is not maintained anymore, and each project using it
>> makes a few small adjustments. From the changelog, it seems GCTP was last
>> changed March 1998.
> 
> In this case, I think it's appropriate to use the bundled GCTP. What do
> others think?

It's not a lot of work to submit a patch for HDF-EOS5 with the bundled GCTP, but I'm afraid that other packages which depend on two libraries that each bundle (a version of) GCTP (such as HDF-EOS2 and HDF-EOS5), will run into problems. There would be either a conflict due to multiple versions of libGctp, or, if we statically include GCTP in the libraries that use it, conflicting symbols when we link those libraries, no?

For this reason, maybe using a separate GCTP package, and adding a patch to projects that use it, is the best solution after all?  Development of GCTP and most packages that depend on it seems to be mostly finished anyway, so maintaining the patches might not be that much work.

Thomas
Ludovic Courtès - July 18, 2016, 1:02 p.m.
Thomas Danckaert <post@thomasdanckaert.be> skribis:

> From: Leo Famulari <leo@famulari.name> Subject: Re: [PATCH] Add gctp
> Date: Fri, 1 Jul 2016 16:33:12 -0400
>
>> On Mon, Jun 27, 2016 at 09:07:54PM +0200, Thomas Danckaert wrote:
>>> Indeed, I believe GCTP is not maintained anymore, and each project
>>> using it makes a few small adjustments. From the changelog, it
>>> seems GCTP was last changed March 1998.
>> In this case, I think it's appropriate to use the bundled GCTP. What
>> do others think?
>
> It's not a lot of work to submit a patch for HDF-EOS5 with the bundled
> GCTP, but I'm afraid that other packages which depend on two libraries
> that each bundle (a version of) GCTP (such as HDF-EOS2 and HDF-EOS5),
> will run into problems. There would be either a conflict due to
> multiple versions of libGctp, or, if we statically include GCTP in the
> libraries that use it, conflicting symbols when we link those
> libraries, no?
>
> For this reason, maybe using a separate GCTP package, and adding a
> patch to projects that use it, is the best solution after all?
> Development of GCTP and most packages that depend on it seems to be
> mostly finished anyway, so maintaining the patches might not be that
> much work.

Leo, what’s your take on this?  It seems we’ve forgotten about this
patch for too long already.  :-)

Thanks,
Ludo’.
Leo Famulari - July 18, 2016, 9:47 p.m.
On Thu, Jul 07, 2016 at 09:40:18AM +0200, Thomas Danckaert wrote:
> It's not a lot of work to submit a patch for HDF-EOS5 with the bundled
> GCTP, but I'm afraid that other packages which depend on two libraries
> that each bundle (a version of) GCTP (such as HDF-EOS2 and HDF-EOS5),
> will run into problems. There would be either a conflict due to
> multiple versions of libGctp, or, if we statically include GCTP in the
> libraries that use it, conflicting symbols when we link those
> libraries, no?

I'm not sure if there will be problems or not... it's unfortunately
beyond my level of expertise :) I've asked someone with more experience
than me to weigh in.

> For this reason, maybe using a separate GCTP package, and adding a
> patch to projects that use it, is the best solution after all?
> Development of GCTP and most packages that depend on it seems to be
> mostly finished anyway, so maintaining the patches might not be that
> much work.

Based on my experience with Guix so far, I think that maintaining our
own forks of 3rd party software is outside of the scope of the Guix
project. I think that the {nix,guix}-daemon is the only software for
which we do this.

If it's not possible to use the bundled GCTPs then we have to use an
external library, but I think it should be maintained outside of Guix.
As you say, it should not be much work to put it on a public Git repo or
to host a tarball, since the development is basically complete.

Too bad no other distros have already packaged it; often we can copy
them ;)

I'm sorry for the loooong delayed reply.

Patch

From 6c253d8ca12003bec3be4b040723d96e07445dfe Mon Sep 17 00:00:00 2001
From: Thomas Danckaert <thomas.danckaert@gmail.com>
Date: Fri, 17 Jun 2016 10:41:50 +0200
Subject: [PATCH] gnu: Add gctp

* gnu/packages/maths.cm (gctp): New variable

* guix/packages.scm (decompression-type): Modify by adding ".Z" suffix
  for gzipped files.

* gnu/packages/patches/gct-build-shared.patch: patch build system for
  shared builds.

* gnu/packages/patches/gctp-remove-hdf-eos5.patch: don't build the
  hdf-eos5 library contained in the same archive.

* gnu/packages/patches/gctp-fix-soname.patch: use a lower case soname.
---
 gnu/packages/maths.scm                          |  39 ++
 gnu/packages/patches/gctp-build-shared.patch    |  84 +++++
 gnu/packages/patches/gctp-fix-soname.patch      |  31 ++
 gnu/packages/patches/gctp-remove-hdf-eos5.patch | 482 ++++++++++++++++++++++++
 4 files changed, 636 insertions(+)
 create mode 100644 gnu/packages/patches/gctp-build-shared.patch
 create mode 100644 gnu/packages/patches/gctp-fix-soname.patch
 create mode 100644 gnu/packages/patches/gctp-remove-hdf-eos5.patch

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index 3b860a9..9cd0554 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -42,6 +42,8 @@ 
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system r)
   #:use-module (gnu packages algebra)
+  #:use-module (gnu packages autotools)
+  #:use-module (gnu packages base)
   #:use-module (gnu packages bison)
   #:use-module (gnu packages boost)
   #:use-module (gnu packages check)
@@ -408,6 +410,43 @@  plotting engine by third-party applications like Octave.")
     (license (license:fsf-free
               "http://gnuplot.cvs.sourceforge.net/gnuplot/gnuplot/Copyright"))))
 
+(define-public gctp
+  (package
+    (name "gctp")
+    (version "1.0")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append "ftp://edhs1.gsfc.nasa.gov/edhs/hdfeos5/latest_release/HDF-EOS5.1.15.tar.Z"))
+              (sha256
+               (base32
+                "1p83333nzzy8rn5chxlm0hrkjjnhh2w1ji8ac0f9q4xzg838i58i"))
+              (patches (search-patches "gctp-build-shared.patch" "gctp-remove-hdf-eos5.patch" "gctp-fix-soname.patch"))
+              ))
+    (native-inputs
+     `(("autoconf" ,autoconf)
+       ("automake" ,automake)
+       ("libtool" ,libtool)
+       ("coreutils" ,coreutils)))
+    (build-system gnu-build-system)
+    (arguments
+     `(#:configure-flags '("--enable-install-include")
+       #:phases
+       (modify-phases %standard-phases
+         (add-before
+             'configure 'autogen
+           (lambda _
+             (and (zero? (system* "chmod" "-R" "u+w" ".")) ; archive is read-only...
+                  (zero? (system* "autoreconf" "--install")))))))) ; configure.ac was patched
+    (synopsis "General Cartographic Transformation Package (GCTP)")
+    (description
+     "The General Cartographic Transformation Package (GCTP) is a system of
+software routines designed to permit the transformation of coordinate pairs
+from one map projection to another.  The GCTP is the standard computer
+software used by the National Mapping Division for map projection
+computations.")
+    (home-page "http://gcmd.nasa.gov/records/USGS-GCTP.html")
+    (license (license:bsd-style "http://gcmd.nasa.gov/records/USGS-GCTP.html"))))
+
 (define-public hdf5
   (package
     (name "hdf5")
diff --git a/gnu/packages/patches/gctp-build-shared.patch b/gnu/packages/patches/gctp-build-shared.patch
new file mode 100644
index 0000000..1139fbb
--- /dev/null
+++ b/gnu/packages/patches/gctp-build-shared.patch
@@ -0,0 +1,84 @@ 
+Allow shared build.
+
+---
+ Makefile.am             |  6 ------
+ configure.ac            | 12 ------------
+ include/HE5_HdfEosDef.h |  1 +
+ src/Makefile.am         |  3 ++-
+ 4 files changed, 3 insertions(+), 19 deletions(-)
+
+diff --git a/Makefile.am b/Makefile.am
+index 363bcfb..01ed024 100644
+--- a/Makefile.am
++++ b/Makefile.am
+@@ -3,13 +3,7 @@
+ # Include boilerplate
+ include $(top_srcdir)/config/include.am
+ 
+-# List of subdirectories.
+-# Only build the testdrivers directory if configure detected that it's present.
+-if TESTDRIVERS_CONDITIONAL
+-TESTDRIVERS=testdrivers
+-else
+ TESTDRIVERS=
+-endif
+ 
+ if INSTALL_INCLUDE_CONDITIONAL
+ INCLUDE=include
+diff --git a/configure.ac b/configure.ac
+index 5d48b43..cfa9d4e 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -13,9 +13,6 @@ AC_CONFIG_AUX_DIR([config])
+ AM_INIT_AUTOMAKE([foreign])
+ AM_MAINTAINER_MODE
+ 
+-# Disable shared libraries (for now)
+-AC_DISABLE_SHARED
+-
+ AM_PROG_LIBTOOL
+ 
+ dnl ----------------------------------------------------------------------
+@@ -597,13 +594,4 @@ AC_CONFIG_FILES([Makefile
+                  gctp/src/Makefile
+                  samples/Makefile])
+ 
+-if test "X$TESTDRIVERS_DIR" = "Xyes"; then
+-  AC_CONFIG_FILES([ testdrivers/Makefile
+-                 testdrivers/grid/Makefile
+-                 testdrivers/point/Makefile
+-                 testdrivers/swath/Makefile
+-                 testdrivers/threads/Makefile
+-                 testdrivers/za/Makefile])
+-fi
+-
+ AC_OUTPUT
+diff --git a/include/HE5_HdfEosDef.h b/include/HE5_HdfEosDef.h
+index 9ed7881..abf0a90 100755
+--- a/include/HE5_HdfEosDef.h
++++ b/include/HE5_HdfEosDef.h
+@@ -24,6 +24,7 @@
+ #ifndef HE5_HDFEOSDEF_H_
+ #define HE5_HDFEOSDEF_H_
+ 
++#define H5_USE_16_API 1
+ #include <hdf5.h>
+ 
+ #ifdef H5_USE_16_API
+diff --git a/src/Makefile.am b/src/Makefile.am
+index 76b1d4c..daf7ad8 100644
+--- a/src/Makefile.am
++++ b/src/Makefile.am
+@@ -10,7 +10,8 @@ INCLUDES=-I$(top_srcdir)/include/
+ 
+ # Set LDFLAGS to allow the HDF-EOS library to use extern variables from
+ # HDF5
+-LDFLAGS=-Wl,-single_module
++LDFLAGS+= -shrext .so
++LIBS+= -lhdf5_hl -lhdf5 -lm
+ 
+ # Build HDF-EOS5
+ lib_LTLIBRARIES=libhe5_hdfeos.la
+-- 
+2.5.0
+
diff --git a/gnu/packages/patches/gctp-fix-soname.patch b/gnu/packages/patches/gctp-fix-soname.patch
new file mode 100644
index 0000000..5a32970
--- /dev/null
+++ b/gnu/packages/patches/gctp-fix-soname.patch
@@ -0,0 +1,31 @@ 
+Make library name all-lowercase.
+
+---
+ gctp/src/Makefile.am | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/gctp/src/Makefile.am b/gctp/src/Makefile.am
+index 76ecf1c..97c2438 100755
+--- a/gctp/src/Makefile.am
++++ b/gctp/src/Makefile.am
+@@ -4,7 +4,7 @@
+ include $(top_srcdir)/config/include.am
+ 
+ # Library to build
+-lib_LTLIBRARIES = libGctp.la
++lib_LTLIBRARIES = libgctp.la
+ 
+ ## Normally DEFAULT_INCLUDES is supplied by Automake, but one of the
+ ## directories included by default is $(top_builddir)/include, which
+@@ -17,7 +17,7 @@ DEFAULT_INCLUDES = -I. -I$(srcdir)
+ INCLUDES=-I$(srcdir)/../include/
+ 
+ # Library source files
+-libGctp_la_SOURCES = gctp.c alberfor.c alberinv.c alconfor.c alconinv.c      \
++libgctp_la_SOURCES = gctp.c alberfor.c alberinv.c alconfor.c alconinv.c      \
+           azimfor.c aziminv.c bceafor.c bceainv.c br_gctp.c ceafor.c         \
+           ceainv.c cproj.c eqconfor.c eqconinv.c equifor.c equiinv.c         \
+           for_init.c gnomfor.c gnominv.c goodfor.c goodinv.c gvnspfor.c      \
+-- 
+2.5.0
+
diff --git a/gnu/packages/patches/gctp-remove-hdf-eos5.patch b/gnu/packages/patches/gctp-remove-hdf-eos5.patch
new file mode 100644
index 0000000..4601c5f
--- /dev/null
+++ b/gnu/packages/patches/gctp-remove-hdf-eos5.patch
@@ -0,0 +1,482 @@ 
+From c206a99fc4692ef9ea48a11bbb9de8a7dd44a7f8 Mon Sep 17 00:00:00 2001
+From: Thomas Danckaert <thomas.danckaert@gmail.com>
+Date: Fri, 17 Jun 2016 07:55:58 +0200
+Subject: [PATCH 1/2] Build only GCTP.
+
+---
+ Makefile.am  |   2 +-
+ configure.ac | 430 +----------------------------------------------------------
+ 2 files changed, 2 insertions(+), 430 deletions(-)
+
+diff --git a/Makefile.am b/Makefile.am
+index 01ed024..335cf1a 100644
+--- a/Makefile.am
++++ b/Makefile.am
+@@ -11,5 +11,5 @@ else
+ INCLUDE=
+ endif
+ 
+-SUBDIRS=gctp src $(INCLUDE) samples $(TESTDRIVERS)
++SUBDIRS=gctp
+ 
+diff --git a/configure.ac b/configure.ac
+index cfa9d4e..2b531e4 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -22,80 +22,6 @@ AC_PREFIX_DEFAULT([`pwd`/hdfeos5])
+ # Check for the math library that HDF5 needs
+ AC_CHECK_LIB([m], [ceil])
+ 
+-# Check whether zlib is enabled.
+-# HDF-EOS5 doesn't use zlib, but HDF5 might.  If HDF5 does, it needs
+-# to be given to the linker or there will be undefined symbols in HDF5.
+-# Using h5cc avoids the need to specify zlib at configure time.
+-AC_ARG_WITH([zlib],
+-            [AC_HELP_STRING([--with-zlib=DIR],
+-                            [Specify path to external zlib library.
+-                             Linker must be able to find zlib if HDF5
+-                             was built with zlib.
+-                             [default=yes]])],,
+-            withval=yes)
+-
+-case $withval in
+-  yes)
+-    HAVE_ZLIB="yes"
+-    AC_CHECK_HEADERS([zlib.h],)
+-    AC_CHECK_LIB([z], [compress2],, [unset HAVE_ZLIB])
+-
+-    if test -z "$HAVE_ZLIB"; then
+-      AC_MSG_ERROR([couldn't find zlib library])
+-    fi
+-    ;;
+-  no)
+-    HAVE_ZLIB="no"
+-    AC_MSG_CHECKING([for GNU zlib])
+-    AC_MSG_RESULT([suppressed])
+-    ;;
+-  *)
+-    HAVE_ZLIB="yes"
+-    case "$withval" in
+-      *,*)
+-        zlib_inc="`echo $withval |cut -f1 -d,`"
+-        zlib_lib="`echo $withval |cut -f2 -d, -s`"
+-        ;;
+-      *)
+-        if test -n "$withval"; then
+-          zlib_inc="$withval/include"
+-          zlib_lib="$withval/lib"
+-        fi
+-        ;;
+-    esac
+-
+-    dnl Trying to include -I/usr/include and -L/usr/lib is redundant and
+-    dnl can mess some compilers up.
+-    if test "X$zlib_inc" = "X/usr/include"; then
+-      zlib_inc=""
+-    fi
+-    if test "X$zlib_lib" = "X/usr/lib"; then
+-      zlib_lib=""
+-    fi
+-
+-    saved_CPPFLAGS="$CPPFLAGS"
+-    saved_LDFLAGS="$LDFLAGS"
+-
+-    if test -n "$zlib_inc"; then
+-      CPPFLAGS="$CPPFLAGS -I$zlib_inc"
+-    fi
+-
+-    AC_CHECK_HEADERS([zlib.h], ,
+-                     [CPPFLAGS="$saved_CPPFLAGS"])
+-
+-    if test -n "$zlib_lib"; then
+-      LDFLAGS="$LDFLAGS -L$zlib_lib"
+-    fi
+-
+-    AC_CHECK_LIB([z], [compress2],,
+-                 [LDFLAGS="$saved_LDFLAGS"; unset HAVE_ZLIB])
+-
+-    if test -z "$HAVE_ZLIB"; then
+-      AC_MSG_ERROR([couldn't find zlib library])
+-    fi
+-    ;;
+-esac
+-
+ dnl --------------------------------------------------
+ dnl Check if -Df2cFortran is specified
+ dnl Running only the preprocessor may not be a good idea
+@@ -172,356 +98,6 @@ if test ${he5_cv_f2cFortran_defined} = "yes"; then
+   fi
+ fi
+ 
+-# Check whether szlib (szip) is enabled.
+-# HDF-EOS5 doesn't use szlib, but HDF5 might.  If HDF5 does, it needs
+-# to be given to the linker or there will be undefined symbols in HDF5.
+-# Using h5cc should avoid the need to specify szlib at configure time.
+-AC_ARG_WITH([szlib],
+-            [AC_HELP_STRING([--with-szlib=DIR],
+-                            [Use szlib library for external szlib I/O
+-                             filter.  Linker must be able to find szlib
+-                             if HDF5 was build with szip. [default=no]])],,
+-            withval=no)
+-
+-case $withval in
+-  yes)
+-    HAVE_SZLIB="yes"
+-    AC_CHECK_HEADERS([szlib.h], [HAVE_SZLIB_H="yes"])
+-    AC_CHECK_LIB([sz], [SZ_BufftoBuffCompress],, [unset HAVE_SZLIB])
+-
+-    if test -z "$HAVE_SZLIB"; then
+-      AC_MSG_ERROR([couldn't find szlib library, you may need to specify szip library path])
+-    fi
+-    ;;
+-  no)
+-    HAVE_SZLIB="no"
+-    AC_MSG_CHECKING([for szlib])
+-    AC_MSG_RESULT([suppressed])
+-    ;;
+-  *)
+-    HAVE_SZLIB="yes"
+-    case "$withval" in
+-      *,*)
+-        szlib_inc="`echo $withval |cut -f1 -d,`"
+-        szlib_lib="`echo $withval |cut -f2 -d, -s`"
+-        ;;
+-      *)
+-        if test -n "$withval"; then
+-          szlib_inc="$withval/include"
+-          szlib_lib="$withval/lib"
+-        fi
+-        ;;
+-    esac
+-
+-    dnl Check if szlib.h exists. We cannot use AC_CHECK_HEADERS here
+-    dnl because it will use preprocessor. Preprocessor always succeeds in
+-    dnl finding szlib.h because h4cc provides the path to szlib.h.
+-    AC_CHECK_FILE($szlib_inc/szlib.h, , [unset HAVE_SZLIB])
+-    if test -z "$HAVE_SZLIB"; then
+-      AC_MSG_ERROR([couldn't find szlib.h, check szip library path])
+-    fi
+-    
+-    dnl Trying to include -I/usr/include and -L/usr/lib is redundant and
+-    dnl can mess some compilers up.
+-    if test "X$szlib_inc" = "X/usr/include"; then
+-      szlib_inc=""
+-    fi 
+-    if test "X$szlib_lib" = "X/usr/lib"; then
+-      szlib_lib=""
+-    fi
+-    
+-    saved_CPPFLAGS="$CPPFLAGS"
+-    saved_LDFLAGS="$LDFLAGS"
+-    
+-    if test -n "$szlib_inc"; then
+-      CPPFLAGS="$CPPFLAGS -I$szlib_inc"
+-    fi
+-    
+-    AC_CHECK_HEADERS([szlib.h],
+-                     [HAVE_SZLIB_H="yes"],
+-                     [CPPFLAGS="$saved_CPPFLAGS"])
+-    
+-    if test -n "$szlib_lib"; then
+-      LDFLAGS="$LDFLAGS -L$szlib_lib"
+-    fi
+-    
+-    AC_CHECK_LIB([sz], [SZ_BufftoBuffCompress],,
+-                 [LDFLAGS="$saved_LDFLAGS"; unset HAVE_SZLIB])
+-    
+-    if test -z "$HAVE_SZLIB" -a -n "$HDF5_CONFIG_ABORT"; then
+-      AC_MSG_ERROR([couldn't find szlib library, check if szip library is valid])
+-    fi
+-    ;;
+-esac
+-
+-
+-if test "X$HAVE_SZLIB" = "Xyes"; then
+-    dnl SZLIB library is available.  Check if it can encode
+-
+-    dnl Given that user specifies h5cc, LDFLAGS in h5cc should be overriden; otherwise,
+-    dnl the encoding test will be performed on the SZIP library linked with HDF5, not
+-    dnl the SZIP library user specifies. To suppress the SZIP library linked with HDF5,
+-    dnl we prepend the user-specified SZIP library path to LDFLAGS in h5cc by using awk.
+-
+-    AC_PROG_AWK
+-
+-    AC_MSG_CHECKING([for h5cc])
+-    PURE_CC=""
+-    if ($CC -show &> /dev/null); then
+-	dnl Since CC can be "h5cc -Df2cFortran", arguments should be removed
+-	PURE_CC=`echo "$CC" | $AWK '{ split($1, array, " ") ; printf array[[1]] }'`
+-	AC_MSG_RESULT([$PURE_CC])
+-    else
+-	AC_MSG_RESULT([$CC])
+-	AC_MSG_ERROR([CC is not h5cc])
+-    fi
+-
+-    SZIP_CC=szip_cc
+-    cat $PURE_CC | $AWK '{ if ( $0 ~ /^LDFLAGS=\"(.*)/ ) { print substr($0, 1, 9) " -L'$szlib_lib' " substr($0, 10) } else  { print } } ' > $SZIP_CC
+-    chmod 755 $SZIP_CC
+-    saved_CC="$CC"
+-    CC=./$SZIP_CC
+-
+-    AC_MSG_CHECKING([for szlib encoder])
+-
+-    AC_CACHE_VAL([he5_cv_szlib_functional],
+-        [AC_TRY_RUN([
+-	#include <stddef.h>
+-        #include <szlib.h>
+-
+-        int main(void)
+-        {
+-            SZ_encoder_enabled();
+-            exit(0);
+-        }
+-        ], [he5_cv_szlib_functional=yes], [he5_cv_szlib_functional=no],)])
+-
+-    AC_CACHE_VAL([he5_cv_szlib_can_encode],
+-        [AC_TRY_RUN([
+-	#include <stddef.h>
+-        #include <szlib.h>
+-
+-        int main(void)
+-        {
+-            /* SZ_encoder_enabled returns 1 if encoder is present */
+-            if(SZ_encoder_enabled() == 1)
+-                exit(0);
+-            else
+-                exit(1);
+-        }
+-        ], [he5_cv_szlib_can_encode=yes], [he5_cv_szlib_can_encode=no],)])
+-
+-    CC="$saved_CC"
+-    rm -f $SZIP_CC
+-
+-    if test ${he5_cv_szlib_functional} = "no"; then
+-        he5_cv_szlib_can_encode=broken
+-    else
+-        AC_DEFINE(HAVE_FILTER_SZIP, 1,
+-                [Define if support for szip filter is enabled])
+-        USE_FILTER_SZIP="yes"
+-    fi
+-
+-    if test ${he5_cv_szlib_can_encode} = "yes"; then
+-    	AC_DEFINE(HAVE_FILTER_SZIP_ENCODER, 1,
+-		[Define if support for szip encoder filter is enabled])
+-	USE_SZIP_ENCODER="yes"
+-        AC_MSG_RESULT([yes])
+-    fi
+-    if test ${he5_cv_szlib_can_encode} = "no"; then
+-        AC_MSG_RESULT([no])
+-    fi
+-    if test ${he5_cv_szlib_can_encode} = "broken"; then
+-        AC_MSG_RESULT([shared szlib doesn't work. disabling szip.])
+-    fi
+-
+-    dnl Add "szip" to external filter list
+-    if test ${he5_cv_szlib_can_encode} = "yes"; then
+-        if test "X$EXTERNAL_FILTERS" != "X"; then
+-            EXTERNAL_FILTERS="${EXTERNAL_FILTERS},"
+-        fi
+-        EXTERNAL_FILTERS="${EXTERNAL_FILTERS}szip(encoder)"
+-    fi
+-    if test ${he5_cv_szlib_can_encode} = "no"; then
+-        if test "X$EXTERNAL_FILTERS" != "X"; then
+-            EXTERNAL_FILTERS="${EXTERNAL_FILTERS},"
+-        fi
+-        EXTERNAL_FILTERS="${EXTERNAL_FILTERS}szip(no encoder)"
+-    fi
+-fi
+-
+-# Check for the HDF5 library using the --with argument
+-# Of course HDF5 is required, but the user may be using h5cc, in which case
+-# they don't need to specify --with-hdf5.  They can also use
+-# --with-hdf5=/path/to/hdf5 to give a specific path.
+-HAVE_HDF5="yes"
+-AC_ARG_WITH([hdf5],
+-            [AC_HELP_STRING([--with-hdf5=DIR],
+-                            [Specify path to HDF5 library to use while building
+-                            [default=yes]])],,
+-            withval=yes)
+-
+-case $withval in
+-  yes)
+-    ;;
+-  no)
+-    AC_MSG_ERROR([HDF5 disabled in confugre, but is required to build HDF-EOS5.])
+-    ;;
+-  *)
+-    case "$withval" in
+-      *,*)
+-        hdf5_inc="`echo $withval |cut -f1 -d,`"
+-        hdf5_lib="`echo $withval |cut -f2 -d, -s`"
+-        ;;
+-      *)
+-        if test -n "$withval"; then
+-          hdf5_inc="$withval/include"
+-          hdf5_lib="$withval/lib"
+-        fi
+-        ;;
+-    esac
+-
+-    dnl Trying to include -I/usr/include and -L/usr/lib is redundant and
+-    dnl can mess some compilers up.
+-    if test "X$hdf5_inc" = "X/usr/include"; then
+-      hdf5_inc=""
+-    fi
+-    if test "X$hdf5_lib" = "X/usr/lib"; then
+-      hdf5_lib=""
+-    fi
+-
+-    if test -n "$hdf5_inc"; then
+-      CPPFLAGS="$CPPFLAGS -I$hdf5_inc"
+-      CFLAGS="$CFLAGS -I$hdf5_inc"
+-    fi
+-
+-    if test -n "$hdf5_lib"; then
+-      LDFLAGS="$LDFLAGS -L$hdf5_lib"
+-    fi
+-    ;;
+-esac
+-
+-dnl See if we have a valid linking path to the HDF5 library, either because
+-dnl it's in the user's path or because they provided the correct path using
+-dnl --with-hdf5
+-AC_CHECK_HEADERS([hdf5.h], , [HAVE_HDF5="no"])
+-AC_CHECK_LIB(hdf5, H5Fcreate,, [HAVE_HDF5="no"])
+-
+-if test "X$HAVE_HDF5" = "Xno"; then
+-  AC_MSG_ERROR([can't link against HDF5 library])
+-fi
+-
+-
+-# Check whether HDF5 threadsafety is enabled
+-AC_MSG_CHECKING([if HDF5 threadsafe mode is enabled])
+-AC_TRY_RUN([
+-#include "hdf5.h"
+-
+-int main(void) {
+-#ifdef H5_HAVE_THREADSAFE
+-  return 0;
+-#else
+-  return 1;
+-#endif
+-} ], 
+-  [ AC_MSG_RESULT([yes])
+-    THREADSAFE="yes"],
+-  [AC_MSG_RESULT([no])
+-    THREADSAFE="no"])
+-
+-# Record threadsafe status in config.h and for Makefiles
+-if test "X$THREADSAFE" = "Xyes"; then
+-  AC_DEFINE([_HDFEOS5_THREADSAFE], [1],
+-            [Define if threadsafe HDF-EOS is enabled])
+-fi
+-
+-AM_CONDITIONAL([THREADSAFE_CONDITIONAL], [test "X$THREADSAFE" = "Xyes"])
+-
+-
+-if test "x$HAVE_HDF5" = "xyes"; then
+-  dnl Check if HDF5 is linked with SZIP encoder
+-
+-  AC_MSG_CHECKING([for hdf5 szip decoding filter])
+-  AC_CACHE_VAL([he5_cv_hdf5_szip_can_decode],
+-      [AC_TRY_RUN([
+-      #include <H5Ipublic.h>
+-      #include <H5Zpublic.h>
+-      
+-      int main(int argc, char **argv)
+-      {
+-              herr_t ret;
+-              unsigned int flags = 0;
+-              int decoder = 0;
+-      
+-              ret = H5Zget_filter_info(H5Z_FILTER_SZIP, &flags);
+-	      if (ret < 0) exit(1);
+-              decoder = flags & H5Z_FILTER_CONFIG_DECODE_ENABLED;
+-              if (decoder) exit(0);
+-              else exit(1);
+-      }
+-      ], [he5_cv_hdf5_szip_can_decode=yes], [he5_cv_hdf5_szip_can_decode=no],)])
+-  if test ${he5_cv_hdf5_szip_can_decode} = "yes"; then
+-    AC_DEFINE(HAVE_HDF5_SZIP_DECODER, 1,
+-	    [Define if HDF5 has szip decoder filter])
+-    AC_DEFINE(H5_HAVE_FILTER_SZIP, 1,
+-	    [Define if HDF5 has szip any type of filter])
+-    AC_MSG_RESULT([yes])
+-  else
+-    AC_MSG_RESULT([no])
+-  fi
+-
+-  AC_MSG_CHECKING([for hdf5 szip encoding filter])
+-  AC_CACHE_VAL([he5_cv_hdf5_szip_can_encode],
+-      [AC_TRY_RUN([
+-      #include <H5Ipublic.h>
+-      #include <H5Zpublic.h>
+-      
+-      int main(int argc, char **argv)
+-      {
+-              herr_t ret;
+-              unsigned int flags = 0;
+-              int encoder = 0;
+-      
+-              ret = H5Zget_filter_info(H5Z_FILTER_SZIP, &flags);
+-	      if (ret < 0) exit(1);
+-              encoder = flags & H5Z_FILTER_CONFIG_ENCODE_ENABLED;
+-              if (encoder) exit(0);
+-              else exit(1);
+-      }
+-      ], [he5_cv_hdf5_szip_can_encode=yes], [he5_cv_hdf5_szip_can_encode=no],)])
+-
+-  if test ${he5_cv_hdf5_szip_can_encode} = "yes"; then
+-    AC_DEFINE(HAVE_HDF5_SZIP_ENCODER, 1,
+-	    [Define if HDF5 has szip encoder filter])
+-    AC_MSG_RESULT([yes])
+-  else
+-    AC_MSG_RESULT([no])
+-  fi
+-
+-  dnl Check if SZIP linked with HDF5 has the same configuration as SZIP given by --with-szlib option has
+-  if test ${he5_cv_hdf5_szip_can_decode} = "no"; then
+-    if test "X$HAVE_SZLIB" = "Xyes"; then
+-      AC_MSG_ERROR([HDF5 was linked without SZIP, but --with-szlib was given])
+-    fi
+-  else
+-    if test "X$HAVE_SZLIB" != "Xyes"; then
+-      AC_MSG_ERROR([HDF5 was linked with SZIP, but --with-szlib was not given])
+-    fi
+-    if test ${he5_cv_szlib_functional} = "no"; then
+-      AC_MSG_ERROR([SZIP specified in --with-szlib is not functional])
+-    fi
+-    if test ${he5_cv_hdf5_szip_can_encode} = "no"; then
+-      if test ${he5_cv_szlib_can_encode} = "yes"; then
+-	AC_MSG_ERROR([HDF5 was linked without SZIP encoder, but yours has SZIP encoder])
+-      fi
+-    else
+-      if test ${he5_cv_szlib_can_encode} = "no"; then
+-	AC_MSG_ERROR([HDF5 was linked with SZIP encoder, but yours does not have SZIP encoder])
+-      fi
+-    fi
+-  fi
+-fi
+-
+ # Set CFLAGS to prevent AC_PROG_CC from setting it
+ CFLAGS=$CFLAGS
+ 
+@@ -584,14 +160,10 @@ AM_CONDITIONAL([INSTALL_INCLUDE_CONDITIONAL], [test "X$INSTALL_INCLUDE" = "Xyes"
+ AM_CONDITIONAL([F2CFORTRAN_CONDITIONAL], [test "X$F2CFORTRAN_MACRO" = "Xyes"])
+ AM_CONDITIONAL([F2CFORTRAN_90_CONDITIONAL], [test "X$F2CFORTRAN_90" = "Xyes"])
+ AM_CONDITIONAL([F2CFORTRAN_32PTR_CONDITIONAL], [test "X$F2CFORTRAN_32PTR" = "Xyes"])
+-AM_CONDITIONAL([SZIP_ENCODER_CONDITIONAL], [test "X$USE_SZIP_ENCODER" = "Xyes"])
+ 
+ AC_CONFIG_FILES([Makefile
+-                 include/Makefile
+-                 src/Makefile
+                  gctp/Makefile
+                  gctp/include/Makefile
+-                 gctp/src/Makefile
+-                 samples/Makefile])
++                 gctp/src/Makefile])
+ 
+ AC_OUTPUT
+-- 
+2.5.0
+
-- 
2.5.0