From n3npq at mac.com Wed Jun 9 20:40:04 2010 From: n3npq at mac.com (Jeff Johnson) Date: Wed, 09 Jun 2010 14:40:04 -0400 Subject: ECDSA genkey w GCRY_VERY_STRONG_RANDOM is painfully slow Message-ID: Attached is a patch to decrease random strength if "(transient-key)" is in the S-expr (just like RSA/DSA). BTW, I'm also seeing this building from gcrypt SVN trunk on RHEL6 beta using this malloc voo-doo in ~/.bash_profile: export MALLOC_CHECK_=3 # http://udrepper.livejournal.com/11429.html export MALLOC_PERTURB_=$(($RANDOM % 255 + 1)) *** glibc detected *** /X/src/libgcrypt/tests/.libs/lt-t-mpi-bit: free(): invalid pointer: 0x0a022bf8 *** ======= Backtrace: ========= /lib/libc.so.6[0x61c861] /lib/libc.so.6(cfree+0xf0)[0x6214a0] /X/src/libgcrypt/src/.libs/libgcrypt.so.11(+0xba3c)[0x427a3c] /X/src/libgcrypt/src/.libs/libgcrypt.so.11(+0x7c38)[0x423c38] /X/src/libgcrypt/src/.libs/libgcrypt.so.11(gcry_free+0x1d)[0x4207bd] /X/src/libgcrypt/tests/.libs/lt-t-mpi-bit[0x80493d1] /lib/libc.so.6(__libc_start_main+0xe6)[0x5c4bb6] /X/src/libgcrypt/tests/.libs/lt-t-mpi-bit[0x8048a31] ======= Memory map: ======== 00280000-00281000 r-xp 00000000 00:00 0 [vdso] 0041c000-0048d000 r-xp 00000000 fd:00 1444033 /X/src/libgcrypt/src/.libs/libgcrypt.so.11.6.0 0048d000-00490000 rw-p 00070000 fd:00 1444033 /X/src/libgcrypt/src/.libs/libgcrypt.so.11.6.0 00588000-005a6000 r-xp 00000000 fd:00 138742 /lib/ld-2.11.1.so 005a6000-005a7000 r--p 0001d000 fd:00 138742 /lib/ld-2.11.1.so 005a7000-005a8000 rw-p 0001e000 fd:00 138742 /lib/ld-2.11.1.so 005ae000-00729000 r-xp 00000000 fd:00 138744 /lib/libc-2.11.1.so 00729000-0072a000 ---p 0017b000 fd:00 138744 /lib/libc-2.11.1.so 0072a000-0072c000 r--p 0017b000 fd:00 138744 /lib/libc-2.11.1.so 0072c000-0072d000 rw-p 0017d000 fd:00 138744 /lib/libc-2.11.1.so 0072d000-00730000 rw-p 00000000 00:00 0 00732000-00735000 r-xp 00000000 fd:00 131244 /lib/libdl-2.11.1.so 00735000-00736000 r--p 00002000 fd:00 131244 /lib/libdl-2.11.1.so 00736000-00737000 rw-p 00003000 fd:00 131244 /lib/libdl-2.11.1.so 00889000-0088c000 r-xp 00000000 fd:00 139535 /lib/libgpg-error.so.0.6.0 0088c000-0088d000 rw-p 00002000 fd:00 139535 /lib/libgpg-error.so.0.6.0 00942000-0095f000 r-xp 00000000 fd:00 138762 /lib/libgcc_s-4.4.3-20100121.so.1 0095f000-00960000 rw-p 0001c000 fd:00 138762 /lib/libgcc_s-4.4.3-20100121.so.1 08048000-0804a000 r-xp 00000000 fd:00 1447630 /X/src/libgcrypt/tests/.libs/lt-t-mpi-bit 0804a000-0804b000 rw-p 00001000 fd:00 1447630 /X/src/libgcrypt/tests/.libs/lt-t-mpi-bit 0a022000-0a043000 rw-p 00000000 00:00 0 [heap] b780f000-b7811000 rw-p 00000000 00:00 0 b7821000-b7822000 rw-p 00000000 00:00 0 bfa40000-bfa55000 rw-p 00000000 00:00 0 [stack] /bin/sh: line 5: 20427 Aborted ${dir}$tst FAIL: t-mpi-bit I'll dig out the flaw somewhen and send a patch, just busy & lazy ... Is there any time line for ECDSA into RFC 2440/4880? I'll be happy to test and help whenever, been waiting for more than a year already ... hth 73 de Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: gcrypt.patch Type: application/octet-stream Size: 2028 bytes Desc: not available URL: From wk at gnupg.org Thu Jun 10 11:07:14 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Jun 2010 11:07:14 +0200 Subject: ECDSA genkey w GCRY_VERY_STRONG_RANDOM is painfully slow In-Reply-To: (Jeff Johnson's message of "Wed, 09 Jun 2010 14:40:04 -0400") References: Message-ID: <87pqzz45od.fsf@vigenere.g10code.de> On Wed, 9 Jun 2010 20:40, n3npq at mac.com said: > Attached is a patch to decrease random strength if "(transient-key)" > is in the S-expr (just like RSA/DSA). Applied. Thanks. > BTW, I'm also seeing this building from gcrypt SVN trunk on RHEL6 beta > using this malloc voo-doo in ~/.bash_profile: Fixed. Here is a patch which can also be used for 1.4: 2010-06-10 Werner Koch * t-mpi-bit.c (mpi2bitstr_nlz): Handle case for LENGTH==0. --- tests/t-mpi-bit.c (revision 1429) +++ tests/t-mpi-bit.c (working copy) @@ -108,13 +108,20 @@ { char *p, *buf; size_t length = gcry_mpi_get_nbits (a); - - buf = p = xmalloc (length + 1); - while (length-- > 1) - *p++ = gcry_mpi_test_bit (a, length) ? '1':'0'; - *p++ = gcry_mpi_test_bit (a, 0) ? '1':'0'; + + if (!length) + { + buf = p = xmalloc (2); + *p++ = '0'; + } + else + { + buf = p = xmalloc (length + 1); + while (length-- > 1) + *p++ = gcry_mpi_test_bit (a, length) ? '1':'0'; + *p++ = gcry_mpi_test_bit (a, 0) ? '1':'0'; + } *p = 0; - return buf; } Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From honia2002 at hotmail.com Mon Jun 14 15:55:22 2010 From: honia2002 at hotmail.com (honi@) Date: Mon, 14 Jun 2010 06:55:22 -0700 (PDT) Subject: =?UTF-8?Q?network.so:_undefined_sym?= =?UTF-8?Q?bol:_gcry=5Fmd=5Fhash=5Fbuffer=E2=80=8F?= Message-ID: <28879871.post@talk.nabble.com> Hi, I am installing collectd-4.10.0 on a CentOS 5 machine: 1) Configured collectd: ./configure --with-librrd=/opt/rrdtool-1.4.3/ --with-liboping=/opt/oping --with-libnetlink=/home/username/iproute2-2.6.29-1 --with-libgcrypt=/usr/lib 2) make followed by make install 3) Configured collectd.conf and this is the network plugin: SecurityLevel "Sign" Username "client2" Password "password2" # TimeToLive "128" # Forward false # CacheFlush 1800 # ReportStats false 4) Restarted collectd and got the following error: Stopping collectd: [FAILED] Starting collectd: /opt/collectd/sbin/collectd: symbol lookup error: /opt/collectd/lib/collectd/network.so: undefined symbol: gcry_md_hash_buffer I looked everywhere to find the problem but had no luck. I installed the same version of collectd on another machine exactly the steps above but it went smoothly and had no problem. Can someone please help me with this? Thanks in advace, honi@ -- View this message in context: http://old.nabble.com/network.so%3A-undefined-symbol%3A-gcry_md_hash_buffer%E2%80%8F-tp28879871p28879871.html Sent from the GnuPG - Libgcrypt - Dev mailing list archive at Nabble.com. From rgetz at blackfin.uclinux.org Tue Jun 15 19:26:23 2010 From: rgetz at blackfin.uclinux.org (Robin Getz) Date: Tue, 15 Jun 2010 13:26:23 -0400 Subject: Problem building 1.4.5 Message-ID: <201006151326.23861.rgetz@blackfin.uclinux.org> When I build up libgcrypt-1.4.5, the lib appears to build fine, but nothing can link against it because of the way that hidden symbols are managed... When trying to link against the lib, I get: version.o: In function `main': ./libgcrypt-1.4.5/tests/version.c:47: undefined reference to `_gcry_control' ./libgcrypt-1.4.5/tests/version.c:48: undefined reference to `_gcry_check_version' ./libgcrypt-1.4.5/tests/version.c:54: undefined reference to `_gcry_control' collect2: ld returned 1 exit status make[4]: *** [version] Error 1 This is because the ABI for Blackfin (the CPU I'm building for) includes a leading underscore "_" in the assembly/linker symbol prefixes. The ABI automatically turns the C symbol "gcry_control", into "_gcry_control" in the .so, and thus turns "_gcry_control" into "__gcry_control". configure understands this: ./config.log has: #define WITH_SYMBOL_UNDERSCORE 1 but that doesn't seem to be used in ./src/visibility.h in the MARK_VISIBLE macros, etc - which seems to be where things are managed. -Robin From wk at gnupg.org Wed Jun 16 11:23:00 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 Jun 2010 11:23:00 +0200 Subject: Problem building 1.4.5 In-Reply-To: <201006151326.23861.rgetz@blackfin.uclinux.org> (Robin Getz's message of "Tue, 15 Jun 2010 13:26:23 -0400") References: <201006151326.23861.rgetz@blackfin.uclinux.org> Message-ID: <874oh3xrez.fsf@vigenere.g10code.de> On Tue, 15 Jun 2010 19:26, rgetz at blackfin.uclinux.org said: > The ABI automatically turns the C symbol "gcry_control", into "_gcry_control" > in the .so, and thus turns "_gcry_control" into "__gcry_control". That is pretty standard on most systems. > ./config.log has: > #define WITH_SYMBOL_UNDERSCORE 1 This is only used for the asm files see (libgcrypt/mpi/Makefile.am) and not the problem at hand. > but that doesn't seem to be used in ./src/visibility.h in the MARK_VISIBLE > macros, etc - which seems to be where things are managed. I guess the problem is with the the version script feature of GNU linkers. What does grep HAVE_LD_VERSION_SCRIPT config.status show? On a GNU system this should yield S["HAVE_LD_VERSION_SCRIPT_FALSE"]="#" S["HAVE_LD_VERSION_SCRIPT_TRUE"]="" If this is the case something is wrong with the linker for the system, disable this feature using ./configure --disable-ld-version-script and try building again. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rgetz at blackfin.uclinux.org Thu Jun 17 00:13:37 2010 From: rgetz at blackfin.uclinux.org (Robin Getz) Date: Wed, 16 Jun 2010 18:13:37 -0400 Subject: Problem building 1.4.5 In-Reply-To: <874oh3xrez.fsf@vigenere.g10code.de> References: <201006151326.23861.rgetz@blackfin.uclinux.org> <874oh3xrez.fsf@vigenere.g10code.de> Message-ID: <201006161813.37622.rgetz@blackfin.uclinux.org> On Wed 16 Jun 2010 05:23, Werner Koch pondered: > On Tue, 15 Jun 2010 19:26, rgetz at blackfin.uclinux.org said: > > > The ABI automatically turns the C symbol "gcry_control", into "_gcry_control" > > in the .so, and thus turns "_gcry_control" into "__gcry_control". > > That is pretty standard on most systems. On some - but I wouldn't say "most", its actually pretty uncommon now-a-days. cat foo.c int main (void) { return 0; } gcc foo.c -o foo nm foo 00000000004004c4 T main bfin-elf-gcc -mcpu=bf548-0.2 foo.c -o foo bfin-elf-nm foo ffa00270 T _main > > ./config.log has: > > #define WITH_SYMBOL_UNDERSCORE 1 > > This is only used for the asm files see (libgcrypt/mpi/Makefile.am) and > not the problem at hand. > > > but that doesn't seem to be used in ./src/visibility.h in the MARK_VISIBLE > > macros, etc - which seems to be where things are managed. > > I guess the problem is with the the version script feature of GNU > linkers. What does > > grep HAVE_LD_VERSION_SCRIPT config.status > > show? On a GNU system this should yield > > S["HAVE_LD_VERSION_SCRIPT_FALSE"]="#" > S["HAVE_LD_VERSION_SCRIPT_TRUE"]="" Which it does: S["HAVE_LD_VERSION_SCRIPT_FALSE"]="#" S["HAVE_LD_VERSION_SCRIPT_TRUE"]="" > If this is the case something is wrong with the linker for the system, > disable this feature using > > ./configure --disable-ld-version-script > > and try building again. That fixes things - but can you describe what you mean when you say "something wrong with the linker"? From wk at gnupg.org Thu Jun 17 09:44:09 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Jun 2010 09:44:09 +0200 Subject: Problem building 1.4.5 In-Reply-To: <201006161813.37622.rgetz@blackfin.uclinux.org> (Robin Getz's message of "Wed, 16 Jun 2010 18:13:37 -0400") References: <201006151326.23861.rgetz@blackfin.uclinux.org> <874oh3xrez.fsf@vigenere.g10code.de> <201006161813.37622.rgetz@blackfin.uclinux.org> Message-ID: <87bpbaw1bq.fsf@vigenere.g10code.de> On Thu, 17 Jun 2010 00:13, rgetz at blackfin.uclinux.org said: > On some - but I wouldn't say "most", its actually pretty uncommon now-a-days. Well on GNU systems it is uncommon. Given that we enable the version script feature only on GNU systems it is no surprise that we did not run into problems until now. I found a 2 years ol message thread on the same problem on Blackfin with no clean solution. Our assumption was that libtool takes care of symbol prefixing which it actually does when using a list of symbols. With the evrsion script it does not. The solution is to prefix the symbols in the version script file. For libgcrypt this is not a problem becuase we need to figure out the prefix anyway but for other libaries we don't need that and thus it would be better if libtool supports this or LD would take an option to prefix symbols from the version script. Please use the disable switch until we found a clean solution. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From vapier.adi at gmail.com Thu Jun 17 00:18:47 2010 From: vapier.adi at gmail.com (Mike Frysinger) Date: Wed, 16 Jun 2010 18:18:47 -0400 Subject: Problem building 1.4.5 In-Reply-To: <201006161813.37622.rgetz@blackfin.uclinux.org> References: <201006151326.23861.rgetz@blackfin.uclinux.org> <874oh3xrez.fsf@vigenere.g10code.de> <201006161813.37622.rgetz@blackfin.uclinux.org> Message-ID: On Wed, Jun 16, 2010 at 18:13, Robin Getz wrote: > On Wed 16 Jun 2010 05:23, Werner Koch pondered: >> If this is the case something is wrong with the linker for the system, >> disable this feature using >> >> ? ./configure --disable-ld-version-script >> >> and try building again. > > That fixes things - but can you describe what you mean when you say > "something wrong with the linker"? the version script operates on linker-visible symbols, not on C visible symbols, so the linker is operating correctly. this is why projects like alsa-lib have the version script be a .in file and it prefixes all symbols with like @SYMBOL_PREFIX at . then the configure script processes that into the final version script with @SYMBOL_PREFIX@ replaced with "_" or "" depending on the configure detected needs of the target system. considering support is apparently already there via WITH_SYMBOL_UNDERSCORE, seems like it should be pretty easy to extend this. -mike From dkg at fifthhorseman.net Thu Jun 17 17:12:39 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 17 Jun 2010 11:12:39 -0400 Subject: network.so: undefined symbol: =?UTF-8?B?Z2NyeV9tZF9oYXNoX2J1?= =?UTF-8?B?ZmZlcuKAjw==?= In-Reply-To: References: <28879871.post@talk.nabble.com>, <4C1A2DBB.6080106@fifthhorseman.net> Message-ID: <4C1A3B67.2060304@fifthhorseman.net> On 06/17/2010 10:52 AM, Honia A wrote: > 1) readelf -s /opt/collectd/lib/collectd/network.so | grep md_hash > > 93: 00000000 0 NOTYPE GLOBAL DEFAULT UND gcry_md_hash_buffer > 239: 00000000 0 NOTYPE GLOBAL DEFAULT UND gcry_md_hash_buffer > > 2) ldd /opt/collectd/lib/collectd/network.so | grep gcry > > I got no output here this seems weird to me. can you show the full output of: ldd /opt/collectd/lib/collectd/network.so why would it reference a symbol of a library that it doesn't link to? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Jun 17 16:14:19 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 17 Jun 2010 10:14:19 -0400 Subject: network.so: undefined symbol: =?UTF-8?B?Z2NyeV9tZF9oYXNoX2J1?= =?UTF-8?B?ZmZlcuKAjw==?= In-Reply-To: <28879871.post@talk.nabble.com> References: <28879871.post@talk.nabble.com> Message-ID: <4C1A2DBB.6080106@fifthhorseman.net> On 06/14/2010 09:55 AM, honi@ wrote: > I am installing collectd-4.10.0 on a CentOS 5 machine: I don't use collectd or CentOS, but i'm happy to help you debug: > 4) Restarted collectd and got the following error: > > Stopping collectd: [FAILED] > Starting collectd: /opt/collectd/sbin/collectd: symbol lookup error: > /opt/collectd/lib/collectd/network.so: undefined symbol: gcry_md_hash_buffer what output do you get from: readelf -s /opt/collectd/lib/collectd/network.so | grep md_hash ldd /opt/collectd/lib/collectd/network.so | grep gcry readelf -s /usr/lib/libgcrypt.so.11 | grep md_hash ? when i install debian's packaged collectd 4.9.1-2 on a testing system, i see this on the equivalent files: >> 0 dkg at pip:~$ readelf -s /usr/lib/collectd/network.so | grep md_hash >> 87: 00000000 0 FUNC GLOBAL DEFAULT UND gcry_md_hash_buffer at GCRYPT_1.2 (5) >> 0 dkg at pip:~$ ldd /usr/lib/collectd/network.so | grep gcry >> libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb7661000) >> 0 dkg at pip:~$ readelf -s /usr/lib/libgcrypt.so.11 | grep md_hash >> 101: 00006130 115 FUNC GLOBAL DEFAULT 13 gcry_md_hash_buffer@@GCRYPT_1.2 >> 0 dkg at pip:~$ i think these three lines of output mean: /usr/lib/collectd/network.so expects to see gcry_md_hash_bufer at GCRYPT1.2 in some library that it will load (it is undefined internally, hence the "UND") /usr/lib/collectd/network.so expects to load libgcrypt.so.11, which the dynamic linker finds in /usr/lib /usr/lib/libgcrypt.so.11 contains a defined symbol gcry_md_hash_bufer at GCRYPT1.2 maybe one of these doesn't line up for you somehow? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From honia2002 at hotmail.com Thu Jun 17 16:52:51 2010 From: honia2002 at hotmail.com (Honia A) Date: Thu, 17 Jun 2010 10:52:51 -0400 Subject: =?windows-1256?Q?RE:_networ?= =?windows-1256?Q?k.so:_unde?= =?windows-1256?Q?fined_symb?= =?windows-1256?Q?ol:_gcry=5Fm?= =?windows-1256?Q?d=5Fhash=5Fbuf?= =?windows-1256?Q?fer=FE?= In-Reply-To: <4C1A2DBB.6080106@fifthhorseman.net> References: <28879871.post@talk.nabble.com>,<4C1A2DBB.6080106@fifthhorseman.net> Message-ID: Good morning dkg, Thanks for your helpful reply. I removed the collectd package and started over, this time gave collectd a different path for libgcrypt: ./configure --with-librrd=/opt/rrdtool-1.4.3/ --with-liboping=/opt/oping --with-libnetlink=/home/username/iproute2-2.6.29-1 --with-libgcrypt=/usr/local I ran all your commands and here are the outputs: (in red) 1) readelf -s /opt/collectd/lib/collectd/network.so | grep md_hash 93: 00000000 0 NOTYPE GLOBAL DEFAULT UND gcry_md_hash_buffer 239: 00000000 0 NOTYPE GLOBAL DEFAULT UND gcry_md_hash_buffer 2) ldd /opt/collectd/lib/collectd/network.so | grep gcry I got no output here 3) readelf -s /usr/lib/libgcrypt.so.11 | grep md_hash 109: 00005570 115 FUNC GLOBAL DEFAULT 11 gcry_md_hash_buffer@@GCRYPT_1.2 Somethings I noticed are: 1) Network.la has a line in it which reads: # Libraries that this one depends upon. dependency_libs=' -L/usr/local/lib -lpthread -ldl' 2) libgcrypt-config file is located here: /usr/local/bin/libgcrypt-config /home/username/libgcrypt-1.4.5/src/libgcrypt-config 3) In libgcrypt-config: includedir = /usr/local/include libdir=/usr/local/lib 4) Inside collectd's src directory's network.c there is a line which reads: # if HAVE_LIBGCRYPT # include GCRYPT_THREAD_OPTION_PTHREAD_IMPL # endif 5) find / -name libgcrypt.so /usr/local/lib/libgcrypt.so /home/username/libgcrypt-1.4.5/src/.libs/libgcrypt.so In the libgcrypt manual, it says that I have to do the following: "If you want to compile a source file including the `gcrypt.h' header file, you must make sure that the compiler can find it in the directory hierarchy. This is accomplished by adding the path to the directory in which the header file is located to the compilers include file search path (via the -I option). However, the path to the include file is determined at the time the source is configured. To solve this problem, Libgcrypt ships with a small helper program libgcrypt-config that knows the path to the include file and other configuration options. The options that need to be added to the compiler invocation at compile time are output by the --cflags option to libgcrypt-config. The following example shows how it can be used at the command line: " gcc -c foo.c `libgcrypt-config --cflags` So I tried to link the network source code to libgcrypt library via command below but got so many errors. gcc -c network.c `libgcrypt-config --cflags` Thanks in advance for the help, Honi@ > Date: Thu, 17 Jun 2010 10:14:19 -0400 > From: dkg at fifthhorseman.net > To: honia2002 at hotmail.com > CC: gcrypt-devel at gnupg.org > Subject: Re: network.so: undefined symbol: gcry_md_hash_buffer? > > On 06/14/2010 09:55 AM, honi@ wrote: > > I am installing collectd-4.10.0 on a CentOS 5 machine: > > I don't use collectd or CentOS, but i'm happy to help you debug: > > > 4) Restarted collectd and got the following error: > > > > Stopping collectd: [FAILED] > > Starting collectd: /opt/collectd/sbin/collectd: symbol lookup error: > > /opt/collectd/lib/collectd/network.so: undefined symbol: gcry_md_hash_buffer > > > what output do you get from: > > readelf -s /opt/collectd/lib/collectd/network.so | grep md_hash > > ldd /opt/collectd/lib/collectd/network.so | grep gcry > > readelf -s /usr/lib/libgcrypt.so.11 | grep md_hash > > ? > > when i install debian's packaged collectd 4.9.1-2 on a testing system, i > see this on the equivalent files: > > >> 0 dkg at pip:~$ readelf -s /usr/lib/collectd/network.so | grep md_hash > >> 87: 00000000 0 FUNC GLOBAL DEFAULT UND gcry_md_hash_buffer at GCRYPT_1.2 (5) > >> 0 dkg at pip:~$ ldd /usr/lib/collectd/network.so | grep gcry > >> libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb7661000) > >> 0 dkg at pip:~$ readelf -s /usr/lib/libgcrypt.so.11 | grep md_hash > >> 101: 00006130 115 FUNC GLOBAL DEFAULT 13 gcry_md_hash_buffer@@GCRYPT_1.2 > >> 0 dkg at pip:~$ > > > i think these three lines of output mean: > > /usr/lib/collectd/network.so expects to see > gcry_md_hash_bufer at GCRYPT1.2 in some library that it will load (it is > undefined internally, hence the "UND") > > /usr/lib/collectd/network.so expects to load libgcrypt.so.11, which the > dynamic linker finds in /usr/lib > > /usr/lib/libgcrypt.so.11 contains a defined symbol > gcry_md_hash_bufer at GCRYPT1.2 > > maybe one of these doesn't line up for you somehow? > > --dkg > _________________________________________________________________ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From honia2002 at hotmail.com Thu Jun 17 17:23:03 2010 From: honia2002 at hotmail.com (Honia A) Date: Thu, 17 Jun 2010 11:23:03 -0400 Subject: =?windows-1256?Q?RE:_networ?= =?windows-1256?Q?k.so:_unde?= =?windows-1256?Q?fined_symb?= =?windows-1256?Q?ol:_gcry=5Fm?= =?windows-1256?Q?d=5Fhash=5Fbuf?= =?windows-1256?Q?fer=FE?= In-Reply-To: <4C1A3B67.2060304@fifthhorseman.net> References: <28879871.post@talk.nabble.com>,<4C1A2DBB.6080106@fifthhorseman.net> , <4C1A3B67.2060304@fifthhorseman.net> Message-ID: Thank you for your reply. Here's the full output: linux-gate.so.1 => (0x00691000) libpthread.so.0 => /lib/libpthread.so.0 (0x00eb6000) libdl.so.2 => /lib/libdl.so.2 (0x00d47000) libc.so.6 => /lib/libc.so.6 (0x00110000) /lib/ld-linux.so.2 (0x002c3000) Regards, h > Date: Thu, 17 Jun 2010 11:12:39 -0400 > From: dkg at fifthhorseman.net > To: honia2002 at hotmail.com > CC: gcrypt-devel at gnupg.org > Subject: Re: network.so: undefined symbol: gcry_md_hash_buffer? > > On 06/17/2010 10:52 AM, Honia A wrote: > > 1) readelf -s /opt/collectd/lib/collectd/network.so | grep md_hash > > > > 93: 00000000 0 NOTYPE GLOBAL DEFAULT UND gcry_md_hash_buffer > > 239: 00000000 0 NOTYPE GLOBAL DEFAULT UND gcry_md_hash_buffer > > > > 2) ldd /opt/collectd/lib/collectd/network.so | grep gcry > > > > I got no output here > > this seems weird to me. can you show the full output of: > > ldd /opt/collectd/lib/collectd/network.so > > why would it reference a symbol of a library that it doesn't link to? > > --dkg > _________________________________________________________________ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From honia2002 at hotmail.com Thu Jun 17 17:59:28 2010 From: honia2002 at hotmail.com (Honia A) Date: Thu, 17 Jun 2010 11:59:28 -0400 Subject: =?windows-1256?Q?RE:_networ?= =?windows-1256?Q?k.so:_unde?= =?windows-1256?Q?fined_symb?= =?windows-1256?Q?ol:_gcry=5Fm?= =?windows-1256?Q?d=5Fhash=5Fbuf?= =?windows-1256?Q?fer=FE?= In-Reply-To: <4C1A3B67.2060304@fifthhorseman.net> References: <28879871.post@talk.nabble.com>,<4C1A2DBB.6080106@fifthhorseman.net> , <4C1A3B67.2060304@fifthhorseman.net> Message-ID: Thank you for your reply. Here's the full output: linux-gate.so.1 => (0x00691000) libpthread.so.0 => /lib/libpthread.so.0 (0x00eb6000) libdl.so.2 => /lib/libdl.so.2 (0x00d47000) libc.so.6 => /lib/libc.so.6 (0x00110000) /lib/ld-linux.so.2 (0x002c3000) Regards, h > Date: Thu, 17 Jun 2010 11:12:39 -0400 > From: dkg at fifthhorseman.net > To: honia2002 at hotmail.com > CC: gcrypt-devel at gnupg.org > Subject: Re: network.so: undefined symbol: gcry_md_hash_buffer? > > On 06/17/2010 10:52 AM, Honia A wrote: > > 1) readelf -s /opt/collectd/lib/collectd/network.so | grep md_hash > > > > 93: 00000000 0 NOTYPE GLOBAL DEFAULT UND gcry_md_hash_buffer > > 239: 00000000 0 NOTYPE GLOBAL DEFAULT UND gcry_md_hash_buffer > > > > 2) ldd /opt/collectd/lib/collectd/network.so | grep gcry > > > > I got no output here > > this seems weird to me. can you show the full output of: > > ldd /opt/collectd/lib/collectd/network.so > > why would it reference a symbol of a library that it doesn't link to? > > --dkg > _________________________________________________________________ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Thu Jun 17 18:16:06 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 17 Jun 2010 12:16:06 -0400 Subject: network.so: undefined symbol: =?UTF-8?B?Z2NyeV9tZF9oYXNoX2J1?= =?UTF-8?B?ZmZlcuKAjw==?= In-Reply-To: References: <28879871.post@talk.nabble.com>, <4C1A2DBB.6080106@fifthhorseman.net> , <4C1A3B67.2060304@fifthhorseman.net> Message-ID: <4C1A4A46.4050801@fifthhorseman.net> On 06/17/2010 11:23 AM, Honia A wrote: > > Thank you for your reply. Here's the full output: > > linux-gate.so.1 => (0x00691000) > libpthread.so.0 => /lib/libpthread.so.0 (0x00eb6000) > libdl.so.2 => /lib/libdl.so.2 (0x00d47000) > libc.so.6 => /lib/libc.so.6 (0x00110000) > /lib/ld-linux.so.2 (0x002c3000) This strikes me as a bug, that it would internally reference a symbol but not list it in table of libraries needed by the dynamic linker. I suggest taking this up with the collectd authors (maybe provide them with your full build log too?), and point them to this discussion. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From simon at josefsson.org Thu Jun 17 17:07:08 2010 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 17 Jun 2010 17:07:08 +0200 Subject: no static library in libgpg-error 1.8? Message-ID: <87ljadbsv7.fsf@mocca.josefsson.org> I see that static libraries were disabled by default with version 1.8, but there is no discussion about it in NEWS or anywhere else as far as I could tell. Building it with --enable-static appears to work. Aren't static libraries supported anymore? /Simon From wk at gnupg.org Thu Jun 17 19:29:16 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Jun 2010 19:29:16 +0200 Subject: network.so: undefined symbol: =?utf-8?Q?gcry=5Fmd=5Fhash=5Fbu?= =?utf-8?Q?ffer=E2=80=8F?= In-Reply-To: <4C1A4A46.4050801@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 17 Jun 2010 12:16:06 -0400") References: <28879871.post@talk.nabble.com> <4C1A2DBB.6080106@fifthhorseman.net> <4C1A3B67.2060304@fifthhorseman.net> <4C1A4A46.4050801@fifthhorseman.net> Message-ID: <874oh1va8j.fsf@vigenere.g10code.de> On Thu, 17 Jun 2010 18:16, dkg at fifthhorseman.net said: > I suggest taking this up with the collectd authors (maybe provide them > with your full build log too?), and point them to this discussion. Do they use dlopen? - Not a good idea. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jun 17 19:28:29 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Jun 2010 19:28:29 +0200 Subject: no static library in libgpg-error 1.8? In-Reply-To: <87ljadbsv7.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Thu, 17 Jun 2010 17:07:08 +0200") References: <87ljadbsv7.fsf@mocca.josefsson.org> Message-ID: <878w6dva9u.fsf@vigenere.g10code.de> On Thu, 17 Jun 2010 17:07, simon at josefsson.org said: > I see that static libraries were disabled by default with version 1.8, > but there is no discussion about it in NEWS or anywhere else as far as I > could tell. Building it with --enable-static appears to work. This happened during the update of libtool about a year ago. As you noted this is only about the default. There might be a problem under Windows with static libs (no dllmain for TLS init). Aren't static libraries supported anymore? No. We still support static libs (maybe except for Windows - see above). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Thu Jun 17 19:49:47 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 17 Jun 2010 13:49:47 -0400 Subject: network.so: undefined symbol: =?UTF-8?B?Z2NyeV9tZF9oYXNoX2J1?= =?UTF-8?B?ZmZlcuKAjw==?= In-Reply-To: References: <28879871.post@talk.nabble.com>, <4C1A2DBB.6080106@fifthhorseman.net>, , <4C1A3B67.2060304@fifthhorseman.net>, , <4C1A4A46.4050801@fifthhorseman.net>, <874oh1va8j.fsf@vigenere.g10code.de> Message-ID: <4C1A603B.8000308@fifthhorseman.net> On 06/17/2010 01:43 PM, Honia A wrote: > > In collectd manual in network plugin section for encryption, it reads: > > "This feature is only available if the network plugin was linked with libgcrypt." > > So, can you please tell me how to statically link libgcrypt into the plugin network.so? Maybe that fixes the issue... I don't think you want static linking. dynamic linking should be fine, you just need to figure out why it's not getting dynamically linked properly. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From rgetz at blackfin.uclinux.org Thu Jun 17 20:58:49 2010 From: rgetz at blackfin.uclinux.org (Robin Getz) Date: Thu, 17 Jun 2010 14:58:49 -0400 Subject: Problem building 1.4.5 In-Reply-To: References: <201006151326.23861.rgetz@blackfin.uclinux.org> <201006161813.37622.rgetz@blackfin.uclinux.org> Message-ID: <201006171458.50005.rgetz@blackfin.uclinux.org> On Wed 16 Jun 2010 18:18, Mike Frysinger pondered: > On Wed, Jun 16, 2010 at 18:13, Robin Getz wrote: > > On Wed 16 Jun 2010 05:23, Werner Koch pondered: > >> If this is the case something is wrong with the linker for the system, > >> disable this feature using > >> > >> ? ./configure --disable-ld-version-script > >> > >> and try building again. > > > > That fixes things - but can you describe what you mean when you say > > "something wrong with the linker"? > > the version script operates on linker-visible symbols, not on C > visible symbols, so the linker is operating correctly. this is why > projects like alsa-lib have the version script be a .in file and it > prefixes all symbols with like @SYMBOL_PREFIX at . then the configure > script processes that into the final version script with > @SYMBOL_PREFIX@ replaced with "_" or "" depending on the configure > detected needs of the target system. > > considering support is apparently already there via > WITH_SYMBOL_UNDERSCORE, seems like it should be pretty easy to extend > this. On Thu 17 Jun 2010 03:44, Werner Koch pondered: > Please use the disable switch until we found a clean solution. Is Mike's suggestion palatable? From wk at gnupg.org Fri Jun 18 09:37:52 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Jun 2010 09:37:52 +0200 Subject: Problem building 1.4.5 In-Reply-To: <201006171458.50005.rgetz@blackfin.uclinux.org> (Robin Getz's message of "Thu, 17 Jun 2010 14:58:49 -0400") References: <201006151326.23861.rgetz@blackfin.uclinux.org> <201006161813.37622.rgetz@blackfin.uclinux.org> <201006171458.50005.rgetz@blackfin.uclinux.org> Message-ID: <87ocf8u6y7.fsf@vigenere.g10code.de> On Thu, 17 Jun 2010 20:58, rgetz at blackfin.uclinux.org said: > Is Mike's suggestion palatable? It makes the vers file a bit ugly. I'd really prefer to have a control statement in the vers file to prefix all symbols. Or a linker switch todo this. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From honia2002 at hotmail.com Thu Jun 17 19:04:02 2010 From: honia2002 at hotmail.com (Honia A) Date: Thu, 17 Jun 2010 13:04:02 -0400 Subject: =?windows-1256?Q?RE:_networ?= =?windows-1256?Q?k.so:_unde?= =?windows-1256?Q?fined_symb?= =?windows-1256?Q?ol:_gcry=5Fm?= =?windows-1256?Q?d=5Fhash=5Fbuf?= =?windows-1256?Q?fer=FE?= In-Reply-To: <4C1A4A46.4050801@fifthhorseman.net> References: <28879871.post@talk.nabble.com>,<4C1A2DBB.6080106@fifthhorseman.net> , <4C1A3B67.2060304@fifthhorseman.net> , <4C1A4A46.4050801@fifthhorseman.net> Message-ID: Thanks again for your reply. There are some references to that symbol...Please see the attached network.c file. In the section below, the code is looking for gcrypt.h in the default directory which is /usr/include: #if HAVE_LIBGCRYPT # include GCRY_THREAD_OPTION_PTHREAD_IMPL; #endif I checked /usr/include directory and the gcrypt.h header file is not there. Instead, the file is in /usr/local/include. So I just simply copied the header files into /usr/include but collectd still fails. There are multiple references to the symbol (gcry_md_hash_buffer) in network.c. Here's another one #if HAVE_LIBGCRYPT static gcry_cipher_hd_t network_get_aes256_cypher (sockent_t *se, /* {{{ */ const void *iv, size_t iv_size, const char *username) { gcry_error_t err; gcry_cipher_hd_t *cyper_ptr; unsigned char password_hash[32]; if (se->type == SOCKENT_TYPE_CLIENT) { cyper_ptr = &se->data.client.cypher; memcpy (password_hash, se->data.client.password_hash, sizeof (password_hash)); } else { char *secret; cyper_ptr = &se->data.server.cypher; if (username == NULL) return (NULL); secret = fbh_get (se->data.server.userdb, username); if (secret == NULL) return (NULL); gcry_md_hash_buffer (GCRY_MD_SHA256, password_hash, secret, strlen (secret)); sfree (secret); } Any info will be much appreciated, I have also posted this question on the collectd mailinglist and also sent an email to Octo (the author) but haven't gotten any replies yet. Regards, h > Date: Thu, 17 Jun 2010 12:16:06 -0400 > From: dkg at fifthhorseman.net > To: honia2002 at hotmail.com > CC: gcrypt-devel at gnupg.org > Subject: Re: network.so: undefined symbol: gcry_md_hash_buffer? > > On 06/17/2010 11:23 AM, Honia A wrote: > > > > Thank you for your reply. Here's the full output: > > > > linux-gate.so.1 => (0x00691000) > > libpthread.so.0 => /lib/libpthread.so.0 (0x00eb6000) > > libdl.so.2 => /lib/libdl.so.2 (0x00d47000) > > libc.so.6 => /lib/libc.so.6 (0x00110000) > > /lib/ld-linux.so.2 (0x002c3000) > > This strikes me as a bug, that it would internally reference a symbol > but not list it in table of libraries needed by the dynamic linker. > > I suggest taking this up with the collectd authors (maybe provide them > with your full build log too?), and point them to this discussion. > > --dkg > _________________________________________________________________ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: network.c URL: From honia2002 at hotmail.com Thu Jun 17 19:43:58 2010 From: honia2002 at hotmail.com (Honia A) Date: Thu, 17 Jun 2010 13:43:58 -0400 Subject: =?windows-1256?Q?RE:_networ?= =?windows-1256?Q?k.so:_unde?= =?windows-1256?Q?fined_symb?= =?windows-1256?Q?ol:_gcry=5Fm?= =?windows-1256?Q?d=5Fhash=5Fbuf?= =?windows-1256?Q?fer=FE?= In-Reply-To: <874oh1va8j.fsf@vigenere.g10code.de> References: <28879871.post@talk.nabble.com>, <4C1A2DBB.6080106@fifthhorseman.net>, , <4C1A3B67.2060304@fifthhorseman.net>, , <4C1A4A46.4050801@fifthhorseman.net>, <874oh1va8j.fsf@vigenere.g10code.de> Message-ID: In collectd manual in network plugin section for encryption, it reads: "This feature is only available if the network plugin was linked with libgcrypt." So, can you please tell me how to statically link libgcrypt into the plugin network.so? Maybe that fixes the issue... Thanks in advance, Regards, h > From: wk at gnupg.org > To: gcrypt-devel at gnupg.org > CC: honia2002 at hotmail.com > Subject: Re: network.so: undefined symbol: gcry_md_hash_buffer? > Date: Thu, 17 Jun 2010 19:29:16 +0200 > > On Thu, 17 Jun 2010 18:16, dkg at fifthhorseman.net said: > > > I suggest taking this up with the collectd authors (maybe provide them > > with your full build log too?), and point them to this discussion. > > Do they use dlopen? - Not a good idea. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > _________________________________________________________________ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From honia2002 at hotmail.com Thu Jun 17 19:58:23 2010 From: honia2002 at hotmail.com (Honia A) Date: Thu, 17 Jun 2010 13:58:23 -0400 Subject: =?windows-1256?Q?RE:_networ?= =?windows-1256?Q?k.so:_unde?= =?windows-1256?Q?fined_symb?= =?windows-1256?Q?ol:_gcry=5Fm?= =?windows-1256?Q?d=5Fhash=5Fbuf?= =?windows-1256?Q?fer=FE?= In-Reply-To: <4C1A603B.8000308@fifthhorseman.net> References: <28879871.post@talk.nabble.com>, <4C1A2DBB.6080106@fifthhorseman.net>, , <4C1A3B67.2060304@fifthhorseman.net>, , <4C1A4A46.4050801@fifthhorseman.net>, <874oh1va8j.fsf@vigenere.g10code.de> , <4C1A603B.8000308@fifthhorseman.net> Message-ID: Sure, I will try the dynamically linking. Can you please help me with that? I've never done this before... >why it's not getting dynamically linked properly Can it be because collectd cannot find the installed libgcrypt package? I give collectd build the path to /usr/local directory. Maybe that's the wrong directory... Can you also please let me know what's teh default installation directory for libgcrypt? Thanks in advance > Date: Thu, 17 Jun 2010 13:49:47 -0400 > From: dkg at fifthhorseman.net > To: honia2002 at hotmail.com > CC: gcrypt-devel at gnupg.org; wk at gnupg.org > Subject: Re: network.so: undefined symbol: gcry_md_hash_buffer? > > On 06/17/2010 01:43 PM, Honia A wrote: > > > > In collectd manual in network plugin section for encryption, it reads: > > > > "This feature is only available if the network plugin was linked with libgcrypt." > > > > So, can you please tell me how to statically link libgcrypt into the plugin network.so? Maybe that fixes the issue... > > I don't think you want static linking. dynamic linking should be fine, > you just need to figure out why it's not getting dynamically linked > properly. > > --dkg > _________________________________________________________________ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Fri Jun 18 11:07:57 2010 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 18 Jun 2010 11:07:57 +0200 Subject: no static library in libgpg-error 1.8? In-Reply-To: <878w6dva9u.fsf@vigenere.g10code.de> (Werner Koch's message of "Thu, 17 Jun 2010 19:28:29 +0200") References: <87ljadbsv7.fsf@mocca.josefsson.org> <878w6dva9u.fsf@vigenere.g10code.de> Message-ID: <87zkys909e.fsf@mocca.josefsson.org> Werner Koch writes: > On Thu, 17 Jun 2010 17:07, simon at josefsson.org said: > >> I see that static libraries were disabled by default with version 1.8, >> but there is no discussion about it in NEWS or anywhere else as far as I >> could tell. Building it with --enable-static appears to work. > > This happened during the update of libtool about a year ago. As you > noted this is only about the default. There might be a problem under > Windows with static libs (no dllmain for TLS init). > > Aren't static libraries supported anymore? > > No. We still support static libs (maybe except for Windows - see > above). Is the dllmain code required for proper functionality? Some people build static Windows executables of GnuTLS and libssh2 libraries, so the Windows platform was actually the reason I asked (it stopped working when I upgraded libgpg-error 1.8 and forgot to add --enable-static). /Simon From vapier.adi at gmail.com Fri Jun 18 15:56:02 2010 From: vapier.adi at gmail.com (Mike Frysinger) Date: Fri, 18 Jun 2010 09:56:02 -0400 Subject: Problem building 1.4.5 In-Reply-To: <87ocf8u6y7.fsf@vigenere.g10code.de> References: <201006151326.23861.rgetz@blackfin.uclinux.org> <201006161813.37622.rgetz@blackfin.uclinux.org> <201006171458.50005.rgetz@blackfin.uclinux.org> <87ocf8u6y7.fsf@vigenere.g10code.de> Message-ID: On Fri, Jun 18, 2010 at 03:37, Werner Koch wrote: > On Thu, 17 Jun 2010 20:58, rgetz at blackfin.uclinux.org said: >> Is Mike's suggestion palatable? > > It makes the vers file a bit ugly. ?I'd really prefer to have a control > statement in the vers file to prefix all symbols. ?Or a linker switch > todo this. neither exist today and likely wont for a long time (if someone were to implement it today), and wouldnt be backwards compatible another option that isnt as clean is to add a Makefile target to run `sed` on the .in file itself rather than configure. then the contents wouldnt change between the current version script and the renamed .in version. -mike From wk at gnupg.org Fri Jun 18 18:24:40 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Jun 2010 18:24:40 +0200 Subject: no static library in libgpg-error 1.8? In-Reply-To: <87zkys909e.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 18 Jun 2010 11:07:57 +0200") References: <87ljadbsv7.fsf@mocca.josefsson.org> <878w6dva9u.fsf@vigenere.g10code.de> <87zkys909e.fsf@mocca.josefsson.org> Message-ID: <87iq5gtik7.fsf@vigenere.g10code.de> On Fri, 18 Jun 2010 11:07, simon at josefsson.org said: > Is the dllmain code required for proper functionality? Some people We use the dllmain code to setup TLS. There is fallback code in case dllmain was not used but that is obviously not race free. TLS is used for the gettext implementation now included in the windows version. > build static Windows executables of GnuTLS and libssh2 libraries, so the > Windows platform was actually the reason I asked (it stopped working > when I upgraded libgpg-error 1.8 and forgot to add --enable-static). I guess this is okay. You might encounter build probklems - I have not checked. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jun 18 18:28:55 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Jun 2010 18:28:55 +0200 Subject: Problem building 1.4.5 In-Reply-To: (Mike Frysinger's message of "Fri, 18 Jun 2010 09:56:02 -0400") References: <201006151326.23861.rgetz@blackfin.uclinux.org> <201006161813.37622.rgetz@blackfin.uclinux.org> <201006171458.50005.rgetz@blackfin.uclinux.org> <87ocf8u6y7.fsf@vigenere.g10code.de> Message-ID: <87eig4tid4.fsf@vigenere.g10code.de> On Fri, 18 Jun 2010 15:56, vapier.adi at gmail.com said: > neither exist today and likely wont for a long time (if someone were > to implement it today), and wouldnt be backwards compatible Well the symbol hiding is not really required and as long as we don't need to change the ABI there is no real need for it. > another option that isnt as clean is to add a Makefile target to run > `sed` on the .in file itself rather than configure. then the contents > wouldnt change between the current version script and the renamed .in > version. Yeah. I was also thinking of this. If we do it for one library we need to do it for all of the GnuPG related libs and thus I see no immediate need for it. Let me discuss this with the libtool or binutils folks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rgetz at blackfin.uclinux.org Fri Jun 18 23:07:51 2010 From: rgetz at blackfin.uclinux.org (Robin Getz) Date: Fri, 18 Jun 2010 17:07:51 -0400 Subject: Problem building 1.4.5 In-Reply-To: <87eig4tid4.fsf@vigenere.g10code.de> References: <201006151326.23861.rgetz@blackfin.uclinux.org> <87eig4tid4.fsf@vigenere.g10code.de> Message-ID: <201006181707.51361.rgetz@blackfin.uclinux.org> On Fri 18 Jun 2010 12:28, Werner Koch pondered: > On Fri, 18 Jun 2010 15:56, vapier.adi at gmail.com said: > > > neither exist today and likely wont for a long time (if someone were > > to implement it today), and wouldnt be backwards compatible > > Well the symbol hiding is not really required and as long as we don't > need to change the ABI there is no real need for it. > > > another option that isnt as clean is to add a Makefile target to run > > `sed` on the .in file itself rather than configure. then the contents > > wouldnt change between the current version script and the renamed .in > > version. > > Yeah. I was also thinking of this. If we do it for one library we need > to do it for all of the GnuPG related libs and thus I see no immediate > need for it. I'm not sure about all... libgpg-error builds without issue... I know that gnutls has a similar issue, but even --disable-ld-version-script doesn't help... still digging into that... > Let me discuss this with the libtool or binutils folks. I'm thinking along the same lines as Mike, when he pondered: > neither exist today and likely wont for a long time (if someone were > to implement it today), and wouldnt be backwards compatible -Robin From simon at josefsson.org Sat Jun 19 09:16:47 2010 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 19 Jun 2010 09:16:47 +0200 Subject: no static library in libgpg-error 1.8? In-Reply-To: <87iq5gtik7.fsf@vigenere.g10code.de> (Werner Koch's message of "Fri, 18 Jun 2010 18:24:40 +0200") References: <87ljadbsv7.fsf@mocca.josefsson.org> <878w6dva9u.fsf@vigenere.g10code.de> <87zkys909e.fsf@mocca.josefsson.org> <87iq5gtik7.fsf@vigenere.g10code.de> Message-ID: <87hbkz331c.fsf@mocca.josefsson.org> Werner Koch writes: > On Fri, 18 Jun 2010 11:07, simon at josefsson.org said: > >> Is the dllmain code required for proper functionality? Some people > > We use the dllmain code to setup TLS. There is fallback code in case > dllmain was not used but that is obviously not race free. TLS is used > for the gettext implementation now included in the windows version. Isn't non-race-free initialization supposed to be done in gpg_err_init? >> build static Windows executables of GnuTLS and libssh2 libraries, so the >> Windows platform was actually the reason I asked (it stopped working >> when I upgraded libgpg-error 1.8 and forgot to add --enable-static). > > I guess this is okay. You might encounter build probklems - I have not > checked. It builds fine and passes all self checks in both libgpg-error itself, libgcrypt, and GnuTLS+libssh2. /Simon From honia2002 at hotmail.com Fri Jun 18 15:56:20 2010 From: honia2002 at hotmail.com (Honia A) Date: Fri, 18 Jun 2010 09:56:20 -0400 Subject: =?windows-1256?Q?RE:_networ?= =?windows-1256?Q?k.so:_unde?= =?windows-1256?Q?fined_symb?= =?windows-1256?Q?ol:_gcry=5Fm?= =?windows-1256?Q?d=5Fhash=5Fbuf?= =?windows-1256?Q?fer=FE?= In-Reply-To: <4C1A603B.8000308@fifthhorseman.net> References: <28879871.post@talk.nabble.com>, <4C1A2DBB.6080106@fifthhorseman.net>, , <4C1A3B67.2060304@fifthhorseman.net>, , <4C1A4A46.4050801@fifthhorseman.net>, <874oh1va8j.fsf@vigenere.g10code.de> , <4C1A603B.8000308@fifthhorseman.net> Message-ID: Good morning, I just came across a brief manual for libgcrypt: http://www.linuxfromscratch.org/blfs/view/svn/general/libgcrypt.html It says the installation directory will be /usr/share/doc/libgcrypt-1.4.5 but i can't see anything but a README file in there... Also, checked the collectd build output and looks like it was aboe to find libgcrypt and therefore I am going to try one more thing before I completely give up on this... So can someone please let me know how I can dynamically link collectd's network.so with libgcrypt? Thanks in advance, h > Date: Thu, 17 Jun 2010 13:49:47 -0400 > From: dkg at fifthhorseman.net > To: honia2002 at hotmail.com > CC: gcrypt-devel at gnupg.org; wk at gnupg.org > Subject: Re: network.so: undefined symbol: gcry_md_hash_buffer? > > On 06/17/2010 01:43 PM, Honia A wrote: > > > > In collectd manual in network plugin section for encryption, it reads: > > > > "This feature is only available if the network plugin was linked with libgcrypt." > > > > So, can you please tell me how to statically link libgcrypt into the plugin network.so? Maybe that fixes the issue... > > I don't think you want static linking. dynamic linking should be fine, > you just need to figure out why it's not getting dynamically linked > properly. > > --dkg > _________________________________________________________________ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vapier.adi at gmail.com Sat Jun 19 19:14:19 2010 From: vapier.adi at gmail.com (Mike Frysinger) Date: Sat, 19 Jun 2010 13:14:19 -0400 Subject: Problem building 1.4.5 In-Reply-To: <87eig4tid4.fsf@vigenere.g10code.de> References: <201006151326.23861.rgetz@blackfin.uclinux.org> <201006161813.37622.rgetz@blackfin.uclinux.org> <201006171458.50005.rgetz@blackfin.uclinux.org> <87ocf8u6y7.fsf@vigenere.g10code.de> <87eig4tid4.fsf@vigenere.g10code.de> Message-ID: On Fri, Jun 18, 2010 at 12:28, Werner Koch wrote: > On Fri, 18 Jun 2010 15:56, vapier.adi at gmail.com said: >> neither exist today and likely wont for a long time (if someone were >> to implement it today), and wouldnt be backwards compatible > > Well the symbol hiding is not really required and as long as we don't > need to change the ABI there is no real need for it. even if you change the ABI, symbol hiding isnt really necessary. the only functions you've guaranteed to be in the ABI are the ones you've listed. if other internal ones leak out and someone uses them and they're later removed, that's not your concern. a correctly maintained ABI means exported symbols are only ever added, not removed. >> another option that isnt as clean is to add a Makefile target to run >> `sed` on the .in file itself rather than configure. ?then the contents >> wouldnt change between the current version script and the renamed .in >> version. > > Yeah. I was also thinking of this. ?If we do it for one library we need > to do it for all of the GnuPG related libs and thus I see no immediate > need for it. ?Let me discuss this with the libtool or binutils folks. as soon as you use a version script to give to binutils, libtool takes no part in the symbol munging. had you used -export-symbols or -export-symbols-regex, then we wouldnt really be bothering you guys about these issues. we'd be looking at libtool to hide the details (and atm, it does a pretty good job of handling symbol prefixes). -mike From wk at gnupg.org Mon Jun 21 15:28:49 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Jun 2010 15:28:49 +0200 Subject: Problem building 1.4.5 In-Reply-To: (Mike Frysinger's message of "Sat, 19 Jun 2010 13:14:19 -0400") References: <201006151326.23861.rgetz@blackfin.uclinux.org> <201006161813.37622.rgetz@blackfin.uclinux.org> <201006171458.50005.rgetz@blackfin.uclinux.org> <87ocf8u6y7.fsf@vigenere.g10code.de> <87eig4tid4.fsf@vigenere.g10code.de> Message-ID: <87sk4gseem.fsf@vigenere.g10code.de> On Sat, 19 Jun 2010 19:14, vapier.adi at gmail.com said: > even if you change the ABI, symbol hiding isnt really necessary. the > only functions you've guaranteed to be in the ABI are the ones you've The version script allows to implement several ABIs. Thus we can modify an API or remobing it without tocuhing the ABI. Checkout glibc to see how this can be useful. > as soon as you use a version script to give to binutils, libtool takes > no part in the symbol munging. had you used -export-symbols or Well it could munge the version script for us or pass an appropriate option to ld ;-). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jun 21 15:31:11 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Jun 2010 15:31:11 +0200 Subject: no static library in libgpg-error 1.8? In-Reply-To: <87hbkz331c.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Sat, 19 Jun 2010 09:16:47 +0200") References: <87ljadbsv7.fsf@mocca.josefsson.org> <878w6dva9u.fsf@vigenere.g10code.de> <87zkys909e.fsf@mocca.josefsson.org> <87iq5gtik7.fsf@vigenere.g10code.de> <87hbkz331c.fsf@mocca.josefsson.org> Message-ID: <87ocf4seao.fsf@vigenere.g10code.de> On Sat, 19 Jun 2010 09:16, simon at josefsson.org said: > Isn't non-race-free initialization supposed to be done in gpg_err_init? Right, however we try to span an extra safety net ;-). > It builds fine and passes all self checks in both libgpg-error itself, > libgcrypt, and GnuTLS+libssh2. Thus we can close this issue, right? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From vapier.adi at gmail.com Mon Jun 21 18:24:17 2010 From: vapier.adi at gmail.com (Mike Frysinger) Date: Mon, 21 Jun 2010 12:24:17 -0400 Subject: Problem building 1.4.5 In-Reply-To: <87sk4gseem.fsf@vigenere.g10code.de> References: <201006151326.23861.rgetz@blackfin.uclinux.org> <201006161813.37622.rgetz@blackfin.uclinux.org> <201006171458.50005.rgetz@blackfin.uclinux.org> <87ocf8u6y7.fsf@vigenere.g10code.de> <87eig4tid4.fsf@vigenere.g10code.de> <87sk4gseem.fsf@vigenere.g10code.de> Message-ID: On Mon, Jun 21, 2010 at 09:28, Werner Koch wrote: > On Sat, 19 Jun 2010 19:14, vapier.adi at gmail.com said: >> even if you change the ABI, symbol hiding isnt really necessary. ?the >> only functions you've guaranteed to be in the ABI are the ones you've > > The version script allows to implement several ABIs. ?Thus we can modify > an API or remobing it without tocuhing the ABI. ?Checkout glibc to see > how this can be useful. i dont classify versioning symbols quite that way, but it's just semantics i guess >> as soon as you use a version script to give to binutils, libtool takes >> no part in the symbol munging. ?had you used -export-symbols or > > Well it could munge the version script for us or pass an appropriate > option to ld ;-). this is treading pretty ugly territory though. you want libtool to parse a pretty free form file like the version script given to ld and mung it ? if the file had strict rules about syntax, then /maybe/ ... at any rate, if we sent a patch that turned src/libgcrypt.vers into a src/libgcrypt.vers.in and then ran `sed` on it, would you guys take it ? -mike From wk at gnupg.org Tue Jun 22 11:07:42 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Jun 2010 11:07:42 +0200 Subject: Problem building 1.4.5 In-Reply-To: (Mike Frysinger's message of "Mon, 21 Jun 2010 12:24:17 -0400") References: <201006151326.23861.rgetz@blackfin.uclinux.org> <201006161813.37622.rgetz@blackfin.uclinux.org> <201006171458.50005.rgetz@blackfin.uclinux.org> <87ocf8u6y7.fsf@vigenere.g10code.de> <87eig4tid4.fsf@vigenere.g10code.de> <87sk4gseem.fsf@vigenere.g10code.de> Message-ID: <87vd9bqvtt.fsf@vigenere.g10code.de> On Mon, 21 Jun 2010 18:24, vapier.adi at gmail.com said: > at any rate, if we sent a patch that turned src/libgcrypt.vers into a > src/libgcrypt.vers.in and then ran `sed` on it, would you guys take it As I said, this uglifies the version file and the version file is part of the ABI: It defines which symbols belong to which ABI. Thus it is really important. Of course that reises a related problem: As soon as we need do change the API we won't can't support Blackfin anymore. This is actually the same as with platforms where we don't have a GNU (or Solaris) linker - we would need to break the ABI on those platform. Given that we are using the GNU toolchain, it is very unfortunate that we can't support Blackfin in the same way as other GNU platforms. I guess that this problem has not been raised earlier is due to the there-is-only-intel-and-linux-in-the-world believe of one well-known glibc hacker. Given that this is not gcrypt specific, I'll start a new thread to discuss this problems with a couple of other guys. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jun 22 11:42:43 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Jun 2010 11:42:43 +0200 Subject: Blackfin and version scripts Message-ID: <87pqzjqu7g.fsf@vigenere.g10code.de> Hi! Mike and Robin found a build problem with libgcrypt on Blackfin using the GNU toolchain: Libgcrypt as most other GnuPG related libraries tries to keep a well defined ABI and thus use a version script to guarantee that. The version script is passed to libtool this way: if HAVE_LD_VERSION_SCRIPT libgcrypt_version_script_cmd = -Wl,--version-script=$(srcdir)/libgcrypt.vers else libgcrypt_version_script_cmd = endif [...] libgcrypt_la_LDFLAGS = $(no_undefined) $(export_symbols) \ $(libgcrypt_version_script_cmd) -version-info \ @LIBGCRYPT_LT_CURRENT@:@LIBGCRYPT_LT_REVISION@:@LIBGCRYPT_LT_AGE@ $(no_undefined) $(export_symbols) are only used for W32 and not defined if we have version script support. Now, versions scripts are using the symbols verbatim as in the C code: GCRYPT_1.2 { global: gcry_check_version; gcry_control; [...] Blackfin seems to be the only platform which has version script support and prefixes symbols with underscores. That does not work of course. Ways to fix this are: (1) Use autoconf to create a foo.vers from foo.vers.in while prefixing all symbols like GCRYPT_1.2 { global: @SYMBOL_PREFIX at gcry_check_version; @SYMBOL_PREFIX at gcry_control; [...] I think this looks too ugly and has also the drawback that we need to get libtool's idea of the symbol prefix into autoconf. For libgcrypt thsi is easy becuase due to the assembler modules we need to know it anyway; but other libs don't need to know this. (2) Another solution would be to sed the file on the fly in the Makefile. This is better but requires that we need to maintain this code in all projects. (3) Introduce an new option in LD which tells it to use the native symbol prefix of the platform for all symbols in the versions script. This may take some time until it is implemneted and widely availabale. (4) Let libtool do something. This may be an option to detect -Wl,--version-script=foo on the command line and hook in a sed to transform the symbols. It is pretty common that symols are all prefixed with something like "foo_" or "_foo_" and thus the option could take a list of these prefixes and - if a symbol prefix is required - transform the version script. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From simon at josefsson.org Tue Jun 22 11:53:52 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 22 Jun 2010 11:53:52 +0200 Subject: no static library in libgpg-error 1.8? In-Reply-To: <87ocf4seao.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 21 Jun 2010 15:31:11 +0200") References: <87ljadbsv7.fsf@mocca.josefsson.org> <878w6dva9u.fsf@vigenere.g10code.de> <87zkys909e.fsf@mocca.josefsson.org> <87iq5gtik7.fsf@vigenere.g10code.de> <87hbkz331c.fsf@mocca.josefsson.org> <87ocf4seao.fsf@vigenere.g10code.de> Message-ID: <87y6e7pf4f.fsf@mocca.josefsson.org> Werner Koch writes: > On Sat, 19 Jun 2010 09:16, simon at josefsson.org said: > >> Isn't non-race-free initialization supposed to be done in gpg_err_init? > > Right, however we try to span an extra safety net ;-). > >> It builds fine and passes all self checks in both libgpg-error itself, >> libgcrypt, and GnuTLS+libssh2. > > Thus we can close this issue, right? Yes, assuming static libgpg-error is supported on Windows. Thanks, /Simon From vapier.adi at gmail.com Tue Jun 22 22:14:03 2010 From: vapier.adi at gmail.com (Mike Frysinger) Date: Tue, 22 Jun 2010 16:14:03 -0400 Subject: Problem building 1.4.5 In-Reply-To: <87vd9bqvtt.fsf@vigenere.g10code.de> References: <201006151326.23861.rgetz@blackfin.uclinux.org> <201006161813.37622.rgetz@blackfin.uclinux.org> <201006171458.50005.rgetz@blackfin.uclinux.org> <87ocf8u6y7.fsf@vigenere.g10code.de> <87eig4tid4.fsf@vigenere.g10code.de> <87sk4gseem.fsf@vigenere.g10code.de> <87vd9bqvtt.fsf@vigenere.g10code.de> Message-ID: On Tue, Jun 22, 2010 at 05:07, Werner Koch wrote: > On Mon, 21 Jun 2010 18:24, vapier.adi at gmail.com said: >> at any rate, if we sent a patch that turned src/libgcrypt.vers into a >> src/libgcrypt.vers.in and then ran `sed` on it, would you guys take it > > As I said, this uglifies the version file and the version file is part > of the ABI: It defines which symbols belong to which ABI. ?Thus it is > really important. running a manual sed on it wouldnt uglify it. the contents wouldnt change at all. as long as the current style is adhered to, it's quite trivial. in the Makefile.am: libgcrypt.vers: libgcrypt.vers.in sed -r 's:\<(gcry_):@SYMBOL_PREFIX@&:g' $< > $@ > Of course that reises a related problem: As soon as we need do change > the API we won't can't support Blackfin anymore. ?This is actually the > same as with platforms where we don't have a GNU (or Solaris) linker - > we would need to break the ABI on those platform. > > Given that we are using the GNU toolchain, it is very unfortunate that > we can't support Blackfin in the same way as other GNU platforms. ?I > guess that this problem has not been raised earlier is due to the > there-is-only-intel-and-linux-in-the-world believe of one well-known > glibc hacker. well, some clarifications here: - Solaris does support symbol versioning and if my history is correct, it had it before the GNU toolchain - Blackfin only supports uClibc because glibc isnt interested in supporting nommu systems, and uClibc does not support symbol versioning -mike From wk at gnupg.org Wed Jun 23 09:46:01 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 23 Jun 2010 09:46:01 +0200 Subject: Blackfin and version scripts In-Reply-To: <87tyoul3k5.fsf@windlord.stanford.edu> (Russ Allbery's message of "Tue, 22 Jun 2010 22:29:30 -0700") References: <87pqzjqu7g.fsf@vigenere.g10code.de> <87r5jyn5pn.fsf@windlord.stanford.edu> <20100623050829.GE9487@gmx.de> <87tyoul3k5.fsf@windlord.stanford.edu> Message-ID: <874oguqjie.fsf@vigenere.g10code.de> On Wed, 23 Jun 2010 07:29, rra at stanford.edu said: > I can take a pass at starting. All that I need for my packages is to > support the basic version syntax: > > { > global: > ; That would be sufficient for me too as long as a with only global symbols is supported as well. Having a second file with a simple list of symbols instead of a version script parser is another option. Actually this is required because to support W32 we need a .def file EXPORTS gcry_check_version @1 gcry_control @2 which allows to assign id numbers to symbols. In theory we could add this via comment lines to a versions script but that would make a parser even more complicated. In some projects I create the .def file from a .def.in file to handle differences between W32 and W32CE. In any case the .def file is easy to parse and could be used as input to --export-symbols. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rra at stanford.edu Tue Jun 22 23:00:04 2010 From: rra at stanford.edu (Russ Allbery) Date: Tue, 22 Jun 2010 14:00:04 -0700 Subject: Blackfin and version scripts In-Reply-To: <87pqzjqu7g.fsf@vigenere.g10code.de> (Werner Koch's message of "Tue, 22 Jun 2010 11:42:43 +0200") References: <87pqzjqu7g.fsf@vigenere.g10code.de> Message-ID: <87r5jyn5pn.fsf@windlord.stanford.edu> Werner Koch writes: > (4) Let libtool do something. This may be an option to detect > -Wl,--version-script=foo on the command line and hook in a sed to > transform the symbols. It is pretty common that symols are all prefixed > with something like "foo_" or "_foo_" and thus the option could take a > list of these prefixes and - if a symbol prefix is required - transform > the version script. I would dearly, dearly love for libtool to pick up a --version-script option that would pass in the full version script on platforms with linkers that understand it, turn it into a symbol export list on platforms that only support that, and suppress it entirely if the linker doesn't have any relevant capabilities. That would save me a ton of maintenance burden on some of my packages, and it would then be easy to add a feature like the above as well. -- Russ Allbery (rra at stanford.edu) From rra at stanford.edu Wed Jun 23 07:29:30 2010 From: rra at stanford.edu (Russ Allbery) Date: Tue, 22 Jun 2010 22:29:30 -0700 Subject: Blackfin and version scripts In-Reply-To: <20100623050829.GE9487@gmx.de> (Ralf Wildenhues's message of "Wed, 23 Jun 2010 07:08:31 +0200") References: <87pqzjqu7g.fsf@vigenere.g10code.de> <87r5jyn5pn.fsf@windlord.stanford.edu> <20100623050829.GE9487@gmx.de> Message-ID: <87tyoul3k5.fsf@windlord.stanford.edu> Ralf Wildenhues writes: > * Russ Allbery wrote on Tue, Jun 22, 2010 at 11:00:04PM CEST: >> I would dearly, dearly love for libtool to pick up a --version-script >> option that would pass in the full version script on platforms with >> linkers that understand it, turn it into a symbol export list on >> platforms that only support that, > is this doable programmatically? Without a full version script parser? You would need a parser, but I don't think the parser needs to be particularly complicated. >> and suppress it entirely if the linker doesn't have any relevant >> capabilities. That would save me a ton of maintenance burden on some >> of my packages, and it would then be easy to add a feature like the >> above as well. > Can somebody try to come up with a more detailed set of semantics, so we > can judge a bit better whether this is feasible? If it is, any > volunteers on implementing this? I can take a pass at starting. All that I need for my packages is to support the basic version syntax: { global: ; ; local: *; }; On platforms with linkers that support regular ELF versioning, libtool would need to figure out the right flag to pass to the linker and then add it to the link line. On platforms that don't support that sort of version script, libtool should extract the symbols listed in the global section and then treat this flag as equivalent to -export-symbols pointing to a file containing just the list of symbols in the global section. Obviously, there are a bunch of other things you can do with symbol versioning and this wouldn't be a replacement for what, say, glibc does. But I bet it would be a good 80% solution. > Do you know the gnulib module lib-symbol-versions? (No, it's not a > complete solution.) I hadn't looked at it before. It looks like all that does is check whether --version-script is supported by the linker. I suspect that will only cover GNU ld and Solaris ld on ELF. The fallback to -export-symbols is the main feature that I'd really like to see, since that's supported on more platforms and satisfies another major reason why people use version scripts. I suppose one could use lib-symbol-versions in conjunction with a separately-maintained or generated export symbols map and apply both of them. I haven't tried that to see if there are any bad interactions between -export-symbols and versioned symbols. -- Russ Allbery (rra at stanford.edu) From Ralf.Wildenhues at gmx.de Wed Jun 23 07:08:31 2010 From: Ralf.Wildenhues at gmx.de (Ralf Wildenhues) Date: Wed, 23 Jun 2010 07:08:31 +0200 Subject: Blackfin and version scripts In-Reply-To: <87r5jyn5pn.fsf@windlord.stanford.edu> References: <87pqzjqu7g.fsf@vigenere.g10code.de> <87r5jyn5pn.fsf@windlord.stanford.edu> Message-ID: <20100623050829.GE9487@gmx.de> Hello Russ, all, * Russ Allbery wrote on Tue, Jun 22, 2010 at 11:00:04PM CEST: > I would dearly, dearly love for libtool to pick up a --version-script > option that would pass in the full version script on platforms with > linkers that understand it, turn it into a symbol export list on platforms > that only support that, is this doable programmatically? Without a full version script parser? > and suppress it entirely if the linker doesn't > have any relevant capabilities. That would save me a ton of maintenance > burden on some of my packages, and it would then be easy to add a feature > like the above as well. Can somebody try to come up with a more detailed set of semantics, so we can judge a bit better whether this is feasible? If it is, any volunteers on implementing this? Do you know the gnulib module lib-symbol-versions? (No, it's not a complete solution.) Thanks, Ralf From rra at stanford.edu Wed Jun 23 08:18:25 2010 From: rra at stanford.edu (Russ Allbery) Date: Tue, 22 Jun 2010 23:18:25 -0700 Subject: Blackfin and version scripts In-Reply-To: <201006230136.36272.vapier@gentoo.org> (Mike Frysinger's message of "Wed, 23 Jun 2010 01:36:34 -0400") References: <87pqzjqu7g.fsf@vigenere.g10code.de> <87r5jyn5pn.fsf@windlord.stanford.edu> <20100623050829.GE9487@gmx.de> <201006230136.36272.vapier@gentoo.org> Message-ID: <87mxuml1am.fsf@windlord.stanford.edu> Mike Frysinger writes: > alternative might be to do something like -export-symbols where libtool > has its own method for managing lists of symbols, but extend it to > handle versioning information as available with GNU/Solaris linkers. > then that would take care of outputting the version script with the > symbol prefix which libtool already knows. That might be a cleaner way of implementing the 80% solution. For most packages, I suspect that all you need to do is add the default symbol version string to the existing -export-symbols list as input parameters and then have libtool generate a symbol versioning file giving all symbols that version and listing everything in -export-symbols as global, with a local: *; section. There are nice things that you can do with a more sophisticated approach to versioning the symbols, but most use of symbol versioning is to avoid conflicts when multiple versions of a shared library are loaded at the same time, not to do more sophisticated things like provide multiple versions of a function bound to different symbol versions. -- Russ Allbery (rra at stanford.edu) From vapier at gentoo.org Wed Jun 23 07:36:34 2010 From: vapier at gentoo.org (Mike Frysinger) Date: Wed, 23 Jun 2010 01:36:34 -0400 Subject: Blackfin and version scripts In-Reply-To: <20100623050829.GE9487@gmx.de> References: <87pqzjqu7g.fsf@vigenere.g10code.de> <87r5jyn5pn.fsf@windlord.stanford.edu> <20100623050829.GE9487@gmx.de> Message-ID: <201006230136.36272.vapier@gentoo.org> On Wednesday, June 23, 2010 01:08:31 Ralf Wildenhues wrote: > * Russ Allbery wrote on Tue, Jun 22, 2010 at 11:00:04PM CEST: > > I would dearly, dearly love for libtool to pick up a --version-script > > option that would pass in the full version script on platforms with > > linkers that understand it, turn it into a symbol export list on > > platforms that only support that, > > is this doable programmatically? Without a full version script parser? i guess it depends on how much you want to support. the full syntax is here: http://sourceware.org/binutils/docs/ld/VERSION.html the non-C language support makes me think it'd require a lot of work to be 100% complete, but ive personally never seen people use that in version scripts before (and ive quite a bit in the open source world). so if we kept the scope to C-only symbols ... the linker is pretty unforgiving of improperly formatted files (which works for us). since we only need to mung the symbol nodes, and those: - cannot have spaces - must be terminated by a semicolon - appear between the braces seems like it wouldnt be too bad ? alternative might be to do something like -export-symbols where libtool has its own method for managing lists of symbols, but extend it to handle versioning information as available with GNU/Solaris linkers. then that would take care of outputting the version script with the symbol prefix which libtool already knows. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From honia2002 at hotmail.com Wed Jun 23 15:48:58 2010 From: honia2002 at hotmail.com (honi@) Date: Wed, 23 Jun 2010 06:48:58 -0700 (PDT) Subject: =?UTF-8?Q?Re:_network.so:_undefined_s?= =?UTF-8?Q?ymbol:_gcry=5Fmd=5Fhash=5Fbuffer=E2=80=8F?= In-Reply-To: <28879871.post@talk.nabble.com> References: <28879871.post@talk.nabble.com> Message-ID: <28972079.post@talk.nabble.com> I contacted collectd folks but didn't get any replies. Can you please let me know: 1) Where is the default installation directory for libgcrypt? 2) How to dynamically link it? Thanks in advance -- View this message in context: http://old.nabble.com/network.so%3A-undefined-symbol%3A-gcry_md_hash_buffer%E2%80%8F-tp28879871p28972079.html Sent from the GnuPG - Libgcrypt - Dev mailing list archive at Nabble.com. From Ralf.Wildenhues at gmx.de Sat Jun 26 21:32:41 2010 From: Ralf.Wildenhues at gmx.de (Ralf Wildenhues) Date: Sat, 26 Jun 2010 21:32:41 +0200 Subject: Blackfin and version scripts In-Reply-To: <87pqzjqu7g.fsf@vigenere.g10code.de> References: <87pqzjqu7g.fsf@vigenere.g10code.de> Message-ID: <20100626193239.GB11765@gmx.de> Hello Werner, all, * Werner Koch wrote on Tue, Jun 22, 2010 at 11:42:43AM CEST: > Mike and Robin found a build problem with libgcrypt on Blackfin using > the GNU toolchain: Libgcrypt as most other GnuPG related libraries tries > to keep a well defined ABI and thus use a version script to guarantee > that. The version script is passed to libtool this way: > > if HAVE_LD_VERSION_SCRIPT > libgcrypt_version_script_cmd = -Wl,--version-script=$(srcdir)/libgcrypt.vers > else > libgcrypt_version_script_cmd = > endif > [...] > libgcrypt_la_LDFLAGS = $(no_undefined) $(export_symbols) \ > $(libgcrypt_version_script_cmd) -version-info \ > @LIBGCRYPT_LT_CURRENT@:@LIBGCRYPT_LT_REVISION@:@LIBGCRYPT_LT_AGE@ > > $(no_undefined) $(export_symbols) are only used for W32 and not defined > if we have version script support. Why is -no-undefined not used unconditionally? For C-only code, this shouldn't be a problem (and if it is, we'd like to hear about it). Cheers, Ralf From Ralf.Wildenhues at gmx.de Sat Jun 26 21:36:08 2010 From: Ralf.Wildenhues at gmx.de (Ralf Wildenhues) Date: Sat, 26 Jun 2010 21:36:08 +0200 Subject: Blackfin and version scripts In-Reply-To: <87pqzjqu7g.fsf@vigenere.g10code.de> References: <87pqzjqu7g.fsf@vigenere.g10code.de> Message-ID: <20100626193605.GA11797@gmx.de> * Werner Koch wrote on Wed, Jun 23, 2010 at 09:46:01AM CEST: > On Wed, 23 Jun 2010 07:29, rra at stanford.edu said: > > > I can take a pass at starting. All that I need for my packages is to > > support the basic version syntax: > > > > { > > global: > > ; > > That would be sufficient for me too as long as a with only > global symbols is supported as well. > > Having a second file with a simple list of symbols instead of a version > script parser is another option. Actually this is required because to > support W32 we need a .def file > > EXPORTS > gcry_check_version @1 > gcry_control @2 > > which allows to assign id numbers to symbols. In theory we could add > this via comment lines to a versions script but that would make a parser > even more complicated. In some projects I create the .def file from a > .def.in file to handle differences between W32 and W32CE. In any case > the .def file is easy to parse and could be used as input to > --export-symbols. OK, so the problem space as I see it: - complex GNU/Solaris ld version scripts, but most users need only a fairly simple part of that, - w32 .def files, - symbols lists or regexes as used by libtool, - the wild card specification to use: ld uses globbing, -export-symbols-regex uses ERE. - mangling relevant also for C: prepending underscore or not, appending calling convention suffixes @... on w32, - mangling for non-C languages: C++, Java, - libtool should be able to add or remove a few symbols to the list, - for w32, we may need to tag DATA exports, "Parsing" is hard in the shell. It's probably easiest to define a libtool-specific language ("file format") that is easily amenable to sed or old awk, from which we can generate a ld version script, a def file, or a list of mangled symbols. That language could still allow the user to specify arbitrarily complex version script constructions, as long as they are given in a way our parser can easily ignore. That's the hard part. A complicating factor in the current libtool handling for exports is line length limitations: we might need to cope with partial links or reloadable objects, or, preferably, employ one of the workarounds like response files or linker scripts. This part in ltmain I know how to deal with, so if you need help there speak up. Cheers, Ralf