From nmav at gnutls.org Thu Mar 9 00:30:55 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu Mar 9 02:17:52 2006 Subject: libgpg-error Message-ID: <200603090030.55282.nmav@gnutls.org> Hello, I've tried to compile libgpg-error in a freebsd system and I get undefined references for textdomain() and friends. Even if I configure with --disable-nls I get the same errors. The only way to compile was to comment out these calls, which are gettext related. Probably this problem applies to all non-glibc systems. -- Nikos Mavrogiannopoulos From jas at extundo.com Thu Mar 9 15:42:25 2006 From: jas at extundo.com (jas@extundo.com) Date: Thu Mar 9 15:41:46 2006 Subject: libgpg-error In-Reply-To: <200603090030.55282.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu, 9 Mar 2006 00:30:55 +0100") References: <200603090030.55282.nmav@gnutls.org> Message-ID: <87veunsmr2.fsf@latte.josefsson.org> Nikos Mavrogiannopoulos writes: > Hello, > I've tried to compile libgpg-error in a freebsd system and > I get undefined references for textdomain() and friends. > Even if I configure with --disable-nls I get the same errors. > The only way to compile was to comment out these calls, > which are gettext related. Probably this problem applies to > all non-glibc systems. I had the same problem on several platforms, see: http://josefsson.org/autobuild-logs/gnutls.html#libgpg-error-1.2 /Simon From hargrave at vonbraunlabs.com.br Thu Mar 9 18:21:31 2006 From: hargrave at vonbraunlabs.com.br (Beatriz Hargrave) Date: Thu Mar 9 20:17:53 2006 Subject: Problem with libgpg-error Message-ID: <20060309172131.25114.qmail@hm318.locaweb.com.br> Hi everybody ! I am trying to compile the libgcrypt library to uclinux (20041215, kernel 2.4.x, Coldfire) and I get this error related to the libgpg-error lib. In file included from ../src/g10lib.h:36, from ../src/mpi.h:36, from mpi-internal.h:52, from mpi-add.c:31: ../src/gcrypt.h:28: gpg-error.h: No such file or directory make[2]: *** [mpi-add.lo] Error 1 make[2]: Leaving directory `/mnt/auto/oberon/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/mnt/auto/oberon/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2' make: *** [all] Error 2 sh-2.05b$ Is it possible to compile libgcrypt without libgpg-error (disable somehow libgpg-error) ? (This is because when I try to compile libgpg-error to uclinux I get another error) Thank you very much, Beatriz. From wk at gnupg.org Thu Mar 9 20:43:53 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Mar 9 20:46:50 2006 Subject: Problem with libgpg-error In-Reply-To: <20060309172131.25114.qmail@hm318.locaweb.com.br> (Beatriz Hargrave's message of "Thu, 9 Mar 2006 14:21:31 -0300") References: <20060309172131.25114.qmail@hm318.locaweb.com.br> Message-ID: <874q27h092.fsf@wheatstone.g10code.de> On Thu, 9 Mar 2006 14:21:31 -0300, Beatriz Hargrave said: > Is it possible to compile libgcrypt without libgpg-error (disable somehow libgpg-error) ? > (This is because when I try to compile libgpg-error to uclinux I get another error) There seems to be a problem with libgpg-error 1.2 - please revert to 1.1 until we have fixed that. It might help to build libgpg-error with configure --disable-nls. Shalom-Salam, Werner From wk at gnupg.org Fri Mar 10 10:59:56 2006 From: wk at gnupg.org (Werner Koch) Date: Fri Mar 10 11:02:00 2006 Subject: [patch] Additional HMAC unit tests In-Reply-To: <200602182215.20665.bradh@frogmouth.net> (Brad Hards's message of "Sat, 18 Feb 2006 22:15:13 +1100") References: <200602182215.20665.bradh@frogmouth.net> Message-ID: <87oe0e1uxv.fsf@wheatstone.g10code.de> On Sat, 18 Feb 2006 22:15:13 +1100, Brad Hards said: > The attached patch provides HMAC unit tests for a range of the more critical > hashes - MD5, SHA224, SHA256, SHA384 and SHA512, using standard test vectors. I have just commited it. However teh HMAC tests for SHA-384 and SHA-512 are failing. Would you mind to look after that? > This patch also changes around the format of the output of --verbose mode to > make it clearer what is actually being tested. Indeed, this is better. > It also changes the public key tests to what I believe is the correct > behaviour - see email from earlier today. Generating all these keys takes some time now :-(. Shalom-Salam, Werner From hargrave at vonbraunlabs.com.br Fri Mar 10 14:17:31 2006 From: hargrave at vonbraunlabs.com.br (Beatriz Hargrave) Date: Fri Mar 10 14:17:00 2006 Subject: Compiling libgcrypt: gcry problem (undefined reference) Message-ID: <20060310131731.2906.qmail@hm318.locaweb.com.br> Hi everybody ! I am trying to compile the libgcrypt library to uclinux (20041215, kernel 2.4.x, Coldfire) and I get this error concerning "gcry" functions (see bellow). Does anybody know how to solve this problem ? (I have information that it might be a linker problem) Thank you very much, Beatriz. m68k-elf-gcc -m5307 -DCONFIG_COLDFIRE -I/home/usuarios/hargrave/uclib/include -Os -g -fomit-frame-pointer -m5307 -DCONFIG_COLDFIRE -fno-common -Wall -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED -nostdinc -I/home/usuarios/hargrave/uClinux-vb/lib/libssl -I/home/usuarios/hargrave/uClinux-vb/lib/libssl/ssl -I/home/usuarios/hargrave/uClinux-vb/lib/libssl/crypto -I/home/usuarios/hargrave/uClinux-vb/include -I/home/usuarios/hargrave/uClinux-vb/include/include -I/home/usuarios/hargrave/uClinux-vb/include/openssl -I/home/usuarios/hargrave/uClinux-vb/mylibs/include/mylibs -I/home/usuarios/hargrave/uClinux-vb/mylibs/include/ilbc -I/home/usuarios/hargrave/uClinux-vb/mylibs/include -fno-builtin -I/home/usuarios/hargrave/desenvolvimento/vonbraun/include -Wl,-elf2flt -DUSE_SYSLOG -Wall -Os -g -fomit-frame-pointer -m5307 -DCONFIG_COLDFIRE -fno-common -Wall -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED -nostdinc -fno-builtin -msep-data -Wl,-elf2flt -Wl,-move-rodata -nostartfiles /home/usuarios/hargrave/uClinux-vb/lib/crt0.o -o prime prime.o -L/home/usuarios/hargrave/uClinux-vb/lib -L/home/usuarios/hargrave/uClinux-vb/mylibs/lib -L/home/usuarios/hargrave/uClinux-vb/lib/libssl ../src/.libs/libgcrypt.a -L/home/usuarios/hargrave/uclib/lib /home/usuarios/hargrave/uclib/lib/libgpg-error.a -lssl -lcrypto -lc -lnsl prime.elf2flt: In function `main': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/tests/prime.c:108: undefined reference to `gcry_control' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/tests/prime.c:109: undefined reference to `gcry_check_version' prime.elf2flt: In function `prime_generate_internal': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:253: undefined reference to `_gcry_get_debug_flag' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:254: undefined reference to `_gcry_log_debug' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:266: undefined reference to `gcry_calloc' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:279: undefined reference to `gcry_calloc' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:300: undefined reference to `gcry_calloc' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:326: undefined reference to `gcry_free' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:377: undefined reference to `_gcry_get_debug_flag' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:386: undefined reference to `_gcry_log_debug' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:398: undefined reference to `gcry_calloc' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:448: undefined reference to `_gcry_get_debug_flag' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:450: undefined reference to `_gcry_log_debug' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:452: undefined reference to `_gcry_log_printf' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:477: undefined reference to `_gcry_get_debug_flag' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:486: undefined reference to `gcry_free' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:489: undefined reference to `gcry_free' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:491: undefined reference to `gcry_free' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:509: undefined reference to `gcry_free' prime.elf2flt: In function `gen_prime': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:545: undefined reference to `_gcry_log_fatal' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:547: undefined reference to `gcry_xmalloc' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:623: undefined reference to `gcry_free' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:605: undefined reference to `_gcry_log_debug' prime.elf2flt: In function `m_out_of_n': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:785: undefined reference to `_gcry_bug' prime.elf2flt: In function `gcry_prime_generate': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:915: undefined reference to `gcry_free' prime.elf2flt: In function `gcry_prime_group_generator': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:987: undefined reference to `_gcry_get_debug_flag' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:989: undefined reference to `_gcry_log_debug' prime.elf2flt: In function `gcry_prime_release_factors': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/primegen.c:1026: undefined reference to `gcry_free' prime.elf2flt: In function `gcry_mpi_div': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpi-div.c:354: undefined reference to `_gcry_log_bug' prime.elf2flt: In function `mpi_read_from_buffer': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpicoder.c:48: undefined reference to `_gcry_log_error' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpicoder.c:53: undefined reference to `_gcry_log_error' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpicoder.c:73: undefined reference to `_gcry_log_bug' prime.elf2flt: In function `gcry_mpi_dump': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpicoder.c:171: undefined reference to `_gcry_log_printf' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpicoder.c:195: undefined reference to `_gcry_log_printf' prime.elf2flt: In function `_gcry_log_mpidump': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpicoder.c:203: undefined reference to `_gcry_log_printf' prime.elf2flt: In function `do_get_buffer': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpicoder.c:228: undefined reference to `gcry_xmalloc_secure' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpicoder.c:228: undefined reference to `gcry_xmalloc' prime.elf2flt: In function `gcry_mpi_scan': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpicoder.c:346: undefined reference to `gcry_is_secure' prime.elf2flt: In function `gcry_mpi_print': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpicoder.c:506: undefined reference to `gcry_free' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpicoder.c:522: undefined reference to `gcry_free' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpicoder.c:543: undefined reference to `gcry_free' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpicoder.c:577: undefined reference to `gcry_free' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpicoder.c:592: undefined reference to `gcry_free' prime.elf2flt:/home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpicoder.c:616: more undefined references to `gcry_free' follow prime.elf2flt: In function `gcry_mpi_aprint': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpicoder.c:640: undefined reference to `gcry_xmalloc_secure' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpicoder.c:640: undefined reference to `gcry_xmalloc' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpicoder.c:643: undefined reference to `gcry_free' prime.elf2flt: In function `_gcry_mpih_mul_n': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpih-mul.c:356: undefined reference to `gcry_is_secure' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpih-mul.c:367: undefined reference to `gcry_is_secure' prime.elf2flt: In function `_gcry_mpih_mul_karatsuba_case': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpih-mul.c:389: undefined reference to `gcry_is_secure' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpih-mul.c:405: undefined reference to `gcry_is_secure' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpih-mul.c:426: undefined reference to `gcry_xcalloc' prime.elf2flt: In function `_gcry_mpih_release_karatsuba_ctx': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpih-mul.c:455: undefined reference to `gcry_free' prime.elf2flt: In function `_gcry_mpi_alloc': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:43: undefined reference to `gcry_xmalloc' prime.elf2flt: In function `_gcry_mpi_m_check': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:55: undefined reference to `_gcry_check_heap' prime.elf2flt: In function `_gcry_mpi_alloc_secure': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:64: undefined reference to `gcry_xmalloc' prime.elf2flt: In function `_gcry_mpi_alloc_limb_space': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:82: undefined reference to `gcry_xmalloc_secure' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:82: undefined reference to `gcry_xmalloc' prime.elf2flt: In function `_gcry_mpi_free_limb_space': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:102: undefined reference to `gcry_free' prime.elf2flt: In function `_gcry_mpi_resize': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:128: undefined reference to `gcry_xrealloc' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:133: undefined reference to `gcry_xcalloc_secure' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:136: undefined reference to `gcry_xcalloc' prime.elf2flt: In function `_gcry_mpi_free': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:155: undefined reference to `gcry_free' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:161: undefined reference to `_gcry_log_bug' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:162: undefined reference to `gcry_free' prime.elf2flt: In function `gcry_mpi_set_opaque': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:193: undefined reference to `gcry_free' prime.elf2flt: In function `gcry_mpi_get_opaque': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:210: undefined reference to `_gcry_log_bug' prime.elf2flt: In function `_gcry_mpi_copy': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:228: undefined reference to `gcry_is_secure' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:228: undefined reference to `gcry_xmalloc_secure' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:228: undefined reference to `gcry_xmalloc' prime.elf2flt: In function `_gcry_mpi_alloc_like': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:260: undefined reference to `gcry_is_secure' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:260: undefined reference to `gcry_malloc_secure' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:260: undefined reference to `gcry_malloc' prime.elf2flt: In function `gcry_mpi_randomize': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:385: undefined reference to `gcry_xmalloc_secure' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:385: undefined reference to `gcry_xmalloc' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:395: undefined reference to `gcry_free' prime.elf2flt: In function `gcry_mpi_set_flag': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:405: undefined reference to `_gcry_log_bug' prime.elf2flt: In function `gcry_mpi_clear_flag': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:415: undefined reference to `_gcry_log_bug' prime.elf2flt: In function `gcry_mpi_get_flag': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/mpi/mpiutil.c:425: undefined reference to `_gcry_log_bug' prime.elf2flt: In function `initialize_basics': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:147: undefined reference to `_gcry_ath_mutex_init' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:149: undefined reference to `_gcry_log_fatal' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:153: undefined reference to `_gcry_log_fatal' prime.elf2flt: In function `initialize': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:166: undefined reference to `gcry_xcalloc_secure' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:166: undefined reference to `gcry_xcalloc' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:168: undefined reference to `gcry_xcalloc_secure' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:168: undefined reference to `gcry_xcalloc' prime.elf2flt: In function `_gcry_random_dump_stats': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:211: undefined reference to `_gcry_log_info' prime.elf2flt: In function `get_random_bytes': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:268: undefined reference to `_gcry_ath_mutex_lock' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:270: undefined reference to `_gcry_log_fatal' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:286: undefined reference to `gcry_xmalloc_secure' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:286: undefined reference to `gcry_xmalloc' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:302: undefined reference to `_gcry_ath_mutex_unlock' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:304: undefined reference to `_gcry_log_fatal' prime.elf2flt: In function `gcry_randomize': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:378: undefined reference to `_gcry_ath_mutex_lock' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:380: undefined reference to `_gcry_log_fatal' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:408: undefined reference to `_gcry_ath_mutex_unlock' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:410: undefined reference to `_gcry_log_fatal' prime.elf2flt: In function `mix_pool': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:520: undefined reference to `_gcry_burn_stack' prime.elf2flt: In function `_gcry_set_random_seed_file': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:528: undefined reference to `_gcry_bug' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:529: undefined reference to `gcry_xstrdup' prime.elf2flt: In function `read_seed_file': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:563: undefined reference to `_gcry_gettext' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:563: undefined reference to `_gcry_log_info' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:568: undefined reference to `_gcry_gettext' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:568: undefined reference to `_gcry_log_info' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:574: undefined reference to `_gcry_gettext' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:574: undefined reference to `_gcry_log_info' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:580: undefined reference to `_gcry_gettext' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:580: undefined reference to `_gcry_log_info' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:587: undefined reference to `_gcry_gettext' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:587: undefined reference to `_gcry_log_info' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:600: undefined reference to `_gcry_gettext' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:600: undefined reference to `_gcry_log_fatal' prime.elf2flt: In function `_gcry_update_random_seed_file': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:645: undefined reference to `_gcry_gettext' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:645: undefined reference to `_gcry_log_info' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:649: undefined reference to `_gcry_ath_mutex_lock' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:651: undefined reference to `_gcry_log_fatal' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:680: undefined reference to `_gcry_gettext' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:680: undefined reference to `_gcry_log_info' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:683: undefined reference to `_gcry_gettext' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:683: undefined reference to `_gcry_log_info' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:688: undefined reference to `_gcry_ath_mutex_unlock' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:690: undefined reference to `_gcry_log_fatal' prime.elf2flt: In function `read_pool': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:735: undefined reference to `_gcry_log_bug' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:755: undefined reference to `_gcry_bug' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:770: undefined reference to `_gcry_bug' prime.elf2flt: In function `getfnc_gather_random': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:916: undefined reference to `_gcry_gettext' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:916: undefined reference to `_gcry_log_fatal' prime.elf2flt: In function `do_fast_random_poll': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:963: undefined reference to `_gcry_bug' prime.elf2flt: In function `_gcry_fast_random_poll': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:1031: undefined reference to `_gcry_ath_mutex_lock' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:1033: undefined reference to `_gcry_log_fatal' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:1039: undefined reference to `_gcry_ath_mutex_unlock' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:1041: undefined reference to `_gcry_log_fatal' prime.elf2flt: In function `read_random_source': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:1069: undefined reference to `_gcry_log_fatal' prime.elf2flt: In function `gather_faked': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:1082: undefined reference to `_gcry_gettext' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:1082: undefined reference to `_gcry_log_info' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:1099: undefined reference to `gcry_xmalloc' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:1109: undefined reference to `gcry_free' prime.elf2flt: In function `gcry_create_nonce': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:1133: undefined reference to `_gcry_ath_mutex_lock' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:1135: undefined reference to `_gcry_log_fatal' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:1181: undefined reference to `_gcry_ath_mutex_unlock' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/random.c:1183: undefined reference to `_gcry_log_fatal' prime.elf2flt: In function `rmd160_write': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/rmd160.c:411: undefined reference to `_gcry_burn_stack' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/rmd160.c:434: undefined reference to `_gcry_burn_stack' prime.elf2flt: In function `rmd160_final': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/rmd160.c:511: undefined reference to `_gcry_burn_stack' prime.elf2flt: In function `sha1_write': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/sha1.c:219: undefined reference to `_gcry_burn_stack' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/sha1.c:243: undefined reference to `_gcry_burn_stack' prime.elf2flt:/home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/sha1.c:304: more undefined references to `_gcry_burn_stack' follow prime.elf2flt: In function `open_device': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/rndlinux.c:55: undefined reference to `_gcry_log_fatal' prime.elf2flt: In function `_gcry_rndlinux_gather_random': /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/rndlinux.c:118: undefined reference to `_gcry_log_error' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/rndlinux.c:128: undefined reference to `_gcry_log_error' /home/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/cipher/rndlinux.c:134: undefined reference to `_gcry_log_fatal' collect2: ld returned 1 exit status make[2]: *** [prime] Error 1 make[2]: Leaving directory `/mnt/auto/oberon/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2/tests' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/mnt/auto/oberon/usuarios/hargrave/tmp/xml/uC/libgcrypt-1.2.2' make: *** [all] Error 2 sh-2.05b$ From nmav at gnutls.org Fri Mar 10 15:34:04 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri Mar 10 16:02:54 2006 Subject: rc2 Message-ID: <200603101534.04841.nmav@gnutls.org> A tiny patch to fix a bug that disallowed the removal of the RC2 symbol when requested. -- Nikos Mavrogiannopoulos -------------- next part -------------- A non-text attachment was scrubbed... Name: patch1 Type: text/x-diff Size: 424 bytes Desc: not available Url : /pipermail/attachments/20060310/8abd1229/patch1-0001.bin From n.mavrogiannopoulos at gmail.com Sat Mar 11 06:54:54 2006 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sat Mar 11 06:54:41 2006 Subject: gpg_err_code_from_errno usage Message-ID: <200603110654.54411.n.mavrogiannopoulos@gmail.com> Hello, I've noticed quite big parts of libgcrypt use the following constructions: array = gcry_calloc (strlen (elems) + 1, sizeof (*array)); if (! array) err = gpg_err_code_from_errno (errno); But how can you be sure that calloc() (or in that case gcry_calloc) will set the errno? calloc is a library call which may or may not use a system call. Even if it works on some systems, this is a very non-portable construction, which will result in no error checking in systems that do not set errno. From marcus.brinkmann at ruhr-uni-bochum.de Sat Mar 11 10:45:58 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sat Mar 11 10:49:06 2006 Subject: gpg_err_code_from_errno usage In-Reply-To: <200603110654.54411.n.mavrogiannopoulos@gmail.com> References: <200603110654.54411.n.mavrogiannopoulos@gmail.com> Message-ID: <87u0a571rd.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sat, 11 Mar 2006 06:54:54 +0100, Nikos Mavrogiannopoulos wrote: > I've noticed quite big parts of libgcrypt use the following > constructions: > > array = gcry_calloc (strlen (elems) + 1, sizeof (*array)); > if (! array) > err = gpg_err_code_from_errno (errno); > > But how can you be sure that calloc() (or in that case gcry_calloc) > will set the errno? calloc is a library call which may or may not use > a system call. Even if it works on some systems, this is a very > non-portable construction, which will result in no error checking in > systems that do not set errno. It's not in ISO C, but in POSIX. Single Unix v3 has: http://www.opengroup.org/onlinepubs/009695399/functions/calloc.html RETURN VALUE Upon successful completion with both nelem and elsize non-zero, calloc() shall return a pointer to the allocated space. If either nelem or elsize is 0, then either a null pointer or a unique pointer value that can be successfully passed to free() shall be returned. Otherwise, it shall return a null pointer [CX] [Option Start] and set errno to indicate the error. [Option End] The CX Option is: http://www.opengroup.org/onlinepubs/009695399/help/codes.html#CX [CX][Option Start] Extension to the ISO C standard [Option End] The functionality described is an extension to the ISO C standard. Application writers may make use of an extension as it is supported on all IEEE Std 1003.1-2001-conforming systems. With each function or header from the ISO C standard, a statement to the effect that ``any conflict is unintentional'' is included. That is intended to refer to a direct conflict. IEEE Std 1003.1-2001 acts in part as a profile of the ISO C standard, and it may choose to further constrain behaviors allowed to vary by the ISO C standard. Such limitations are not considered conflicts. Where additional semantics apply to a function or header, the material is identified by use of the CX margin legend. Thanks, Marcus From nmav at gnutls.org Sat Mar 11 11:52:26 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat Mar 11 11:52:06 2006 Subject: gpg_err_code_from_errno usage In-Reply-To: <87u0a571rd.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200603110654.54411.n.mavrogiannopoulos@gmail.com> <87u0a571rd.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <200603111152.26697.nmav@gnutls.org> On Sat 11 Mar 2006 10:45, Marcus Brinkmann wrote: > > But how can you be sure that calloc() (or in that case gcry_calloc) > > will set the errno? calloc is a library call which may or may not > > use a system call. Even if it works on some systems, this is a very > > non-portable construction, which will result in no error checking > > in systems that do not set errno. > It's not in ISO C, but in POSIX. Single Unix v3 has: > http://www.opengroup.org/onlinepubs/009695399/functions/calloc.html Maybe but this doesn't change my argument. It is less portable than the ISO/ANSI C behavior. Given that libgcrypt is already ported to non-UNIX systems as well[0], I would consider this a bug. [0]. Even older unix systems may not support that. regards, Nikos -- Nikos Mavrogiannopoulos From marcus.brinkmann at ruhr-uni-bochum.de Sat Mar 11 12:26:18 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sat Mar 11 12:28:57 2006 Subject: gpg_err_code_from_errno usage In-Reply-To: <200603111152.26697.nmav@gnutls.org> References: <200603110654.54411.n.mavrogiannopoulos@gmail.com> <87u0a571rd.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200603111152.26697.nmav@gnutls.org> Message-ID: <87slpp6x45.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sat, 11 Mar 2006 11:52:26 +0100, Nikos Mavrogiannopoulos wrote: > > On Sat 11 Mar 2006 10:45, Marcus Brinkmann wrote: > > > > But how can you be sure that calloc() (or in that case gcry_calloc) > > > will set the errno? calloc is a library call which may or may not > > > use a system call. Even if it works on some systems, this is a very > > > non-portable construction, which will result in no error checking > > > in systems that do not set errno. > > It's not in ISO C, but in POSIX. Single Unix v3 has: > > http://www.opengroup.org/onlinepubs/009695399/functions/calloc.html > > Maybe but this doesn't change my argument. It is less portable than > the ISO/ANSI C behavior. Given that libgcrypt is already ported to > non-UNIX systems as well[0], I would consider this a bug. ISO/ANSI C alone is not a reasonable target platform to write applications for. So, if you want to port libgcrypt to a specific platform, please say which one and tell us what changes are required to make it work on that specific platform. Only then we can consider it. Thanks, Marcus From wk at gnupg.org Sat Mar 11 15:49:02 2006 From: wk at gnupg.org (Werner Koch) Date: Sat Mar 11 15:51:58 2006 Subject: gpg_err_code_from_errno usage In-Reply-To: <200603111152.26697.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sat, 11 Mar 2006 11:52:26 +0100") References: <200603110654.54411.n.mavrogiannopoulos@gmail.com> <87u0a571rd.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200603111152.26697.nmav@gnutls.org> Message-ID: <87veuljau9.fsf@wheatstone.g10code.de> On Sat, 11 Mar 2006 11:52:26 +0100, Nikos Mavrogiannopoulos said: > On Sat 11 Mar 2006 10:45, Marcus Brinkmann wrote: >> > But how can you be sure that calloc() (or in that case gcry_calloc) >> > will set the errno? calloc is a library call which may or may not >> > use a system call. Even if it works on some systems, this is a very >> > non-portable construction, which will result in no error checking >> > in systems that do not set errno. >> It's not in ISO C, but in POSIX. Single Unix v3 has: >> http://www.opengroup.org/onlinepubs/009695399/functions/calloc.html > Maybe but this doesn't change my argument. It is less portable than > the ISO/ANSI C behavior. Given that libgcrypt is already ported to > non-UNIX systems as well[0], I would consider this a bug. To protect against ill behaving implementaions we even use some failsafe code in the internal malloc code: gcry_err_code_t gcry_malloc (size_t n, unsigned int flags, void **mem) { [...] /* Call standard malloc or user registered function. */ [...] if (!m) { /* Make sure that ERRNO has been set in case a user supplied memory handler didn't it correctly. */ if (!errno) errno = ENOMEM; err = gpg_err_code_from_errno (errno); } else *mem = m; return err; } Shalom-Salam, Werner From bradh at frogmouth.net Sun Mar 12 07:40:36 2006 From: bradh at frogmouth.net (Brad Hards) Date: Sun Mar 12 07:43:31 2006 Subject: [patch] Additional HMAC unit tests In-Reply-To: <87oe0e1uxv.fsf@wheatstone.g10code.de> References: <200602182215.20665.bradh@frogmouth.net> <87oe0e1uxv.fsf@wheatstone.g10code.de> Message-ID: <200603121740.44767.bradh@frogmouth.net> On Friday 10 March 2006 20:59 pm, Werner Koch wrote: > On Sat, 18 Feb 2006 22:15:13 +1100, Brad Hards said: > > The attached patch provides HMAC unit tests for a range of the more > > critical hashes - MD5, SHA224, SHA256, SHA384 and SHA512, using standard > > test vectors. > > I have just commited it. However teh HMAC tests for SHA-384 and > SHA-512 are failing. Would you mind to look after that? It is a problem with the blocksize (128, instead of 64) - I raised this problem in April 2005: http://lists.gnupg.org/pipermail/gcrypt-devel/2005-April/000778.html. I posted a (somewhat hacky) patch to the list: http://lists.gnupg.org/pipermail/gcrypt-devel/2005-April/000779.html [The actual patch is missing from the archive - I can resend it if required]. Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060312/d085799a/attachment.pgp From wk at gnupg.org Sun Mar 12 09:35:35 2006 From: wk at gnupg.org (Werner Koch) Date: Sun Mar 12 09:41:55 2006 Subject: [patch] Additional HMAC unit tests In-Reply-To: <200603121740.44767.bradh@frogmouth.net> (Brad Hards's message of "Sun, 12 Mar 2006 17:40:36 +1100") References: <200602182215.20665.bradh@frogmouth.net> <87oe0e1uxv.fsf@wheatstone.g10code.de> <200603121740.44767.bradh@frogmouth.net> Message-ID: <87oe0cjc14.fsf@wheatstone.g10code.de> On Sun, 12 Mar 2006 17:40:36 +1100, Brad Hards said: > It is a problem with the blocksize (128, instead of 64) - I raised this > problem in April 2005: > http://lists.gnupg.org/pipermail/gcrypt-devel/2005-April/000778.html. I had something like this in mind... > I posted a (somewhat hacky) patch to the list: > http://lists.gnupg.org/pipermail/gcrypt-devel/2005-April/000779.html > [The actual patch is missing from the archive - I can resend it if required]. .. but did not found the pacth. Please resend it. Thanks, Werner From pak21 at srcf.ucam.org Sat Mar 11 11:25:34 2006 From: pak21 at srcf.ucam.org (Philip Kendall) Date: Mon Mar 13 10:42:21 2006 Subject: gpg_err_code_from_errno usage In-Reply-To: <200603110654.54411.n.mavrogiannopoulos@gmail.com> References: <200603110654.54411.n.mavrogiannopoulos@gmail.com> Message-ID: <20060311102534.GA17931@srcf.ucam.org> On Sat, Mar 11, 2006 at 06:54:54AM +0100, Nikos Mavrogiannopoulos wrote: > > But how can you be sure that calloc() (or in that case gcry_calloc) > will set the errno? calloc is a library call which may or may not use > a system call. Even if it works on some systems, this is a very > non-portable construction, which will result in no error checking in > systems that do not set errno. gcrypt makes certain assumptions about the system on which in it is running. One of these is ANSI C compliance (which guarantees that calloc() will set errno). I wouldn't exactly call that "very non-portable". Cheers, Phil -- "In case de curse does not succeed, dis is my lucky stake. I have killed many vampires wit it. I call it Mr. Pointy." "You named your stake?" "Yes." "Remind me to get you a stuffed animal." Kendra and Buffy: Becoming, Part 1 From marcus.brinkmann at ruhr-uni-bochum.de Mon Mar 13 14:19:09 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Mar 13 14:18:55 2006 Subject: gpg_err_code_from_errno usage In-Reply-To: References: <200603110654.54411.n.mavrogiannopoulos@gmail.com> <87u0a571rd.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200603111152.26697.nmav@gnutls.org> <87veuljau9.fsf@wheatstone.g10code.de> Message-ID: <87oe0a7a9e.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Mon, 13 Mar 2006 13:54:48 +0100, Nikos Mavrogiannopoulos wrote: > In any case I don't find any benefit into checking errno for memory > allocation. The value is not interesting at all, and it adds > complexity to the code. Normally, you don't check. You just return the value that's stored in errno in case of allocation failure. Your concern was that some systems may not set errno. This can only be addressed by either coding behaviour specifically for these systems, or by a generic check. The check is necessary so that if errno is returned, it is not overwritten. There is also the question to what errno should be set on bogus systems. Can we rely on ENOMEM? By what justification? It is not mandated by ISO C99 either. I would really like to see a list of systems where malloc and friends don't set errno. As for complexity: You call for the complexity by asking to support systems that don't support the respective standards. Thanks, Marcus From nmav at gnutls.org Mon Mar 13 13:54:48 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon Mar 13 14:50:30 2006 Subject: gpg_err_code_from_errno usage In-Reply-To: <87veuljau9.fsf@wheatstone.g10code.de> References: <200603110654.54411.n.mavrogiannopoulos@gmail.com> <87u0a571rd.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200603111152.26697.nmav@gnutls.org> <87veuljau9.fsf@wheatstone.g10code.de> Message-ID: On 3/11/06, Werner Koch wrote: > > Maybe but this doesn't change my argument. It is less portable than > > the ISO/ANSI C behavior. Given that libgcrypt is already ported to > > non-UNIX systems as well[0], I would consider this a bug. > To protect against ill behaving implementaions we even use some > failsafe code in the internal malloc code: Ok, thanks, then my concern of this behaviour not working is addressed. A small bug in the code is that errno is not set to zero before thus if a system does not set errno, and errno (most likely) contains some previous value that value will be detected. In any case I don't find any benefit into checking errno for memory allocation. The value is not interesting at all, and it adds complexity to the code. Nikos From jas at extundo.com Wed Mar 15 14:56:07 2006 From: jas at extundo.com (Simon Josefsson) Date: Wed Mar 15 14:55:30 2006 Subject: libgpg-error 1.3 and gettext Message-ID: <877j6vbymg.fsf@latte.josefsson.org> Version 1.3 build slightly better, but still fail on some systems, builds logs: http://josefsson.org/autobuild-logs/libgpg-error-1.3.tar.gz-x86-solaris1-output http://josefsson.org/autobuild-logs/libgpg-error-1.3-td176.testdrive.hp.com-output http://josefsson.org/autobuild-logs/libgpg-error-1.3-td192.testdrive.hp.com-output When I spoke to Bruno about gettext problems in libraries in the past he convinced that it is better to avoid putting a copy of libintl in the library, but instead just disable the use of gettext in the library when gettext isn't available. The library will build more easily and work fine, and if someone wonder whether translated messages aren't available, the answer is that she should install gettext first. /Simon From bradh at frogmouth.net Thu Mar 16 10:42:00 2006 From: bradh at frogmouth.net (Brad Hards) Date: Thu Mar 16 11:26:44 2006 Subject: Missing commit for pth config check? Message-ID: <200603162042.06736.bradh@frogmouth.net> the new gcryptrnd application (daemon?) won't compile (with or without pth) However there is no ./configure check that checks pth is available. I started to write a check, but then noticed that most of it is there. Is there just a missing check like: Index: src/Makefile.am =================================================================== --- src/Makefile.am (revision 1149) +++ src/Makefile.am (working copy) @@ -25,7 +25,9 @@ include_HEADERS = gcrypt.h gcrypt-module.h lib_LTLIBRARIES = libgcrypt.la -sbin_PROGRAMS = gcryptrnd +if HAVE_PTH + sbin_PROGRAMS = gcryptrnd +endif bin_PROGRAMS = getrandom if HAVE_LD_VERSION_SCRIPT Index: configure.ac =================================================================== --- configure.ac (revision 1149) +++ configure.ac (working copy) @@ -437,6 +437,9 @@ [AC_SEARCH_LIBS(setsockopt, [socket], , , [-lnsl])]) AC_SEARCH_LIBS(setsockopt, [nsl]) +AC_CHECK_PTH(2.0.6,,,,have_pth=yes,) +AM_CONDITIONAL(HAVE_PTH, test x$have_pth = xyes) + ################################## #### Checks for header files. #### ################################## Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060316/1c5ef852/attachment.pgp From wk at gnupg.org Fri Mar 17 16:58:28 2006 From: wk at gnupg.org (Werner Koch) Date: Fri Mar 17 17:01:56 2006 Subject: Missing commit for pth config check? In-Reply-To: <200603162042.06736.bradh@frogmouth.net> (Brad Hards's message of "Thu, 16 Mar 2006 20:42:00 +1100") References: <200603162042.06736.bradh@frogmouth.net> Message-ID: <87bqw5dpwb.fsf@wheatstone.g10code.de> On Thu, 16 Mar 2006 20:42:00 +1100, Brad Hards said: > the new gcryptrnd application (daemon?) won't compile (with or without pth) > However there is no ./configure check that checks pth is available. I started > to write a check, but then noticed that most of it is there. Is there just a > missing check like: Sorry, I might have missed to commit that. Done right now. The checks are anyway not ready as wee need to check for several other things before we can build gcryptrnd. > +AC_CHECK_PTH(2.0.6,,,,have_pth=yes,) I prefer to use the check as used by GnuPG which is much simpler and not as error prone as the official pth check. Shalom-Salam, Werner From bradh at frogmouth.net Thu Mar 30 11:27:03 2006 From: bradh at frogmouth.net (Brad Hards) Date: Thu Mar 30 13:10:15 2006 Subject: ksba documentation? Message-ID: <200603301927.10875.bradh@frogmouth.net> I raised a patch against the ksba docs in the aegypten tracker: http://www.intevation.de/roundup/aegypten/issue488 Any chance that this can be applied? Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060330/e2e3fb08/attachment.pgp From wk at gnupg.org Thu Mar 30 16:47:19 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Mar 30 16:51:45 2006 Subject: ksba documentation? In-Reply-To: <200603301927.10875.bradh@frogmouth.net> (Brad Hards's message of "Thu, 30 Mar 2006 19:27:03 +1000") References: <200603301927.10875.bradh@frogmouth.net> Message-ID: <87hd5g56rs.fsf@wheatstone.g10code.de> On Thu, 30 Mar 2006 19:27:03 +1000, Brad Hards said: > I raised a patch against the ksba docs in the aegypten tracker: > http://www.intevation.de/roundup/aegypten/issue488 > Any chance that this can be applied? Done. Thanks. Sorry, I have not followed the Aegypten tracker for quite some time. Shalom-Salam, Werner