The HDF project involves the development and support of software and file formats for scientific data management. The HDF software includes I/O libraries and tools for analyzing, visualizing, and converting scientific data. There are two HDF formats, HDF (4.x and previous releases) and HDF5. These formats are completely different and NOT compatible. The HDF software is developed and supported by NCSA and is freely available. It is used world-wide in many fields, including Environmental Science, Neutron Scattering, Non-Destructive Testing, and Aerospace, to name a few. Scientific projects that use HDF include NASA's HDF-EOS project, and the DOE's Advanced Simulation and Computing Program. (text extracted from official site) Reproducible: Always Steps to Reproduce:
Created attachment 12034 [details] Hierarchical Data Format (HDF) version 4 (uncomplete) I couldn't finish this ebuild, I'm using a manual compiled version. The ebuild can compile and install hdf4 but I'm not sure if it's doing everything right. Maybe is a good idea use slot="4" as version 5 isn't backward compatible.
Created attachment 12035 [details] Hierarchical Data Format (HDF) version 5 (uncomplete) Ebuild not finished. Error during ebuild's compiling time, but I compiled manually. Not backward compatible, so could be a good idea use slot="5".
Hi Castel
Hi Castelão. I am testing out your ebuilds, and I cannot build hdf-4. Looks like it bombs out during tests: making `test' in directory /var/tmp/portage/hdf-4.1/work/HDF4.1r5/mfhdf/libsrc make[3]: Entering directory `/var/tmp/portage/hdf-4.1/work/HDF4.1r5/mfhdf/libsrc' Makefile:587: warning: overriding commands for target `/var/tmp/portage/hdf-4.1/image//usr/lib' Makefile:584: warning: ignoring old commands for target `/var/tmp/portage/hdf-4.1/image//usr/lib' Makefile:694: warning: overriding commands for target `/var/tmp/portage/hdf-4.1/image//usr/bin' Makefile:691: warning: ignoring old commands for target `/var/tmp/portage/hdf-4.1/image//usr/bin' Makefile:721: warning: overriding commands for target `/var/tmp/portage/hdf-4.1/image//usr/include' Makefile:718: warning: ignoring old commands for target `/var/tmp/portage/hdf-4.1/image//usr/include' Makefile:783: warning: overriding commands for target `/var/tmp/portage/hdf-4.1/image//usr/man' Makefile:778: warning: ignoring old commands for target `/var/tmp/portage/hdf-4.1/image//usr/man' gcc -c -I/usr/include/rpc -I. -I../../hdf/src/ -I../../mfhdf/libsrc -I../../mfhdf/port -DSWAP -DNDEBUG -DHDF -DNO_STRERROR -ansi -D_BSD_SOURCE cdftest.c ar rcuv libmfhdf.a array.o attr.o cdf.o dim.o file.o iarray.o error.o globdef.o putget.o putgetg.o sharray.o string.o var.o xdrposix.o hdfsds.o mfsd.o nssdc.o ranlib libmfhdf.a gcc -ansi -D_BSD_SOURCE cdftest.o libmfhdf.a ../../hdf/src/libdf.a ../../hdf/jpeg/libjpeg.a -lm ../../hdf/zlib/libz.a -o cdftest libmfhdf.a(error.o)(.text+0x28): In function `strerror': : `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead libmfhdf.a(error.o)(.text+0x11): In function `strerror': : `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead cdftest.o(.text+0xa48): In function `main': : undefined reference to `errno' collect2: ld returned 1 exit status make[3]: *** [cdftest] Error 1 make[3]: Leaving directory `/var/tmp/portage/hdf-4.1/work/HDF4.1r5/mfhdf/libsrc' make[2]: *** [libsrc/test] Error 1 make[2]: Leaving directory `/var/tmp/portage/hdf-4.1/work/HDF4.1r5/mfhdf' make[1]: *** [subdn] Error 2 make[1]: Leaving directory `/var/tmp/portage/hdf-4.1/work/HDF4.1r5' make: *** [test] Error 2 Could you please take a look into this issue? Here are relevant parts of my emerge info: Portage 2.0.48-r1 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1) ================================================================= System uname: 2.4.20-gaming-r3 i686 Pentium III (Coppermine) USE="x86 oss apm avi crypt cups encode gif jpeg gnome libg++ mikmod mmx mpeg ncurses pdflib png quicktime spell truetype xml2 xmms xv zlib alsa gdbm berkdb readline arts tetex aalib nas svga tcltk java guile postgres X sdl gpm tcpd pam libwww ssl perl python imlib oggvorbis gtk qt kde motif opengl mozilla gphoto2 cdr scanner acpi acpi4linux dga directfb dvd fbcon fbdev flash gd ggi glide gpg imap jpilot maildir mcrypt moznocompose moznoirc moznomail nls oav pcmcia pda pic plotutils pnp rage128 samba slp sse tiff trusted usb vim-with-x wavelan wmf Xaw3d xinerama xml xosd -3dnow -gtkhtml -slang -bonobo -ruby -esd" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O2 -pipe -fforce-addr -fomit-frame-pointer -falign-functions=4 -fprefetch-loop-arrays -fexpensive-optimizations -mfpmath=sse" CXXFLAGS="-march=pentium3 -O2 -pipe -fforce-addr -fomit-frame-pointer -falign-functions=4 -fprefetch-loop-arrays -fexpensive-optimizations -mfpmath=sse" ACCEPT_KEYWORDS="~x86 x86" MAKEOPTS="-j2" FEATURES="sandbox digest ccache distcc userpriv usersandbox noauto"
*** Bug 21482 has been marked as a duplicate of this bug. ***
George, Good work. I have tested the hdf5 ebuild on x86 but not alpha or ppc. The KEYWORDS should be modified accordingly. This was the first ebuild I wrote and evidently I didn't have a clue what I was doing. Shaun
Created attachment 13089 [details] modified hdf5 ebuild from #21482 Here goes the ebuild. Unfortunately this one also doesn't compile, and the problem again seems to be related to tests :). Strange thing: upon entering ${S}/c++/test build first creates dsets.o, then moves it to dsets.lo and then cannot find dsets.o ?? :/ Here is the tail of the build: make[3]: Entering directory `/var/tmp/portage/hdf5-1.4.5/work/hdf5-1.4.5-post2/c++/test' g++ -march=pentium3 -O2 -pipe -fforce-addr -fomit-frame-pointer -falign-functions=4 -fprefetch-loop-arrays -fexpensive-optimizations -mfpmath=sse -I. -I../src -I./../src -I../../test -I../../src -I../../src -D_BSD_SOURCE -D_POSIX_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -c dsets.cpp -fPIC -DPIC mv -f dsets.o dsets.lo mkdir .libs libtool: link: warning: `AC_LIBTOOL_DLOPEN' not used. Assuming no dlopen support. rm -f .libs/dsets.nm .libs/dsets.nmS .libs/dsets.nmT creating .libs/dsetsS.c generating symbol list for `dsets' (cd .libs && gcc -c -fno-builtin -fno-rtti -fno-exceptions "dsetsS.c") rm -f .libs/dsetsS.c .libs/dsets.nm .libs/dsets.nmS .libs/dsets.nmT g++ .libs/dsetsS.o -march=pentium3 -O2 -pipe -fforce-addr -fomit-frame-pointer -falign-functions=4 -fprefetch-loop-arrays -fexpensive-optimizations -mfpmath=sse -o dsets dsets.o ../../src/../test/h5test.o ../src/.libs/libhdf5_cpp.a ../../src/.libs/libhdf5.so -lz -lm -Wl,--rpath -Wl,/var/tmp/portage/hdf5-1.4.5/work/hdf5-1.4.5-post2/src/.libs -Wl,--rpath -Wl,/usr/bin g++: dsets.o: No such file or directory rm -f .libs/dsetsS.o make[3]: *** [dsets] Error 1 make[3]: Leaving directory `/var/tmp/portage/hdf5-1.4.5/work/hdf5-1.4.5-post2/c++/test' make[2]: *** [tests] Error 1 make[2]: Leaving directory `/var/tmp/portage/hdf5-1.4.5/work/hdf5-1.4.5-post2/c++' make[1]: *** [tests] Error 1 make[1]: Leaving directory `/var/tmp/portage/hdf5-1.4.5/work/hdf5-1.4.5-post2' make: *** [all] Error
Final comment for today: I am not really sure what to do about hdf vs hdf5. Ideologically this is the same package so both could be accomodated by hdf setting SLOT's accordingly (and making sure they do not collide when installed together). On the other hand, according to description on website the only thing these versions have in common is the idea behind the package. Everything else - library and even formats are different. This is also represented in a different package name - for all purposes hdf!=hdf5 (according to standard GNU naming scheme). Thus technically it is possible to treat these versions as separate packages, in fact it seems to be easier to handle this way. So, I am taking comments on this issue. Perheaps I will post a message to gentoo-dev in a day or two (after the most involved parties will have their say ;)). George PS. WRT above build problems: I tried changing emake to make, to avoid parallel build (sometimes similar problems are caused by that) to no avail. Still got the same error (although rerun with emake produced slightly different output, which prompted me to try such change). So, I am not sure what is the difference - some packages from "testing" profile in my case or CFLAGS slightly on extreme side? Any ideas are appreciated. George
George, Regarding the build problems you experience when building hdf5, I also experience the same failure when building the C++ interface. In my research I have no need for the C++ interface, so have never built it. I will look into it when I get a chance, but perhaps Donald Giuliano who suggested the addition of the --enable-cxx flag has more experience with it and could shed some light on the issue. My feeling is that it is unlikely to be a compiler version or CFLAGS issue. With respect to the naming question, I advocate treating the two packages as just that, two separate packages, for the same reasons you outline. Shaun
Ok, removing --enable-cxx seems to work fine. I have committed the modified version of hdf5 ebuild (new package hdf5. hdf, which is hdf4 is problemmatic atm, will get to it later). Please test. Donald: I have added you to CC, since I noticed you weren't added to this bug and the suggestion to use --enable-cxx was actually yours ;). Could you please look into the issue, as mentioned above few comments? The addition of this flag causes some tests to fail.. George
Evidently disabling static libraries causes the problem with the "--enable-cxx" flag. So long as they're enabled it compiles fine with it. I've attached a slightly modified ebuild that also checks for USE="ssl" and uses the appropriate flag for that if it is set.
Created attachment 13527 [details] Slight modifications to hdf5 ebuild
Hi Donald. Thanks for the update and sorry for the delay. I have updated hdf5 to 1.6.0 and added your changes to it as well. Actually I made "--enable-cxx" and --disable-static exclusive flags. The way you had it in ebuild it was possible for them to simultaneously appear and trigger misbehavior. Please test (the changes are in 1.6.0 ebuuld). Also, could you please take a look at #25365. Apparently there are few patches that might be applied, but I would like to get an idea of what they do and in what circumstances they are usefull. George
Hi everybody, I completely emerge the 1.6.0 ebuild file without problems. I didn't test yet with real HDF5 files but I believe that's OK as there is a test section in make process. Good job! Castel
Hi everybody, I completely emerge the 1.6.0 ebuild file without problems. I didn't test yet with real HDF5 files but I believe that's OK as there is a test section in make process. Good job! Castelão.
reclosing the bug.
