On 8/25/21 9:42 PM, Alessio Vanni wrote: > This means that once the application is being executed, gettext will try > to search the application's PO files for the e.g. the string > > "Assertion failed at %s:%d. Aborting.\n", > > failing because that string is defined in a header which gettext doesn't > know about, thus always displaying the original string and defeating the > purpose of using gettext at all.
Good point, but that's a specific issue with that macro, which I agree should not use "_" but dgettext(). I've fixed this (and a few related) instance(s) in Git master just now. > For this problem the solution is simple: just change any call to `_' > with an explicit call to `dgettext' and give it the appropriate domain, > but this actually creates a new issue. > > Currently, GNUnet's gettext domain is set inside the > `GNUNET_OS_ProjectData' structure defined in `gnunet_os_installation.c' > and it's set to the macro "PACKAGE". To make sure both GNUnet's > internals and the macros in the util header use the same domain, the > dgettext calls ought to also use PACKAGE as their domain arguments. There is a much simpler (and IMO proper) solution: GNUNET_OS_ProjectData should really just use "gnunet" and not PACKAGE. > While I was investigating this issue I discovered that there is at least > one other macro where an Autoconf macro can be overridden, giving an > inappropriate value. > > Again inside the util header there is the macro "GNUNET_AGPL_URL", which > is currently defined as: > > #define GNUNET_AGPL_URL "https://gnunet.org/git/gnunet.git#" PACKAGE_VERSION Oh, that should at least be updated to git.gnunet.org, fixing as well ;-). > Inside GNUnet this correctly gives > "https://gnunet.org/git/gnunet.git#0.15.2" (or whatever the current > version is when expanded), but if used within an application with e.g. a > version number of "13.0.1" it will generate > "https://gnunet.org/git/gnunet.git#13.0.1" which is obviously incorrect > as of today. > > I can think of a couple of ways to fix these issues, for example by > having a separate header file for this kind of macros, which is expanded > by Autoconf at configure time (i.e. a ".h.in" generating a ".h") and > thus the values can't be overridden, but before progressing I'd like to > ask for opinions, in case changing how these macros are handled ends up > touching things I wasn't aware of. I think that would likely be the best fix for the PACKAGE_VERSION issue. We _could_ use this also for the PACKAGE issue you raised, but here I'm fine with just hard-coding "gnunet" as a quick fix. > Hopefully things can be changed without too many consequences, as it's > otherwise a fairly easy issue to tackle and fix. I also do not currently see any unintended consequences of what you describe. > Thanks, > A.V. > > P.S.: Apologies for the long e-mail for what in the end is a simple > issue, but I wanted to explain in details to avoid (as much as possible) > misunderstandings. :) Thanks for the very clear report ;-). > P.P.S: Is the GNUNET_AGPL_URL value correct? Currently it redirects to > the homepage of git.gnunet.org, but I don't know if that's what it > should point to. The idea was to point to the tag. I have fixed that in Git as well. -Christian
signature.asc
Description: OpenPGP digital signature