Skip to content

Commit 0ef04cd

Browse files
committed
Build on Ubuntu
Skip-PR-comments: true Signed-off-by: Brian J. Murrell <[email protected]>
1 parent 56c07ff commit 0ef04cd

File tree

96 files changed

+36974
-128
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

96 files changed

+36974
-128
lines changed

Jenkinsfile

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -40,5 +40,5 @@
4040
// I.e. for testing library changes
4141
//@Library(value="pipeline-lib@your_branch") _
4242

43-
packageBuildingPipelineDAOSTest(['distros' : ['el8', 'leap15'],
43+
packageBuildingPipelineDAOSTest(['distros' : ['el8', 'leap15', 'ubuntu20.04'],
4444
'test-tag': 'hdf5testsuite'])

debian/README.Debian

Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
HDF5 for Debian
2+
===============
3+
4+
On thread safety
5+
----------------
6+
Some general notes for developers: since 1.8 series HDF Group deprecates
7+
enabling the thread-safe option for the C library and at the same time
8+
supporting high level (HL), C++ and Fortran bindings. Those options cannot
9+
cohexist for safety because non C libraries wrapper are not thread-aware.
10+
Debian GNU/Linux still support a C thread-safe library and the alternative
11+
bindings, but it does not imply that the Debian distributed high level, C++
12+
aand Fortranalibraries are thread-safe.
13+
14+
For short: DO NOT use HL, C++ or Fortran bindings in multi-thread programs
15+
witihout providing yourself mutex infrastructure support for every wrapped
16+
function. You can use safely only the C binding in a multi-thread environment.
17+
That was not different in 1.6 series, just the issue was ignored.
18+
19+
Now, you are warned.
20+
21+
-- Francesco Paolo Lovergine <[email protected]> Fri Jun 19 22:09:25 CEST 2009
22+
23+
1.10.0 and 1.10.1 compatibility
24+
-------------------------------
25+
From HDF Group newsletter #153:
26+
HDF5 releases are always backward compatible. In general, they are also
27+
forward compatible in maintenance releases of a major release. However,
28+
the HDF5 - 1.10.0 maintenance release will NOT be able to read HDF5 - 1.10.1
29+
files that contain a metadata cache image. The metadata cache image must be
30+
removed with the h5clear tool in order for HDF5 - 1.10.0 to read the file.
31+
32+
-- Gilles Filippini <[email protected]> Sat, 07 Oct 2017 14:02:39 +0200

debian/README.source

Lines changed: 101 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,101 @@
1+
HDF5 for Debian, note for the mantainers
2+
----------------------------------------
3+
4+
The Debian version of HDF5 is created starting from the official tarball and
5+
adding some required patches managed by quilt. More information about quilt
6+
use are available in /usr/share/doc/quilt/README.Debian and its documentation.
7+
8+
Note that starting from 1.8 HDF Group is not more providing a tarball of the
9+
library documentation. The documentation in html format is now taken by
10+
the HDF Group svn repository:
11+
12+
svn export https://svn.hdfgroup.uiuc.edu/hdf5doc/branches/hdf5_1_8_4/html
13+
14+
This is taken care by uscan companion script debian/orig-tar.sh.
15+
16+
About symbols files
17+
-------------------
18+
To update the symbols files on new upstream releases:
19+
0- Rename and update the symbols files with the new sonames. This can be
20+
done with the script debian/update-symbols-files-soname
21+
1- Build the package for the new release
22+
2- Patch the symbols files from the dpkg-gensymbols output in the build log
23+
$ patch -p0 <path_to_build_log
24+
3- Use the debian/process-symbols-files script to unmangle and sort C++
25+
symbols, and generate the version scripts (debian/map_*.ver)
26+
4- Rebuild the package and check that no diff are reported by dpkg-gensymbols
27+
5- Goto (2) if need be
28+
29+
About version scripts (debian/map_*.ver)
30+
----------------------------------------
31+
Their purpose is to be able to link serial and mpi flavors of libhdf5
32+
into the same executable.
33+
34+
I use the helper script make-version-scripts to generate them. I don't
35+
care about identifying local symbols for now.
36+
37+
About C++ symbols tracking
38+
--------------------------
39+
Tracking C++ versioned symbols is complacated:
40+
* Firstly we need to track them under their unmangled form to be arch
41+
independant.
42+
* Secondly I discovered after many /try fail repeat/ that dpkg-gensymbols
43+
wants the verbose unmangled symbols (output from 'c++filt' command)
44+
while version scripts want the non verbose ones (output from
45+
'c++filt -i' command).
46+
* Finaly the patches generated by dpkg-gensymbols don't allow any
47+
comment in the symbols files and requires a specific sorting order
48+
(bug #773718).
49+
All these concerns are handled by three helper scripts:
50+
* debian/process-symbols-files
51+
* debian/sort-symbols
52+
* debian/make-version-scripts
53+
The entry point being debian/process-symbols-files.
54+
55+
There was a non backward-compatible change in the C++ API between releases
56+
1.8.11 and 1.8.12 with no soname bump. Since there is no packages in sid
57+
using this C++ library, we didn't bother.
58+
59+
The script debian/check-dep-on-hdf5-cpp is used to check these dependencies.
60+
61+
About shared libraries versioning and SONAME
62+
--------------------------------------------
63+
Worth reading to get the picture about libtool versioning:
64+
<http://bzed.de/scratchpad/soname-libtool.txt>
65+
66+
[Old note - for the record]
67+
> About versioning style. In very recent times (since 1.8 series) HDF Group
68+
> introduced a libtool SONAME versioning in the library with major/minor releases.
69+
> Unfortunately, past experieces showed that API retention has been sometimes
70+
> violated in the past, so current packages use a defensive approach by considering
71+
> each release as not back-compatible. This is also motivated by the presence of
72+
> of C++ and Fortran bindings as well as multiple MPI editions, which could imply
73+
> ABI breakages even for minor releases. Be defensive is more safe, definitively
74+
75+
Looking at the 1.8.x releases, it seems that upstream doesn't apply the
76+
libtool versioning strategy. Instead they use it the major.medium.minor way
77+
where:
78+
* medium=0
79+
* minor++ on release
80+
* major++, minor=0 on API breaks
81+
82+
Considering applying this piece of advice from Julien Cristau:
83+
> J'aurais tendance à suggérer d'utiliser le switch -version-number de
84+
> libtool plutôt que -version-info. Ça prend directement comme argument
85+
> major:minor:micro, donc on se perd pas dans des calculs à la con.
86+
87+
Manpages
88+
--------
89+
$ help2man -n "helper script to compile HDF5 Fortran applications" --version-string="h5pfc (hdf5 1.8.12)" -h -help -N h5pfc >debian/man/h5pfc.1
90+
$ help2man -n "helper script to compile HDF5 C applications" --version-string="h5pcc (hdf5 1.8.12)" -h -help -N h5pcc >debian/man/h5pcc.1
91+
$ help2man -n "debugs an existing HDF5 file at a low level" --version-string="h5debug (hdf5 1.8.12)" -N 'bash -c "h5debug 2>&1"' >debian/man/h5debug.1
92+
93+
TO-DO
94+
-----
95+
* common manpage for h5*{c,f}c
96+
* patch libtool usage to use -version-number instead of -version-info'?
97+
* propose to upstream to use a separate libtool version for each language
98+
(C, C++, Fortran)?
99+
100+
-- Francesco Paolo Lovergine <[email protected]> Mon Jan 25 06:00:00 CET 2010
101+
-- Gilles Filippini <[email protected]> Mon, 22 Dec 2014 01:50:39 +0100

0 commit comments

Comments
 (0)