libgcrypt: bump to 1.7.2, keep and fix libgcrypt.la, add TEST().

[fbrosson]

• Bump to version 1.7.2, update HOMEPAGE.
• Move hmac256 to the $binDir of the base package. Keep dumpsexp, mpicalc and libgcrypt-config in the _devel package, however.
• Keep libgcrypt.la to allow packages that depend on libgcrypt to not have to declare an indirect dependency on libgpg_error.
• Fix paths to libgpg_error in libgcrypt.la to make sure they won't become broken if libgpg_error gets upgraded.
• Add TEST() with make check.

[korli]

dumpsexp, hmac256 and mpicalc are meant to be in the devel package, why the change?
The reason to keep libgcrypt.la is dubious, I mean no other package requires it.

[fbrosson]

OK, I've put back dumpsexp and mpicalc in the devel package, but I left hmac256 in the base package because it has its man page.
For the libgcrypt.la file, I came to the conclusion that we should keep (and fix) all libtool files.
I'll explain why I think so.

[fbrosson]

Imagine we have 3 recipes: one program, say myprog and two libraries, libfoo and libbar. If myprog only needs libfoo, and libfoo needs libbar then we should not mention libbar in the recipe of myprog. It should only mention libfoo. If, for some reason, libfoo decides to not use libbar anymore, but another lib, then this change should only appear in libfoo. After such a change, we would only need to bump the revision of myprog to make sure it gets rebuilt against the new version of libfoo.
If you agree with all this, then the only way to have a recipe for myprog that builds (without it mentionning libbar) is to make use of the package-links abstraction: the libfoo.la libtool file has references to libbar that will be automatically pulled by haikuporter when we build myprog, provided devel:libbar is in the REQUIRES_devel of libfoo and devel:libfoo is in the BUILD_REQUIRES of myprog.
If we stick to that rule for all packages that come with libtool files then we can safely narrow the dependencies of any package to the strict set of direct dependencies.
I do understand that keeping and fixing libtool files may not seem necessary, but it is really helpfull if you consider all indirect dependencies that "high-level" packages currently need to mention just to make sure they build.
Having a correct libtool file for libfoo allows to drop in the recipe of myprog the indirect dependency of myprog on libbar (and only keep the direct dependency on libfoo.)

[pulkomandy]

That makes sense. Is there a way to fix libtool so it generates the right thing directly? (IIRC there is no need for an absolute path in the .la files). This would avoid having to manually fix things in the recipes, at least.

[korli]

Please open an issue about the problem you want to discuss, or post on the mailing list.
See also this
@pulkomandy I think Debian does it.

-1 for keeping libgcrypt.la.

[pulkomandy]

So, if I read the libtool patch linked by Korli correctly, we can:

1. remove the .la files
2. fix libtool so it doesn't include the transitive dependencies when linking

[fbrosson]

A patch for libtool to make it drop the references to other libs will only make things worse with regards to indirect dependencies. We need to keep the libtool files and fix them using the paths that package-links abstraction provide. See the description of the portPackageLinksDir variable in https://github.com/haikuports/haikuports/wiki/HaikuPorter-BuildRecipes if you want to read about package-links abstraction.

If libfoo needs libbar-acuda then we just need to add devel:libbar_acuda$secondaryArchSuffix in libfoo's REQUIRES_devel and BUILD_REQUIRES, and put this in libfoo's INSTALL():

    local develPackageName="${portName}_devel-$portFullVersion"
    local packageLinksDir="`dirname "$portPackageLinksDir"`"
    local develPkgLinksDir="$packageLinksDir/$develPackageName"
    local libbar_acuda="$develPkgLinksDir/devel~bar_acuda$secondaryArchSuffix/$relativeDevelopLibDir"
    sed -i \
            -e "/^dependency_libs=/ s,-L/packages/libbar$secondaryArchSuffix-[^\ /]*/\.self/develop/$relativeLibDir,-L$libbar,g" \
            -e "/^dependency_libs=/ s,/packages/libbar_acuda$secondaryArchSuffix-[^\ /]*/\.self/develop/$relativeLibDir/\(libbar-acuda\.la\),$libbar_acuda/\1,g" \
            $developLibDir/libfoo.la

