[hdf-java] 2.5_p3 broken on unix

Hdf-forum archives
1

Compiling hdf-java-2.5_p3 gives me
  make: *** No rule to make target
`ext/npoess/DataOptionNPOESS.class', needed by `ext.npoess'. Stop.
while 2.5_p2 works fine.

A diff between the two source directories tells me something a about
classes with the term "NPOESS" in it, but
$ find|grep -i NPOESS
$
shows there is no such thing mentioned in the source tree

Best,
-- Maik

PS: I got p2 to build after overriding the value of LLEXT in configure
to be "so" rather than "a", because I like to avoid compiling every
static lib with fPIC. Is there any reason for linking a against the
static libs beside the convenience of deploying static binaries?

2

Hello Maik,

Compiling hdf-java-2.5_p3 gives me
make: *** No rule to make target
`ext/npoess/DataOptionNPOESS.class', needed by `ext.npoess'. Stop.
while 2.5_p2 works fine.

A diff between the two source directories tells me something a about
classes with the term "NPOESS" in it, but
$ find|grep -i NPOESS
$
shows there is no such thing mentioned in the source tree

Yes, the NPOESS package should not be required. This will be fixed in
the next release of HDFView.

In order to get around this problem you can remove the npoess package
from the Makefile. For an example, here are the steps from doing
this on the Macintosh:

  1) Delete the npoess-package from Makefile.in line 120. The
     correct line will look like:
     packages: jhdf-packages jhdf5-packages nc2-packages fits-packages
       jhdfobj-packages jhdfview-packages

  2) Delete line 331
  $(JAR) cf $(JH45INSTALLDIR)/lib/ext/npoess.jar $(NPOESSCLASSES)

  3) Run config.sh. The config.sh looks like (examples are located at Config/)

···

############################################################
# macintel (tejeda) #
############################################################
INSTDIR=/tmp/hdf-java/build
JAVAINC=/System/Library/Frameworks/JavaVM.framework/Headers
JAVALIB=/System/Library/Frameworks/JavaVM.framework/Libraries
HDF4=/Users/xcao/work/build/hdf4
HDF5=/Users/xcao/work/build/hdf5
JPEG=/Users/xcao/work/lib-external/jpeg-6b
SZIP=/Users/xcao/work/lib-external/szip-2.1
ZLIB=/Users/xcao/work/lib-external/zlib-1.2.1
EXTRA_FLAGS="-build=powerpc-apple
--with-jdkclasses=/System/Library/Frameworks/JavaVM.framework/Classes
--with-javabin=/System/L
ibrary/Frameworks/JavaVM.framework/Commands"

4) Do "make; make install; make check"

5) if all works, you will find hdfview under INSTDIR

PS: I got p2 to build after overriding the value of LLEXT in configure
to be "so" rather than "a", because I like to avoid compiling every
static lib with fPIC. Is there any reason for linking a against the
static libs beside the convenience of deploying static binaries?

If you can get this to work, then it is probably okay. We don't test
this as the JNI is also a shared library.

-Barbara

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Barbara Jones
The HDF Helpdesk

The HDF Group
help@hdfgroup.org
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

3

Hello Maik,

Thanks for the quick response!

Compiling hdf-java-2.5_p3 gives me
make: *** No rule to make target
`ext/npoess/DataOptionNPOESS.class', needed by `ext.npoess'. Stop.
while 2.5_p2 works fine.

A diff between the two source directories tells me something a about
classes with the term "NPOESS" in it, but
$ find|grep -i NPOESS
$
shows there is no such thing mentioned in the source tree

Yes, the NPOESS package should not be required. This will be fixed in
the next release of HDFView.

In order to get around this problem you can remove the npoess package
from the Makefile. For an example, here are the steps from doing
this on the Macintosh:

As I didn't run into problems so far I'll stick with p2 until p4 is out.

PS: I got p2 to build after overriding the value of LLEXT in configure
to be "so" rather than "a", because I like to avoid compiling every
static lib with fPIC. Is there any reason for linking a against the
static libs beside the convenience of deploying static binaries?

If you can get this to work, then it is probably okay. We don't test
this as the JNI is also a shared library.

So you're configure hdf-java to build against static libs since JNI is
also a shared library?

Interesting :wink:

Greetings,
-- Maik

