[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [DebianGIS] Package of hdf-1.8.3, first try



On Thu, Jun 18, 2009 at 01:18:24PM +0200, Francesco P. Lovergine wrote:
> On Thu, Jun 18, 2009 at 10:44:58AM +0200, Heiko Klein wrote:
> > Hi,
> >
> > I'm eager to build a debian/ubuntu package of netcdf4 which requires  
> > hdf-1.8.3. I've seen that it is on the todo list of this group, but  
> > without explicit roadmap, so I gave it a try to build a hdf5-package:
> >
> > http://pastebin.met.no/pastebin/cgi-bin/file?id=afbf25c4b95a64a3ecf0e97ca4b713731f08f589/hdf5_1.8.3.orig.tar.gz
> > http://pastebin.met.no/pastebin/cgi-bin/file?id=4e69a51659c8fa467ed66534b0e5105d2209a1d9/hdf5_1.8.3-1.diff.gz
> >
> > It was generated from the 1.6.5 debian package with uscan, and some  
> > smaller changes to get hdf5 to build. The biggest change I introduce is  
> > to name the library to the ABI version rather than the hdf package  
> > version. hdf5 tries uses libtool and tries to be ABI compatible  
> > (currently at library version 6) so I don't see a reason why the hdf5  
> > packages should still force the correct version number.
> >
> > I have tested the package under hardy and debian 5.0.1. lintian gives  
> > some complaints about man-page and the ABI-VERSION conflicts, but  
> > otherwise it seems to work.
> >
> > I include the orig.tar.gz since the official hdf5_1.8.3.tar.gz contains  
> > a file twice (detype_files.txt), which conflicts with debuild 'tar -xkf'.
> >
> 
> Nice try. We have an ongoing discussion about 1.8.3 specifically about
> the thread-safety and C++/Fortran. The reason for having a different
> name is the following: the existance of the soname for the library is 
> a recent discovery of HDF group. Unfortunately they use the same
> soname for all libraries (C/C++/Fotran) so I think it's much more
> safe embedding the library version into the package name. Note that
> they often in the past changed API and ABI at every new release
> and I suspect that would be done again if the C interface only was
> left stable.
> 
> A good improvement would be dropping the unused (unuseful?) additional
> ABI version in the package, which is what I did for 1.8.2.
> 
> But for that it is now time to issue a svn branch for the available
> stuff in order to have a common reference for all available parties.
> 
> 

Just for note, this is the current set of libraries with 1.8.2. This is not
different for 1.8.3:

lrwxrwxrwx 1 frankie 1000      16 Mar 31 12:44 libhdf5.so.6 -> libhdf5.so.6.0.1*
-rwxr-xr-x 1 frankie 1000 3038106 Mar 31 12:43 libhdf5.so.6.0.1*
lrwxrwxrwx 1 frankie 1000      20 Mar 31 12:44 libhdf5_cpp.so.0 -> libhdf5_cpp.so.0.0.0*
-rwxr-xr-x 1 frankie 1000  534867 Mar 31 12:43 libhdf5_cpp.so.0.0.0*
lrwxrwxrwx 1 frankie 1000      24 Mar 31 12:44 libhdf5_fortran.so.0 -> libhdf5_fortran.so.0.0.0*
-rwxr-xr-x 1 frankie 1000  278892 Mar 31 12:43 libhdf5_fortran.so.0.0.0*
lrwxrwxrwx 1 frankie 1000      19 Mar 31 12:44 libhdf5_hl.so.0 -> libhdf5_hl.so.0.0.0*
-rwxr-xr-x 1 frankie 1000  126402 Mar 31 12:43 libhdf5_hl.so.0.0.0*
lrwxrwxrwx 1 frankie 1000      23 Mar 31 12:44 libhdf5_hl_cpp.so.0 -> libhdf5_hl_cpp.so.0.0.0*
-rwxr-xr-x 1 frankie 1000   12177 Mar 31 12:44 libhdf5_hl_cpp.so.0.0.0*
lrwxrwxrwx 1 frankie 1000      26 Mar 31 12:44 libhdf5hl_fortran.so.0 -> libhdf5hl_fortran.so.0.0.0*
-rwxr-xr-x 1 frankie 1000   65326 Mar 31 12:44 libhdf5hl_fortran.so.0.0.0*

If you check in the building scripts, only the C binding uses the explicitly set LT_VERSION.
The resulting non-C binding use always the same versioning.

----
My own conclusion about the thread-safety is enabling both thread-support AND C++/Fortran
interfaces in the same libraries, adding a note in the documentation about possible problems
in using HDF5 non-C functions in multi-thread programs. This is the same choice done
by Fedora folks.



-- 
Francesco P. Lovergine



Reply to: