Re: C++ libtool build error?
Bruno Haible writes: >> Recently gnulib added some self-tests written in C++ for otherwise >> C-only modules. When imported into libidn (otherwise a strictly C >> library), this leads to an error message: >> >> /bin/bash ../libtool --preserve-dup-deps --mode=link g++ -o >> test-fcntl-h-c++ test-fcntl-h-c++.o libtests.a ../gl/libgnu.la libtests.a >> libtool: link: unable to infer tagged configuration >> libtool: link: specify a tag with `--tag' >> make[4]: *** [test-fcntl-h-c++] Error 1 >> make[4]: Leaving directory `/home/jas/src/libidn/gltests' > > Hmm. When I do > $ ./gnulib-tool --create-testdir --dir=/tmp/testdir --with-tests --libtool > fcntl-h > and configure and build that testdir, everything works fine, including these > commands: That works fine for me as well. > This is for both --disable-shared and --enable-shared, with or without > --preserve-dup-deps. So I guess you have an older version of libtool? > The version that works for me is 2.2.6. No, I have version '2.2.6b' from debian. I noticed one thing: if I add AC_PROG_CXX to libidn/configure.ac everything works. So I believe this is a bug in gnulib, it is adding C++ files to my project so it should make sure that a C++ compiler is available. I see the ansi-c++-opt module, maybe it is missing some libtool magic? /Simon
Re: New stable snapshot
Hi Ian,
> I've released a new stable snapshot. See attached NEWS.stable for details.
Thanks for doing this. It's time to advertise your stable releases a little
more. Here's a proposed doc change:
2010-03-09 Bruno Haible
* doc/gnulib-intro.texi (Steady Development): Mention Ian Beckwith's
stable releases.
--- doc/gnulib-intro.texi.orig Tue Mar 9 10:50:43 2010
+++ doc/gnulib-intro.texi Tue Mar 9 10:50:24 2010
@@ -312,10 +312,23 @@
Gnulib modules are continually adapted, to match new practices, to be
consistent with newly added modules, or simply as a response to build
-failure reports. We don't make releases, but instead recommend to use the
-newest version of Gnulib from the Git repository, except in periods of major
-changes. The source tree can also be fetched from a read-only CVS that
-mirrors the Git repository.
+failure reports. Gnulib is available in two qualities:
+
+...@itemize
+...@item
+There is the newest version of Gnulib from the Git repository. The
+source tree can also be fetched from a read-only CVS that mirrors the Git
+repository.
+
+...@item
+We also make stable releases every two months, at
+...@url{http://erislabs.net/ianb/projects/gnulib/}.
+...@end itemize
+
+If you are willing to report an occasional regression, we recommend to
+use the newest version always, except in periods of major changes. Most
+Gnulib users do this. If you prefer stable releases, please use the
+newest stable release.
@node Openness
@section Openness
latest test-string-c++.c causes CXX compilation failure
Hi, I tried the latest from gnulib via coreutils, and saw this: In file included from test-string-c++.cc:23: ../lib/string.h:301: error: type of 'memchr' is unknown ../lib/string.h:301: error: invalid type in declaration before ';' token ../lib/string.h:301: error: 'int memchr' redeclared as different kind of symbol /usr/include/string.h:76: error: previous declaration of 'const void* memchr(cons t void*, int, size_t)' In file included from test-string-c++.cc:23: ../lib/string.h:371: error: no matches converting function 'memrchr' to type 'voi d* (*)(const void*, int, size_t)' /usr/include/string.h:114: error: candidates are: void* memrchr(void*, int, size_ t) /usr/include/string.h:116: error: const void* memrchr(const void* , int, size_t) ../lib/string.h:372: error: type of 'memrchr' is unknown In file included from test-string-c++.cc:23: ../lib/string.h:372: error: invalid type in declaration before ';' token ../lib/string.h:372: error: 'int memrchr' redeclared as different kind of symbol /usr/include/string.h:116: error: previous declaration of 'const void* memrchr(co nst void*, int, size_t)' In file included from test-string-c++.cc:23: ../lib/string.h:572: error: no matches converting function 'strpbrk' to type 'cha r* (*)(const char*, const char*)' /usr/include/string.h:292: error: candidates are: char* strpbrk(char*, const char *) /usr/include/string.h:294: error: const char* strpbrk(const char* , const char*) ../lib/string.h:574: error: type of 'strpbrk' is unknown ../lib/string.h:574: error: invalid type in declaration before ';' token ../lib/string.h:574: error: 'int strpbrk' redeclared as different kind of symbol /usr/include/string.h:294: error: previous declaration of 'const char* strpbrk(co nst char*, const char*)' In file included from test-string-c++.cc:23: ../lib/string.h:662: error: no matches converting function 'strstr' to type 'char * (*)(const char*, const char*)' /usr/include/string.h:319: error: candidates are: char* strstr(char*, const char* ) /usr/include/string.h:321: error: const char* strstr(const char*, const char*) ../lib/string.h:664: error: type of 'strstr' is unknown ../lib/string.h:664: error: invalid type in declaration before ';' token ../lib/string.h:664: error: 'int strstr' redeclared as different kind of symbol /usr/include/string.h:321: error: previous declaration of 'const char* strstr(con st char*, const char*)' test-string-c++.cc:28: error: 'memchr' is not a member of 'gnulib' make[3]: *** [test-string-c++.o] Error 1 -- After a little preprocessing, I found this: k.cc:3:1: warning: "__STDC__" redefined : warning: this is the location of the previous definition k.cc:5:1: warning: "__STDC_HOSTED__" redefined : warning: this is the location of the previous definition k.cc:3563: error: no matches converting function 'memchr' to type 'void* (*)(const void*, int, size_t)' k.cc:3052: error: candidates are: void* memchr(void*, int, size_t) k.cc:3054: error: const void* memchr(const void*, int, size_t) k.cc:3566: error: type of 'memchr' is unknown k.cc:3566: error: invalid type in declaration before ';' token k.cc:3566: error: 'int memchr' redeclared as different kind of symbol k.cc:3054: error: previous declaration of 'const void* memchr(const void*, int, size_t)' k.cc:3573: error: no matches converting function 'memrchr' to type 'void* (*)(const void*, int, size_t)' k.cc:3079: error: candidates are: void* memrchr(void*, int, size_t) k.cc:3081: error: const void* memrchr(const void*, int, size_t) k.cc:3574: error: type of 'memrchr' is unknown k.cc:3574: error: invalid type in declaration before ';' token k.cc:3574: error: 'int memrchr' redeclared as different kind of symbol k.cc:3081: error: previous declaration of 'const void* memrchr(const void*, int, size_t)' k.cc:3597: error: no matches converting function 'strpbrk' to type 'char* (*)(const char*, const char*)' k.cc:3238: error: candidates are: char* strpbrk(char*, const char*) k.cc:3240: error: const char* strpbrk(const char*, const char*) k.cc:3599: error: type of 'strpbrk' is unknown k.cc:3599: error: invalid type in declaration before ';' token k.cc:3599: error: 'int strpbrk' redeclared as different kind of symbol k.cc:3240: error: previous declaration of 'const char* strpbrk(const char*, const char*)' k.cc:3601: error: no matches converting function 'strstr' to type 'char* (*)(const char*, const char*)' k.cc:3252: error: candidates are: char* strstr(char*, const char*) k.cc:3254: error: const char* strstr(const char*, const char*) k.cc:3603: error: type of 'strstr' is unknown k.cc:3603: error: invalid type in declaration before ';' token k.cc:3603: error: 'int strstr' redeclared as different kind of symbol k.cc:3254: error: previous declaration of 'const char* strstr(const char*, const char*)' Line 3563 starts her
Re: latest test-string-c++.c causes CXX compilation failure
Jim Meyering wrote: > I tried the latest from gnulib via coreutils, > and saw this: > > In file included from test-string-c++.cc:23: > ../lib/string.h:301: error: type of 'memchr' is unknown > ../lib/string.h:301: error: invalid type in declaration before ';' token > ../lib/string.h:301: error: 'int memchr' redeclared as different kind of > symbol > /usr/include/string.h:76: error: previous declaration of 'const void* > memchr(cons More details: The above was on F12, with $ g++ --version g++ (GCC) 4.4.3 20100127 (Red Hat 4.4.3-4)
Re: C++ libtool build error?
On 03/09/2010 01:02 AM, Simon Josefsson wrote: > No, I have version '2.2.6b' from debian. > > I noticed one thing: if I add AC_PROG_CXX to libidn/configure.ac > everything works. So I believe this is a bug in gnulib, it is adding > C++ files to my project so it should make sure that a C++ compiler is > available. I see the ansi-c++-opt module, maybe it is missing some > libtool magic? Which begs the question - why is gnulib-tool making C-only projects to import C++ test files? It seems like C++ files should be excluded unless the developer explicitly requests that both C and C++ be supported. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: C++ libtool build error?
Eric Blake writes: > On 03/09/2010 01:02 AM, Simon Josefsson wrote: >> No, I have version '2.2.6b' from debian. >> >> I noticed one thing: if I add AC_PROG_CXX to libidn/configure.ac >> everything works. So I believe this is a bug in gnulib, it is adding >> C++ files to my project so it should make sure that a C++ compiler is >> available. I see the ansi-c++-opt module, maybe it is missing some >> libtool magic? > > Which begs the question - why is gnulib-tool making C-only projects to > import C++ test files? It seems like C++ files should be excluded > unless the developer explicitly requests that both C and C++ be supported. That would indeed be nice (I'd prefer to not ever risk having to worry about C++ compiler issues for a C library), but I'm not sure there is any capability like that in gnulib today. /Simon
Re: [PATCH] (x)memcoll: performance improvement when input is known to be NUL delimited.
Hi Bruno,
I tried with the checks for the presence of that last NUL byte like you
suggested, and to my surprise on the remote machine I was testing on it was
consistently (as in every run for 20 runs) faster, and thus I've included it in
the patch. This is not what I expected at all, and I'm having a hard time
coming up with a reason why this is; if someone has an explanation I'd love to
know. I also tested on my laptop, but even after killing X the variance was too
high for meaningful results.
Even though gnulib seems to have it's own stdlib.h, I included
in memcoll.c instead, since that's what xmemcoll.c includes.
>From 19516c730bced56670d180899d099e18be2a9ae3 Mon Sep 17 00:00:00 2001
From: Chen Guo
Date: Sun, 7 Mar 2010 17:07:49 -0800
Subject: [PATCH] (x)memcoll: performance improvement when input is known to be
NUL delimited.
This is in suport of a patch to coreutils' sort, where for each
input line xmemcoll is called several times. If each input line is
NUL delimited when read in, memcoll no longer needs to save the
last byte, NUL delimit, then put the last byte back every time the
line is compared. Sorting a 96MB, 1M line file, performance
improvement is roughly 1%.
* lib/memcoll.c: Include stdlib.
(memcoll0) New function.
(strcoll_loop) New function, refactored for use in both memcoll
and memcoll0.
* lib/memcoll.h: Add prototype for memcoll0.
* lib/xmemcoll.c: (xmemcoll0) New function.
(collate_error) New function, refactored for use in both xmemcoll
and xmemcoll0.
* lib/xmemcoll.h: Add prototype for xmemcoll0.
* m4/memcoll.m4: add inline invocation.
---
lib/memcoll.c | 88 +++
lib/memcoll.h |1 +
lib/xmemcoll.c | 35 +-
lib/xmemcoll.h |1 +
m4/memcoll.m4 |1 +
5 files changed, 86 insertions(+), 40 deletions(-)
diff --git a/lib/memcoll.c b/lib/memcoll.c
index e08ffa5..8e48551 100644
--- a/lib/memcoll.c
+++ b/lib/memcoll.c
@@ -23,20 +23,54 @@
#include "memcoll.h"
#include
+#include
#include
+/* Ensure strcoll operates on the entire input strings, in case they contain
+ NUL bytes. */
+
+static inline int
+strcoll_loop (const char *s1, size_t s1len, const char *s2, size_t s2len)
+{
+ int diff;
+ while (! (errno = 0, (diff = strcoll (s1, s2)) || errno))
+{
+ /* strcoll found no difference, but perhaps it was fooled by NUL
+ characters in the data. Work around this problem by advancing
+ past the NUL chars. */
+ size_t size1 = strlen (s1) + 1;
+ size_t size2 = strlen (s2) + 1;
+ s1 += size1;
+ s2 += size2;
+ s1len -= size1;
+ s2len -= size2;
+
+ if (s1len == 0)
+{
+ if (s2len != 0)
+diff = -1;
+ break;
+}
+ else if (s2len == 0)
+{
+ diff = 1;
+ break;
+}
+}
+ return diff;
+}
+
/* Compare S1 (with length S1LEN) and S2 (with length S2LEN) according
to the LC_COLLATE locale. S1 and S2 do not overlap, and are not
adjacent. Perhaps temporarily modify the bytes after S1 and S2,
but restore their original contents before returning. Set errno to an
error number if there is an error, and to zero otherwise. */
+
int
memcoll (char *s1, size_t s1len, char *s2, size_t s2len)
{
int diff;
-#if HAVE_STRCOLL
-
/* strcoll is slow on many platforms, so check for the common case
where the arguments are bytewise equal. Otherwise, walk through
the buffers using strcoll on each substring. */
@@ -54,43 +88,33 @@ memcoll (char *s1, size_t s1len, char *s2, size_t s2len)
s1[s1len++] = '\0';
s2[s2len++] = '\0';
- while (! (errno = 0, (diff = strcoll (s1, s2)) || errno))
-{
- /* strcoll found no difference, but perhaps it was fooled by NUL
- characters in the data. Work around this problem by advancing
- past the NUL chars. */
- size_t size1 = strlen (s1) + 1;
- size_t size2 = strlen (s2) + 1;
- s1 += size1;
- s2 += size2;
- s1len -= size1;
- s2len -= size2;
-
- if (s1len == 0)
-{
- if (s2len != 0)
-diff = -1;
- break;
-}
- else if (s2len == 0)
-{
- diff = 1;
- break;
-}
-}
+ diff = strcoll_loop (s1, s1len, s2, s2len);
s1[s1len - 1] = n1;
s2[s2len - 1] = n2;
}
-#else
+ return diff;
+}
- diff = memcmp (s1, s2, s1len < s2len ? s1len : s2len);
- if (! diff)
-diff = s1len < s2len ? -1 : s1len != s2len;
- errno = 0;
+/* Like memcoll, but S1 and S2 are known to be NUL delimited, thus no
+ modification to S1 or S2 are needed. */
+int
+memcoll0 (const char *s1, size_t s1len, const char *s2, size_t s2len)
+{
+ int diff;
+ if (!(s1len > 0 && s1[s1len] == '\0'))
+abort ();
+ if (!(s2len > 0 && s2[s2len] == '\0'))
+abo