PS: if --prefix=/some/path/ and /some/path doesn't exist yet,
configure fails. I never came across this behavior so far and it did
bite me when packaging hdf-java for my distro. Is this by intention?

···

2009/10/7 Barbara Jones <bljones@hdfgroup.org>:

4

Hello,

I'm using hdf5 version 1.8.3 and I'd like to know if there is any API to test whether an object exists by its name.

The attribute API has an "exists" function.
But for groups and datasets, we have to open the object and test the return value.
However, HDF5 returns also some errors on stderr.

Is there any way to test object existence without HDF5 complains on stderr ?

Thanks a lot,

Cyril.

5

Hi Maik,

As Barbara pointed out, building JNI from shared libraries may work for you.
However, when you move what you build to a different machine, it may cause
problem because of some path problem in the shared libraries, at least we
know that there are problems on mac machines.

Thanks
--pc

···

If you can get this to work, then it is probably okay. We don't test
this as the JNI is also a shared library.
    
So you're configure hdf-java to build against static libs since JNI is
also a shared library?

Interesting :wink:

Greetings,
-- Maik

PS: if --prefix=/some/path/ and /some/path doesn't exist yet,
configure fails. I never came across this behavior so far and it did
bite me when packaging hdf-java for my distro. Is this by intention?

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org

6

Is there an configure option to build against the shared libs? This
would be the preferred way on linux distributions, since the packagers
build from source anyway.

Best,
-- Maik

···

2009/10/7 Peter Cao <xcao@hdfgroup.org>:

Hi Maik,

As Barbara pointed out, building JNI from shared libraries may work for you.
However, when you move what you build to a different machine, it may cause
problem because of some path problem in the shared libraries, at least we
know that there are problems on mac machines.

Thanks
--pc

7

Hi Cyril,

Please try H5Lexists http://www.hdfgroup.org/HDF5/doc/RM/RM_H5L.html#Link-Exists

Elena

···

On Oct 7, 2009, at 12:50 PM, cyril.giraudon@free.fr wrote:

Hello,

I'm using hdf5 version 1.8.3 and I'd like to know if there is any API to test whether an object exists by its name.

The attribute API has an "exists" function.
But for groups and datasets, we have to open the object and test the return value.
However, HDF5 returns also some errors on stderr.

Is there any way to test object existence without HDF5 complains on stderr ?

Thanks a lot,

Cyril.

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org

8

Hi Maik,

Since we know that linking shared libraries inside the HDF5 JNI shared
library does not work, we will not add the option to the configuration file for now.
If you would like to try, change LLEXT from "a" to "so" at native/hdf5lib/Makefile
and give it a shot.

If it compiles (most likely it will), remember to set your LD_LIBRARY_PATH
before you run any tests.

Thanks
--pc

Maik Beckmann wrote:

···

2009/10/7 Peter Cao <xcao@hdfgroup.org>:
  

Hi Maik,

As Barbara pointed out, building JNI from shared libraries may work for you.
However, when you move what you build to a different machine, it may cause
problem because of some path problem in the shared libraries, at least we
know that there are problems on mac machines.

Thanks
--pc
    
Is there an configure option to build against the shared libs? This
would be the preferred way on linux distributions, since the packagers
build from source anyway.

Best,
-- Maik

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org

9

Thanks Elena, it works fine.

Cyril.

----- Mail Original -----

···

De: "Elena Pourmal" <epourmal@hdfgroup.org>
À: hdf-forum@hdfgroup.org
Envoyé: Jeudi 8 Octobre 2009 04h32:42 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne
Objet: Re: [Hdf-forum] Is there an API to test whether an object exsits

Hi Cyril,

Please try H5Lexists http://www.hdfgroup.org/HDF5/doc/RM/RM_H5L.html#Link-Exists

Elena
On Oct 7, 2009, at 12:50 PM, cyril.giraudon@free.fr wrote:

Hello,

I'm using hdf5 version 1.8.3 and I'd like to know if there is any
API to test whether an object exists by its name.

The attribute API has an "exists" function.
But for groups and datasets, we have to open the object and test the
return value.
However, HDF5 returns also some errors on stderr.

Is there any way to test object existence without HDF5 complains on
stderr ?

Thanks a lot,

Cyril.

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org