This will convert e.g. -L/packages/libbar_acuda-1.0-1/.self/develop/lib/libbar-acuda.la into
-L$portPackageLinksDir/devel~libbar_acuda$secondaryArchSuffix/$relativeDevelopLibDir and /packages/libbar_acuda-1.0-1/.self/develop/lib/libbar-acuda.la into
$portPackageLinksDir/devel~libbar_acuda$secondaryArchSuffix/$relativeDevelopLibDir/libbar-acuda.la

HaikuPorter already has a helper function, fixLibtoolArchives, written by @mmuman, that was added for that purpose, but it does not work for all cases, and no recipes currently use it. We could either improve it or add a sister function.

If other contributors also agree with @pulkomandy's comment, "That makes sense", refering to my previous comment, then please consider writing in private mail to @korli to convince him we should keep and fix the libtool files, either with sed commands or by calling a helper function. BTW, I can try and write such a helper function for HaikuPorter if I'm given green lights to keep libtool files. And in that case I'll wait until that helper function becomes available in order to simplify this recipe (before merging it) as well as the other recipes that are still WIP.
@korli: You're the last person I would like to argue with, because your knowledge of gcc (and many other topics) is essential to Haiku and I don't want to hurt your feelings. I only want to improve HaikuPorts.

[waddlesplash]

As far as I know, very few recipes were broken by lack of libtool files, and that number will continue to shrink because libtool seems to be used less and less. So I say we drop them (@pulkomandy's option 1, @korli's stance, and the general procedure since forever.)

Also, don't write private mails to korli, or anyone else; rather, start a discussion on the HaikuPorts mailing list (explicitly referencing korli, if you must) about this. Thanks.

[waddlesplash]

Another follow-up: Since this has been procedure since forever, and it's easy enough to change in the future, go ahead and delete the libtool files (and mark the other recipes non-WIP that were waiting on that). If there is another discussion on the ML that reverses that concensus, we can change things rather easily.

And just so there aren't any perceived slights: @fbrosson, your work on HaikuPorts is to be commended! Not all of us have as much time for it as we'd like, so your work is greatly appreciated.

[waddlesplash]

Also, in the thread that @korli linked to, the last message in the thread points to https://autotools.io/libtool/lafiles.html, which clearly states at the bottom of the page:

Dependency tracking for static linking is, nowadays, mostly supplanted by the use of pkg-config, as can be read in Section 2.1, “Static linking”. Since most build systems, custom and not, have easy access to the data stored in .pc files, without the need to use libtool when linking the consumer, the whole idea of Libtool Archives is, nowadays, considered obsolete.

(emphasis mine).

[fbrosson]

I might be wrong, but the pc files do not have references to external dependencies, so this means that myprog would have to explicitely depend on both libfoo and libbar. With the libtool file we can get rid of all indirect dependencies.
I might be wrong and I'm not a specialist of libtool and pkgconfig, but what I learned about package -links abstraction makes me think keeping (and fixing) the libtool files would be an improvement.

[waddlesplash]

I might be wrong and I'm not a specialist of libtool and pkgconfig, but what I learned about package -links abstraction makes me think keeping (and fixing) the libtool files would be an improvement.

As I said above: libtool is effectively deprecated and fewer applications are using it. We will always have to explicitly declare REQUIRES/PROVIDES in a recipe; and so the only thing we care about is when the lack of libtool files breaks a build somewhere else. So, unless you know of some piece of software which requires these, remove them. (And re-add them with a comment saying which recipe requires them if you need to, but the number of those are decreasing.)

So please drop the libtool files here and elsewhere.

[pulkomandy]

Well let's get things right:

• libtool itself is not deprecated, it is still used in any autotools-based build when dynamic linking is involved.
• .la files are not required on Haiku, because our ELF files already have the required information. Linux is able to work without .la files too. On other systems (other flavours of UNIX, and also Windows), the .la files may still be needed.
• The .pc file are there to tell programs what to include on their linker command line to link all their dependencies. If they included the transitive dependencies, things would not work as we want, because the program would end up with an explicit reference to those. We do only want the direct dependencies in the .pc file. The program links only against those, then at runtime, the runtime_loader figures out the dependencies and finds the transitive dependencies and loads all libraries. It does not need any help for that, all the required information is already in the ELF file headers for the program and the shared libraries.