Mailing List Archive

On Wed, 12 May 2004 12:11:44 +0300, Nikos Mavroyanopoulos said:

> I bring again the libgpg-error issue. Would it be possible to
> add the required functions for libgcrypt (without gettext and the extra
> stuff), in a single object which will be compiled if libgpg-error is not
> found in the system[0]? This would make the library much easier to

This is a problem. Sooner or later another application will require
libgpg-error and than we get into the problem of duplicate symbols or
- if we take them out of the linker's scope - that other application
won't be able to display proper i18n'd messages or you will see a
translation or no translation depending on where the error gets
printed.

Adding libgpg-error as an independent part to libgcrypt would be
possibe but be a headache for maintenance.


Salam-Shalom,

Werner

On Thursday 13 May 2004 10:36, Werner Koch wrote:

> > I bring again the libgpg-error issue. Would it be possible to
> > add the required functions for libgcrypt (without gettext and the extra
> > stuff), in a single object which will be compiled if libgpg-error is not
> > found in the system[0]? This would make the library much easier to
>
> This is a problem. Sooner or later another application will require
> libgpg-error and than we get into the problem of duplicate symbols or
> - if we take them out of the linker's scope - that other application
> won't be able to display proper i18n'd messages or you will see a
> translation or no translation depending on where the error gets
> printed.
That's why a warning should be issued. This is due to an administrative
decision so such behaviour is acceptable (they should install libgpg-error
to avoid that). In any case my proposal was for systems that do not need
internationalization such as constrained systems etc. Also porting
is much more work with interlibrary dependencies and this change would
help a lot.

> Adding libgpg-error as an independent part to libgcrypt would be
> possibe but be a headache for maintenance.
Not a fully working gpg-error is expected to be included. Just the
minimum part of it that is required for it to work. Only the .h file should
be updated if new error values are used in libgcrypt. If this is not possible
a disable option to disable completely error printing (and thus the
dependency to libgpg-error) would also help.

> Salam-Shalom,
> Werner

--
Nikos Mavroyanopoulos

On Thu, 13 May 2004 11:33:11 +0300, Nikos Mavroyanopoulos said:

> minimum part of it that is required for it to work. Only the .h file should
> be updated if new error values are used in libgcrypt. If this is not possible

and that is excaly what makes maintenance hard.

> a disable option to disable completely error printing (and thus the
> dependency to libgpg-error) would also help.

Disabling error printing is a Bad Thing. You will get weird bug
reports taking a long time to duplcate them and finally it is a simple
thing which could have been figured out by the error message directly.
After all we went for this shared libary with markers for the
subsystem to make bug tracking easier. By not having a central place
to maintain this information (the shared library) this effort would be
rendered mostly fruitless.

What is the real problem you have with libgpg-error? Does it not
build cleanly on all systems? I'd like to hear about such things
ASAP.


Shalom-Salam,

Werner

On Thursday 13 May 2004 13:12, Werner Koch wrote:

> > a disable option to disable completely error printing (and thus the
> > dependency to libgpg-error) would also help.
> Disabling error printing is a Bad Thing. You will get weird bug
Well error printing the way libgpg-error does, is only usefull to applications
such as gnupg. For gnutls which is a low level wrapper library over libgcrypt
it is just unused code.

> reports taking a long time to duplcate them and finally it is a simple
> thing which could have been figured out by the error message directly.
> What is the real problem you have with libgpg-error? Does it not
> build cleanly on all systems? I'd like to hear about such things
> ASAP.
I don't have anything with libgpg-error. I just want an option to disable it
if I don't need it at all since it makes it harder to compile libgcrypt and
adds unused code.

Your concerns when adding an option to disable it are for end user
distributions which will of course include it, since they want error
reporting. On the other hand embedded servers that only use gnutls
over libgcrypt don't need it at all.


> Shalom-Salam,
> Werner

--
Nikos Mavroyanopoulos

At Thu, 13 May 2004 11:33:11 +0300,
Nikos Mavroyanopoulos wrote:
> On Thursday 13 May 2004 10:36, Werner Koch wrote:
> That's why a warning should be issued. This is due to an administrative
> decision so such behaviour is acceptable (they should install libgpg-error
> to avoid that). In any case my proposal was for systems that do not need
> internationalization such as constrained systems etc.

You can disable i18n when compiling libgpg-error (--disable-nls).

> Also porting
> is much more work with interlibrary dependencies and this change would
> help a lot.

That's hardly true.

> > Adding libgpg-error as an independent part to libgcrypt would be
> > possibe but be a headache for maintenance.
> Not a fully working gpg-error is expected to be included. Just the
> minimum part of it that is required for it to work. Only the .h file should
> be updated if new error values are used in libgcrypt. If this is not possible
> a disable option to disable completely error printing (and thus the
> dependency to libgpg-error) would also help.

We don't optimize the software for the rare cases. If you have a
genuine need to keep things small, you can compile libgpg-error with
disable-nls, and link statically to it. If you don't use
gcry_strerror, it should not link in the error strings.

Thanks,
Marcus

On Thu, 13 May 2004 13:56:56 +0200, Marcus Brinkmann said:

> disable-nls, and link statically to it. If you don't use
> gcry_strerror, it should not link in the error strings.

Furthermore, we could eventually work together on a common set of
error codes and add the gnutls specific ones to libgpg-error.
Obviously only for the next gnutls API as. gnutls is also a very
basic library and having one set of error codes will make things for
applications easier.


Shalom-Salam,

Werner

On Thu, 13 May 2004 14:13:39 +0300, Nikos Mavroyanopoulos said:

> distributions which will of course include it, since they want error
> reporting. On the other hand embedded servers that only use gnutls
> over libgcrypt don't need it at all.

Don't forget about applications using gnutls directly and indirectly
as it is very common if one uses LDAP.


Salam-Shalom,

Werner