Bug#922010: RFS: libmurmurhash 1.3
I don't know why this was being discussed on a RT unblock bug (it should be moved elsewhere really, so just adding the bug in Bcc) On 11/02/2019 16:53, Fabian Klötzl wrote: > Long Description: PMurHash comes with a few functions e.g. > "PMurHash32_Process" > which I use internally, but I don't want to support. The true API of > libmurmurhash consists of six functions "prefixed with lmmh_ or MurmurHash3_. > Only these functions appear in the header supplied by the -dev package. As > they > are the public interface, only they should appear in the symbols file, right? If you have some symbols that can't be declared 'static' because they are used internally by different objects, then those will be exposed in your ELF binary by default, even if they are not declared in your public headers. The way to limit what is exposed in the binary in these cases is to tell libtool to only export 'lmmh_*' symbols with the -export-symbols-regex option, see: https://codesearch.debian.net/search?q=-export-symbols-regex Add that to your lib and compare the output of `nm -D libmurmurhash.so' before and after building with that option. Cheers, Emilio
Bug#922010: RFS: libmurmurhash 1.3
On 11.02.19 22:24, Andreas Tille wrote: I had a look on the build logs[1] and at least mips and s390x keep on failing (some archs are not yet build). Sorry for keeping you busy with this That's fine, because it is entirely my fault; Wouldn't have happened if I had merged your automake suggestion. Pushed a new release to salsa. To quote another authority: "Everything should be made as simple as possible, but not simpler." (A. Einstein) I regard the simple Makefile as to simple for the intended purpose. Touché. Fabian
Bug#922010: RFS: libmurmurhash 1.3
Hi Fabian, I had a look on the build logs[1] and at least mips and s390x keep on failing (some archs are not yet build). Sorry for keeping you busy with this Andreas. [1] https://buildd.debian.org/status/package.php?p=libmurmurhash On Mon, Feb 11, 2019 at 05:28:32PM +0100, Andreas Tille wrote: > On Mon, Feb 11, 2019 at 04:53:16PM +0100, Fabian Klötzl wrote: > > > Could you be more verbose about what you did and what lintian error was > > > issued? Normally you do not simply remove symbols vrom the .symbols > > > file manually. You should rather declare the interface private inside > > > the code and update the symbols file. > > > > Long Description: PMurHash comes with a few functions e.g. > > "PMurHash32_Process" which I use internally, but I don't want to support. > > The true API of libmurmurhash consists of six functions "prefixed with lmmh_ > > or MurmurHash3_. Only these functions appear in the header supplied by the > > -dev package. As they are the public interface, only they should appear in > > the symbols file, right? > > > > > So my advise to upstream is: > > > > > > 1. Declare the private functions really private > > Got it; managed to define the PMurHash with visibility hidden. Will create a > > new upstream version with bumped soname some time. > > :-) > > > > 2. Use Automake > > > > I leave it to Lennart Poettering to describe the madness that are the > > autotools: „Das ist ein Perlskript, das ein m4-Skript generiert, das ein > > Shellskript generiert, was ein Makefile generiert.“ [1] Even though I know > > automake, I am a bit reluctant to add it to libmurmurhash, because I think > > that for such a small project a simple makefile should suffice. (And it > > works just fine on Arch Linux *cough*) > > You try to use the method "proof by authority" to make your point? ;-P > Well, I did not added the patch since I have to much spare time. As > far as I remember your package had three issues: >1. No multiarch triplet installation >2. Static lib in wrong place. >3. No pkg-config support > So I had the choice to move things around manually to use d-shlibs or to > write some Makefile creating system. I'm less educated with cmake thus > I cut-n-pasted some existing automake patches we have for other libs. > The point is that you need to write only a few lines of code to solve > all three issues above and in the end it might help other distributors > as well. If you prefer cmake (or whatever you authority suggest ;-)) > that's perfectly fine for me. To quote another authority: "Everything > should be made as simple as possible, but not simpler." (A. Einstein) > I regard the simple Makefile as to simple for the intended purpose. > > > > 3. Bump SONAME if the resulting lib has changed / removed symbols > > > > > > Please note: Bumping SONAME also means changing the package name and > > > thus trying another round inside new queue. While currently ftpmaster > > > is incredibly quick I've seen relion sitting there for longer than > > > expected due to the same reason (admittedly way more complex code to > > > review). In any case the tour via new queue has a non-predictable delay > > > time and may be we wait until mash has migrated to testing before doing > > > this. > > > > Fully agree on this one; Let's take one step after the other, first > > libmurmurhash, then mash, then our other packages, and, maybe if we want to > > and the API/ABI is stable, other debian packages. > > Fine. So we have some time to decide. > > Kind regards and thanks a lot for your work on that lib in any case > > Andreas. > > > 1: https://cre.fm/cre209-das-linux-system?t=15:53 > > -- > http://fam-tille.de -- http://fam-tille.de
Bug#922010: RFS: libmurmurhash 1.3
On Mon, Feb 11, 2019 at 04:53:16PM +0100, Fabian Klötzl wrote: > > Could you be more verbose about what you did and what lintian error was > > issued? Normally you do not simply remove symbols vrom the .symbols > > file manually. You should rather declare the interface private inside > > the code and update the symbols file. > > Long Description: PMurHash comes with a few functions e.g. > "PMurHash32_Process" which I use internally, but I don't want to support. > The true API of libmurmurhash consists of six functions "prefixed with lmmh_ > or MurmurHash3_. Only these functions appear in the header supplied by the > -dev package. As they are the public interface, only they should appear in > the symbols file, right? > > > So my advise to upstream is: > > > > 1. Declare the private functions really private > Got it; managed to define the PMurHash with visibility hidden. Will create a > new upstream version with bumped soname some time. :-) > > 2. Use Automake > > I leave it to Lennart Poettering to describe the madness that are the > autotools: „Das ist ein Perlskript, das ein m4-Skript generiert, das ein > Shellskript generiert, was ein Makefile generiert.“ [1] Even though I know > automake, I am a bit reluctant to add it to libmurmurhash, because I think > that for such a small project a simple makefile should suffice. (And it > works just fine on Arch Linux *cough*) You try to use the method "proof by authority" to make your point? ;-P Well, I did not added the patch since I have to much spare time. As far as I remember your package had three issues: 1. No multiarch triplet installation 2. Static lib in wrong place. 3. No pkg-config support So I had the choice to move things around manually to use d-shlibs or to write some Makefile creating system. I'm less educated with cmake thus I cut-n-pasted some existing automake patches we have for other libs. The point is that you need to write only a few lines of code to solve all three issues above and in the end it might help other distributors as well. If you prefer cmake (or whatever you authority suggest ;-)) that's perfectly fine for me. To quote another authority: "Everything should be made as simple as possible, but not simpler." (A. Einstein) I regard the simple Makefile as to simple for the intended purpose. > > 3. Bump SONAME if the resulting lib has changed / removed symbols > > > > Please note: Bumping SONAME also means changing the package name and > > thus trying another round inside new queue. While currently ftpmaster > > is incredibly quick I've seen relion sitting there for longer than > > expected due to the same reason (admittedly way more complex code to > > review). In any case the tour via new queue has a non-predictable delay > > time and may be we wait until mash has migrated to testing before doing > > this. > > Fully agree on this one; Let's take one step after the other, first > libmurmurhash, then mash, then our other packages, and, maybe if we want to > and the API/ABI is stable, other debian packages. Fine. So we have some time to decide. Kind regards and thanks a lot for your work on that lib in any case Andreas. > 1: https://cre.fm/cre209-das-linux-system?t=15:53 -- http://fam-tille.de
Bug#922010: RFS: libmurmurhash 1.3
Hi Andreas, On 11.02.19 15:41, Andreas Tille wrote: Furthermore, I added some man page links. I also wanted to remove some private functions from the .symbols file. However, that resulted in a lintian error. Could you be more verbose about what you did and what lintian error was issued? Normally you do not simply remove symbols vrom the .symbols file manually. You should rather declare the interface private inside the code and update the symbols file. Long Description: PMurHash comes with a few functions e.g. "PMurHash32_Process" which I use internally, but I don't want to support. The true API of libmurmurhash consists of six functions "prefixed with lmmh_ or MurmurHash3_. Only these functions appear in the header supplied by the -dev package. As they are the public interface, only they should appear in the symbols file, right? So my advise to upstream is: 1. Declare the private functions really private Got it; managed to define the PMurHash with visibility hidden. Will create a new upstream version with bumped soname some time. 2. Use Automake I leave it to Lennart Poettering to describe the madness that are the autotools: „Das ist ein Perlskript, das ein m4-Skript generiert, das ein Shellskript generiert, was ein Makefile generiert.“ [1] Even though I know automake, I am a bit reluctant to add it to libmurmurhash, because I think that for such a small project a simple makefile should suffice. (And it works just fine on Arch Linux *cough*) 3. Bump SONAME if the resulting lib has changed / removed symbols Please note: Bumping SONAME also means changing the package name and thus trying another round inside new queue. While currently ftpmaster is incredibly quick I've seen relion sitting there for longer than expected due to the same reason (admittedly way more complex code to review). In any case the tour via new queue has a non-predictable delay time and may be we wait until mash has migrated to testing before doing this. Fully agree on this one; Let's take one step after the other, first libmurmurhash, then mash, then our other packages, and, maybe if we want to and the API/ABI is stable, other debian packages. Best, Fabian 1: https://cre.fm/cre209-das-linux-system?t=15:53
Bug#922010: RFS: libmurmurhash 1.3
Hi Fabian, On Mon, Feb 11, 2019 at 03:19:42PM +0100, Fabian Klötzl wrote: > The latest version should fix the few remaining build issues on big-endian > systems. Thanks a lot. Due to a racing condition of my attempt to get mash into testing by asking ftpmaster for removal of missing architectures I managed to disappoint ftpmaster. I hope this will settle now and the latest version of mash will make it into testing anyway. > Furthermore, I added some man page links. I also wanted to remove > some private functions from the .symbols file. However, that resulted in a > lintian error. Could you be more verbose about what you did and what lintian error was issued? Normally you do not simply remove symbols vrom the .symbols file manually. You should rather declare the interface private inside the code and update the symbols file. However, when deleting symbols this is considered an ABI change and you need to bump the SOVERSION (even if we can probably safely assume in practice that this ABI is not yet used widely we should do things correctly). I'd recommend to take over my automake patches directly into your upstream distribution since this should simplify this sort of things. > So if, as per the documentation, someone wants to “discuss > with upstream to implement a version script to fix this,” go ahead. ☺ "Discuss with upstream" is nice. ;-) So my advise to upstream is: 1. Declare the private functions really private 2. Use Automake 3. Bump SONAME if the resulting lib has changed / removed symbols Please note: Bumping SONAME also means changing the package name and thus trying another round inside new queue. While currently ftpmaster is incredibly quick I've seen relion sitting there for longer than expected due to the same reason (admittedly way more complex code to review). In any case the tour via new queue has a non-predictable delay time and may be we wait until mash has migrated to testing before doing this. Kind regards Andreas. -- http://fam-tille.de
