[Octave-bug-tracker] [bug #45509] communications-1.2.1 fails during package install in octave-4.0.0

[anonymous]

Follow-up Comment #9, bug #45509 (project octave):

Any chance a resolution ever came from the mailing list thread (if one was
created)?

I'm having something similar on CentOS 6.6 64-bit between two systems (i.e.,
comment #7).  

One system, this error somehow resolved itself over a configure-make battery
of reinstalling after apparently making no changes to the OS (looking at my
bash history and my notes on the matter).  

Now on a new system, I've gone through my notes and repeated everything, but
the communications package still will not compile correctly against HDF5 (so
far as I can tell).  The primary differences between the two systems when
installing the communications package (-verbose) is below:

pkg install -forge communications -verbose
mkdir (/tmp/oct-eaXuh5)
untar (/root/communications-1.2.1.tar.gz, /tmp/oct-eaXuh5)
checking for mkoctfile... /usr/local/bin/mkoctfile-4.0.0 --verbose
checking for octave... /usr/local/bin/octave-4.0.0
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for a sed that does not truncate output... /bin/sed
checking for Octave HDF5 preprocessor flags... 
checking for Octave HDF5 linker flags... 
checking for Octave HDF5 libraries... -lhdf5
checking for octave_hdf5_id type... no
checking for octave_base_value::gripe_load and
octave_base_value::gripe_save... no



Those last 2 lines are 'yes' on the working system.  That difference then
tacks on '-DHAVE_OCTAVE_HDF5_ID_TYPE=1' and
'-DHAVE_OCTAVE_BASE_VALUE_GRIPE_LOAD_SAVE=1' to the compiler commands.  So in
that much, this issue is similar to the one in comment #2 in that perhaps
installation should abort when these flags are 'no' rather than proceed,
because ultimately this error occurs:

In file included from gf.cc:41:
ov-galois.h:41: error: ‘hid_t’ does not name a type
g++ -shared -Wl,-Bsymbolic  -o genqamdemod.oct  genqamdemod.o  
-L/usr/local/lib/octave/4.0.0 -L/usr/local/lib -loctinterp -loctave
make: *** [gf.o] Error 1
make: *** Waiting for unfinished jobs....
In file included from op-gm-gm.cc:26:
ov-galois.h:41: error: ‘hid_t’ does not name a type
make: *** [op-gm-gm.o] Error 1
make: Leaving directory `/tmp/oct-TGVEyR/communications-1.2.1/src'


So in essence, having HAVE_OCTAVE_HDF5_ID_TYPE _not_ defined and HAVE_HDF5
defined results in somehow not having access to that type in hdf5 even though
Octave's configure log indicates it found a usable version of hdf5.

I have the same versions of 'hdf5', 'hdf5-devel', and 'hdf5-static' packages
installed on both systems.  I've also verified the file from comment #4 is the
same in both cases.  The the only set of HDF5 flag that Octave defined during
compilation is '-lhdf5' (as shown above).

I've tried looking at the 'configure.ac' file for the communications package,
but I'm having trouble tracing back how to get both of those flags to be true
(so that I can test to see if whatever drives that would solve this for me).

Where should I start looking for how to get those flags to be set?



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45509>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/