Re: localcharset is conditional on HAVE_SETLOCALE

[Bruno Haible]

Paul Eggert wrote:
> The localcharset test slows down 'configure' and
> does not affect how the code actually behaves.  OK to install this?
> 
> 2006-10-17  Paul Eggert  <[EMAIL PROTECTED]>
> 
>   Simplify localcharset code a bit and speed up configuration
>   by removing test for setlocale.
>   * lib/localcharset.c: Do not include  or
>   check HAVE_SETLOCALE, since the code never invokes setlocale
>   anyway.  This change doesn't affect runtime behavior.
>   * m4/localcharset.m4 (gl_LOCALCHARSET): Don't check for setlocale.

Thanks for the patch. I prefer to keep the comments in place, in a #if 0.
So I committed this:


2006-10-17  Paul Eggert  <[EMAIL PROTECTED]>

* lib/localcharset.c: Do not check HAVE_SETLOCALE.
* m4/localcharset.m4 (gl_LOCALCHARSET): Don't check for setlocale.

diff -c -3 -r1.25 localcharset.c
*** lib/localcharset.c  14 Sep 2006 14:18:36 -  1.25
--- lib/localcharset.c  18 Oct 2006 12:02:24 -
***
*** 41,47 
  # if HAVE_LANGINFO_CODESET
  #  include 
  # else
! #  if HAVE_SETLOCALE
  #   include 
  #  endif
  # endif
--- 41,47 
  # if HAVE_LANGINFO_CODESET
  #  include 
  # else
! #  if 0 /* see comment below */
  #   include 
  #  endif
  # endif
***
*** 351,357 
   (like SunOS 4 or DJGPP) have only the C locale.  Therefore we don't
   use setlocale here; it would return "C" when it doesn't support the
   locale name the user has set.  */
! #  if HAVE_SETLOCALE && 0
locale = setlocale (LC_CTYPE, NULL);
  #  endif
if (locale == NULL || locale[0] == '\0')
--- 351,357 
   (like SunOS 4 or DJGPP) have only the C locale.  Therefore we don't
   use setlocale here; it would return "C" when it doesn't support the
   locale name the user has set.  */
! #  if 0
locale = setlocale (LC_CTYPE, NULL);
  #  endif
if (locale == NULL || locale[0] == '\0')
diff -c -3 -r1.5 localcharset.m4
*** m4/localcharset.m4  31 Jul 2006 16:09:08 -  1.5
--- m4/localcharset.m4  18 Oct 2006 12:02:24 -
***
*** 1,4 
! # localcharset.m4 serial 4
  dnl Copyright (C) 2002, 2004, 2006 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
--- 1,4 
! # localcharset.m4 serial 5
  dnl Copyright (C) 2002, 2004, 2006 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
***
*** 9,15 
dnl Prerequisites of lib/localcharset.c.
AC_REQUIRE([AM_LANGINFO_CODESET])
AC_CHECK_DECLS_ONCE(getc_unlocked)
-   AC_CHECK_FUNCS_ONCE(setlocale)
  
dnl Prerequisites of the lib/Makefile.am snippet.
AC_REQUIRE([AC_CANONICAL_HOST])
--- 9,14 

setlocale (was: Re: hello-2.1.93 internationalization doesn't work)

[Simon Josefsson]

Bruno Haible <[EMAIL PROTECTED]> writes:

> The reason is that HAVE_SETLOCALE is tested, but nowhere defined. Since one
> can assume setlocale() already for ca. 5 years, there is no risk in removing
> the HAVE_SETLOCALE. Here is a proposed patch.

I'm still testing for setlocale in libidn.  Why can we assume
setlocale exists?  Is it POSIX?  Or is there some mechanism that turn
the call to setlocale into a null-op if the system doesn't have it?

/Simon

Re: setlocale (was: hello-2.1.93 internationalization doesn't work)

[Bruno Haible]

Simon Josefsson wrote:
> Why can we assume setlocale exists?

Because we haven't encountered systems without a setlocale() for 10 years.
The last such system that I remember was Linux libc5 5.0.xx or 5.2.xx.

> Is it POSIX?

Even more: It's specified by ISO C 99.

Bruno

Re: setlocale

[Simon Josefsson]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Simon Josefsson wrote:
>> Why can we assume setlocale exists?
>
> Because we haven't encountered systems without a setlocale() for 10 years.
> The last such system that I remember was Linux libc5 5.0.xx or 5.2.xx.
>
>> Is it POSIX?
>
> Even more: It's specified by ISO C 99.

Ah, thanks.  I noticed that the LibIDN example code (which is always
built) didn't check for HAVE_SETLOCALE nor HAVE_LOCALE_H, and nobody
has complained, so I dropped the check for the front-end tool as well.

/Simon

read_utmp changes

[Sergey Poznyakoff]

I have installed the following change to read_utmp:

2006-10-18  Sergey Poznyakoff  <[EMAIL PROTECTED]>

* lib/readutmp.c (desirable_utmp_entry): Implement new flag:
READ_UTMP_USER_PROCESS.
* lib/readutmp.h (READ_UTMP_USER_PROCESS): New flag

Index: lib/readutmp.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/readutmp.c,v
retrieving revision 1.25
diff -p -u -r1.25 readutmp.c
--- lib/readutmp.c  13 Sep 2006 22:38:14 -  1.25
+++ lib/readutmp.c  18 Oct 2006 13:23:43 -
@@ -69,10 +69,15 @@ extract_trimmed_name (const STRUCT_UTMP 
 static inline bool
 desirable_utmp_entry (STRUCT_UTMP const *u, int options)
 {
-  return ! (options & READ_UTMP_CHECK_PIDS
-   && IS_USER_PROCESS (u)
-   && (UT_PID (u) <= 0
-   || (kill (UT_PID (u), 0) < 0 && errno == ESRCH)));
+  int up = IS_USER_PROCESS (u);
+  if ((options & READ_UTMP_USER_PROCESS) && !up)
+return false;
+  if ((options & READ_UTMP_CHECK_PIDS)
+  && up
+  && (UT_PID (u) <= 0
+ || (kill (UT_PID (u), 0) < 0 && errno == ESRCH)))
+return false;
+  return true;
 }
 
 /* Read the utmp entries corresponding to file FILE into freshly-
Index: lib/readutmp.h
===
RCS file: /cvsroot/gnulib/gnulib/lib/readutmp.h,v
retrieving revision 1.21
diff -p -u -r1.21 readutmp.h
--- lib/readutmp.h  22 Aug 2006 17:34:55 -  1.21
+++ lib/readutmp.h  18 Oct 2006 13:23:43 -
@@ -202,7 +202,8 @@ enum { UT_USER_SIZE = sizeof UT_USER ((S
 /* Options for read_utmp.  */
 enum
   {
-READ_UTMP_CHECK_PIDS = 1
+READ_UTMP_CHECK_PIDS = 1,
+READ_UTMP_USER_PROCESS = 2
   };
 
 char *extract_trimmed_name (const STRUCT_UTMP *ut);

Re: setlocale

[Ben Pfaff]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Simon Josefsson wrote:
>> Why can we assume setlocale exists?
>> Is it POSIX?
>
> Even more: It's specified by ISO C 99.

Even more than that: it's in C90 also.
-- 
Ben Pfaff 
email: [EMAIL PROTECTED]
web: http://benpfaff.org

Reusing vasnprintf

[Daniel Jacobowitz]

For GDB, we're looking at fixing our printf built in command once and
for all.  What we really need to do that is two separate interfaces
that can talk to each other: one for parsing a format string, and one
for converting arguments.  Basically, this is printf_parse plus the
rest of vasnprintf, but without printf_fetchargs.

Could I persuade you to split the existing vasnprintf along these
lines, so that we can use it?  I can submit a patch myself if necessary
to shuffle all the code around, but I don't have a gnulib assignment;
not sure whether that would be considered trivial.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [bug-gnulib] Reusing vasnprintf

[Bruno Haible]

Daniel Jacobowitz wrote:
> For GDB, we're looking at fixing our printf built in command once and
> for all.  What we really need to do that is two separate interfaces
> that can talk to each other: one for parsing a format string, and one
> for converting arguments.

Do you need a standard printf, or an extensible printf?

In the latter case, do you need to extend the basic types? The modifiers?
The set of directives? Or do you also need to modify the implementation
of existing, standardized directives?

How does what you need compare with the register_printf_function /
parse_printf_format facility in glibc's public header file  ?

Bruno

Re: [bug-gnulib] Reusing vasnprintf

[Daniel Jacobowitz]

On Wed, Oct 18, 2006 at 06:08:22PM +0200, Bruno Haible wrote:
> Daniel Jacobowitz wrote:
> > For GDB, we're looking at fixing our printf built in command once and
> > for all.  What we really need to do that is two separate interfaces
> > that can talk to each other: one for parsing a format string, and one
> > for converting arguments.
> 
> Do you need a standard printf, or an extensible printf?

A standard printf.  We're not trying to print out new things, we're
trying to print out standard things using different sorts of arguments.

Here's an example.  You can open up GDB and say this:

(gdb) printf "%lld\n", 1
1

But that "1" isn't ever something you can fetch with va_arg (long
long).  It's a GDB "struct value".  Also, it may not be the same size
as a host long long.  A better example for that is just "long"; if
you're running a 64-bit amd64 GDB, talking to a 32-bit ARM target,
the target "long" type doesn't match the host's "long" type.  GDB knows
how to do all the necessary conversions.

> How does what you need compare with the register_printf_function /
> parse_printf_format facility in glibc's public header file  ?

Wow, I knew about register_printf_function, but I'd never noticed
parse_printf_format before.

printf breaks down into three stages: parsing the format string,
recovering the arguments, and constructing the output string.  We need
completely normal versions of the first and third, but a non-va_arg
based version of the second.  If there was some way to construct a
va_arg programmatically, which there isn't, we could do this with
parse_printf_format (or the gnulib version) plus the existing
vasnprintf.

-- 
Daniel Jacobowitz
CodeSourcery

Re: __long64_t not declared AIX 5.3.0.50, gcc 4.0.2

[Paul Eggert]

In 
Perry Smith <[EMAIL PROTECTED]> writes:

> *** lib/inttypes_.h   Mon Aug 28 20:42:18 2006
> --- lib/inttypes.hTue Oct 17 04:01:55 2006

Thanks, I got that patch.  Unfortunately the diff between
lib/stdint_.h and lib/stdint.h doesn't match coreutils 6.3
lib/stdint_.h, so I guess you modified stdint_.h first?

Anyway, in thinking about the original symptoms, I came up
with a different patch against coreutils 6.3 lib/stdint_.h.
Can you please try the following patch instead?  (Please
apply the patch to the original 6.3 lib/stdint_.h.)

If this patch doesn't work, please send the compiler
diagnostics along with the complete output of the command
"gcc -std=gnu99 -I. -E xstrtoimax.c".

Thanks.

2006-10-18  Paul Eggert  <[EMAIL PROTECTED]>

* lib/stdint_.h: Include  before ,
to avoid a problem with AIX 5.3 reported by Perry Smith in
.

*** lib/stdint_.h.~1.34.~   Tue Oct 10 22:58:47 2006
--- lib/stdint_.h   Wed Oct 18 09:56:49 2006
***
*** 46,60 
  # include @ABSOLUTE_STDINT_H@
  #endif
  
- /*  defines some of the stdint.h types as well, on glibc,
-IRIX 6.5, and OpenBSD 3.8 (via ).
-MacOS X 10.4.6  includes  (which is us), but
-relies on the system  definitions, so include
- after @[EMAIL PROTECTED]  */
- #if @HAVE_SYS_TYPES_H@
- # include 
- #endif
- 
  /* Get LONG_MIN, LONG_MAX, ULONG_MAX.  */
  #include 
  
--- 46,51 
***
*** 65,76 
  # define _GL_JUST_INCLUDE_ABSOLUTE_INTTYPES_H
  # include 
  # undef _GL_JUST_INCLUDE_ABSOLUTE_INTTYPES_H
! #elif @HAVE_SYS_INTTYPES_H@
/* Solaris 7  has the types except the *_fast*_t types, and
!  the macros except for *_FAST*_*, INTPTR_MIN, PTRDIFF_MIN, PTRDIFF_MAX.  
*/
  # include 
  #endif
  
  #if @HAVE_SYS_BITYPES_H@ && ! defined __BIT_TYPES_DEFINED__
/* Linux libc4 >= 4.6.7 and libc5 have a  that defines
   int{8,16,32,64}_t and __BIT_TYPES_DEFINED__.  In libc5 >= 5.2.2 it is
--- 56,81 
  # define _GL_JUST_INCLUDE_ABSOLUTE_INTTYPES_H
  # include 
  # undef _GL_JUST_INCLUDE_ABSOLUTE_INTTYPES_H
! #endif
! 
! #if @HAVE_SYS_INTTYPES_H@
/* Solaris 7  has the types except the *_fast*_t types, and
!  the macros except for *_FAST*_*, INTPTR_MIN, PTRDIFF_MIN, PTRDIFF_MAX.
!  AIX 5.3  includes  (which is us), but its
!   relies on the  definitions, so include
!   before .  */
  # include 
  #endif
  
+ /*  defines some of the stdint.h types as well, on glibc,
+IRIX 6.5, and OpenBSD 3.8 (via ).
+MacOS X 10.4.6  includes  (which is us), but
+relies on the system  definitions, so include
+ after @[EMAIL PROTECTED]  */
+ #if @HAVE_SYS_TYPES_H@
+ # include 
+ #endif
+ 
  #if @HAVE_SYS_BITYPES_H@ && ! defined __BIT_TYPES_DEFINED__
/* Linux libc4 >= 4.6.7 and libc5 have a  that defines
   int{8,16,32,64}_t and __BIT_TYPES_DEFINED__.  In libc5 >= 5.2.2 it is

Re: setlocale

[Paul Eggert]

Ben Pfaff <[EMAIL PROTECTED]> writes:

> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> Simon Josefsson wrote:
>>> Why can we assume setlocale exists?
>>> Is it POSIX?
>>
>> Even more: It's specified by ISO C 99.
>
> Even more than that: it's in C90 also.

Yes, that's the key point: it was in ISO C90 aka ANSI C89.  But even
more than that: setlocale was in XPG3, and therefore in SunOS 4
(introduced 1989, last shipped to customers on 1998-09-30), which for
many years was the oldest Unix that could conceivably be a target of
modern GNU apps.  You have to go back to something like SVR3
(introduced 1986, probably last shipped to customers around 1990) to
find a system that lacks setlocale, but SVR3 is 100% dead now.

Theoretically we might still have problem with setlocale, since
freestanding C implementations are not required to supply setlocale or
 -- this is true even for C99.  But if this turns into a
real problem, we can write a setlocale module that supplies a no-op
substitute.

Re: read_utmp changes

[Jim Meyering]

"Sergey Poznyakoff" <[EMAIL PROTECTED]> wrote:
> I have installed the following change to read_utmp:
>
> 2006-10-18  Sergey Poznyakoff  <[EMAIL PROTECTED]>
>
> * lib/readutmp.c (desirable_utmp_entry): Implement new flag:
> READ_UTMP_USER_PROCESS.
> * lib/readutmp.h (READ_UTMP_USER_PROCESS): New flag

Hi Sergey,

That change looks fine.  Next time I'll try to reply sooner.
I've made this additional change:

2006-10-18  Jim Meyering  <[EMAIL PROTECTED]>

* lib/readutmp.c (desirable_utmp_entry): Use "bool" as the
type for a local, and rename it: s/up/user_proc/.

Index: lib/readutmp.c
===
RCS file: /sources/gnulib/gnulib/lib/readutmp.c,v
retrieving revision 1.26
diff -u -r1.26 readutmp.c
--- lib/readutmp.c  18 Oct 2006 13:24:19 -  1.26
+++ lib/readutmp.c  18 Oct 2006 17:49:14 -
@@ -69,11 +69,11 @@
 static inline bool
 desirable_utmp_entry (STRUCT_UTMP const *u, int options)
 {
-  int up = IS_USER_PROCESS (u);
-  if ((options & READ_UTMP_USER_PROCESS) && !up)
+  bool user_proc = IS_USER_PROCESS (u);
+  if ((options & READ_UTMP_USER_PROCESS) && !user_proc)
 return false;
   if ((options & READ_UTMP_CHECK_PIDS)
-  && up
+  && user_proc
   && (UT_PID (u) <= 0
  || (kill (UT_PID (u), 0) < 0 && errno == ESRCH)))
 return false;

Re: [bug-gnulib] Reusing vasnprintf

[Bruno Haible]

Daniel Jacobowitz wrote:
> A standard printf.  We're not trying to print out new things, we're
> trying to print out standard things using different sorts of arguments.
> 
> Here's an example.  You can open up GDB and say this:
> 
> (gdb) printf "%lld\n", 1
> 1

OK, thanks, I see the intent and the cross-compilation issues...

> > How does what you need compare with the register_printf_function /
> > parse_printf_format facility in glibc's public header file  ?
> 
> Wow, I knew about register_printf_function, but I'd never noticed
> parse_printf_format before.

But without the other part, which constructs the output string, this
function is useless to gdb, right? So there's no point in gnulib trying
to make a 100% glibc compatible parse_printf_format.

> printf breaks down into three stages: parsing the format string,
> recovering the arguments, and constructing the output string.  We need
> completely normal versions of the first and third, but a non-va_arg
> based version of the second.

Are you sure you can use the parsing stage and the output stage without
modifications?
- In the parsing phase, you need to recognize %lld also if the host environment
  doesn't support long longs (e.g. on MSVC hosts). This means the
  #ifdef HAVE_LONG_LONG_INT
  in printf-args.h needs to be adjusted for your use case.
- In the output stage, when the host has 32-bit 'long's and the target
  environment has 64-bit 'long's, the output routine that converts a
  'long' to decimal needs to be able to produce 20 decimal digits, not
  just 10.
- Also in the output stage, when you encounter a %ls directive with a
  wide string argument, to you perform the wcstombs on the host machine
  or on the target machine?

Bruno

Re: [bug-gnulib] Reusing vasnprintf

[Daniel Jacobowitz]

On Wed, Oct 18, 2006 at 09:44:58PM +0200, Bruno Haible wrote:
> > > How does what you need compare with the register_printf_function /
> > > parse_printf_format facility in glibc's public header file  ?
> > 
> > Wow, I knew about register_printf_function, but I'd never noticed
> > parse_printf_format before.
> 
> But without the other part, which constructs the output string, this
> function is useless to gdb, right? So there's no point in gnulib trying
> to make a 100% glibc compatible parse_printf_format.

Right.

> > printf breaks down into three stages: parsing the format string,
> > recovering the arguments, and constructing the output string.  We need
> > completely normal versions of the first and third, but a non-va_arg
> > based version of the second.
> 
> Are you sure you can use the parsing stage and the output stage without
> modifications?
> - In the parsing phase, you need to recognize %lld also if the host 
> environment
>   doesn't support long longs (e.g. on MSVC hosts). This means the
>   #ifdef HAVE_LONG_LONG_INT
>   in printf-args.h needs to be adjusted for your use case.

Yes, it looks like you're right.  And, similar changes would have to be
made to printf-parse.c.  If we did this to the same copy, that would
change the behavior of "%lld" on hosts which don't support long long;
previously it would be handled as "long", and subsequently it would
lead to an error in printf_fetchargs.  Is that undesirable?

> - In the output stage, when the host has 32-bit 'long's and the target
>   environment has 64-bit 'long's, the output routine that converts a
>   'long' to decimal needs to be able to produce 20 decimal digits, not
>   just 10.

No, I don't think I'd do it that way - it would be crazy, because it
would have to rely on a different member of the arg union to hold the
value, which would not fit otherwise.

I was figuring I'd transform the result of printf-parse.c
appropriately as I fetched the arguments.  When presented with a
"%ld" conversion that wouldn't work on the host, I'd adjust the
flags to do a host "%lld" instead.

I'm now worrying that I misunderstood how the gnulib vasnprintf works,
though.  This may be less useful than I thought, since it uses both the
result of arg parsing and the format string :-(

> - Also in the output stage, when you encounter a %ls directive with a
>   wide string argument, to you perform the wcstombs on the host machine
>   or on the target machine?

To be honest, I don't particularly care about this today.  GDB support
for wide strings is miniscule and no one is improving it.  However,
if I were to support it, I would try to emulate the target machine's
behavior on the host through some other mechanism.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [bug-gnulib] Reusing vasnprintf

[Daniel Jacobowitz]

On Wed, Oct 18, 2006 at 04:10:46PM -0400, Daniel Jacobowitz wrote:
> I'm now worrying that I misunderstood how the gnulib vasnprintf works,
> though.  This may be less useful than I thought, since it uses both the
> result of arg parsing and the format string :-(

Never mind, this bit is obviously incorrect on a closer reading.

-- 
Daniel Jacobowitz
CodeSourcery

hello pretest 2.1.94

[Karl Berry]

I put another hello pretest at
ftp://alpha.gnu.org/gnu/hello/hello-2.1.94.tar.bz2 (and .gz).

Maybe someday it'll even be ready for a release :).

Thanks,
Karl

Re: hello pretest 2.1.94

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Karl Berry on 10/18/2006 5:33 PM:
> I put another hello pretest at
> ftp://alpha.gnu.org/gnu/hello/hello-2.1.94.tar.bz2 (and .gz).
> 
> Maybe someday it'll even be ready for a release :).

Is it worth demonstrating how to portably use gcc __attribute__'s to mark
my_exit as never returning?  Other than that, I'm not seeing anything
wrong in your reworked hello.c :)

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFNuzC84KuGfSFAYARAgUuAJ406s21SR2rPFKj5d8ZbiGvCsfUNwCePg3l
qVK+qai1fj61vXi6+XntmVU=
=YIxD
-END PGP SIGNATURE-

strftime.c problem on dietlibc

[Eelco Dolstra]

Hi,

When compiling coreutils-5.3 with dietlibc I got the following compiler error:

In file included from fprintftime.c:7:
strftime.c: In function 'strftime_case_':
strftime.c:645: error: invalid use of undefined type 'struct __stdio_file'
strftime.c:737: error: invalid use of undefined type 'struct __stdio_file'
etc.

The problem is in the following line in the add(n, f) macro in strftime.c:

  p += FPRINTFTIME ? 0 : _n;

where p is a FILE *.  If the storage size of FILE is not known (which is the
case on dietlibc), then the compiler cannot increase the pointer p, not even by 
0.

Patch (against latest CVS) is attached.

-- 
Eelco Dolstra | http://www.cs.uu.nl/~eelco
? strftime-uclibc.patch
Index: lib/strftime.c
===
RCS file: /sources/gnulib/gnulib/lib/strftime.c,v
retrieving revision 1.91
diff -c -r1.91 strftime.c
*** lib/strftime.c  8 Oct 2006 07:24:56 -   1.91
--- lib/strftime.c  18 Oct 2006 15:20:03 -
***
*** 181,186 
--- 181,192 
  # define memset_zero(P, Len) (memset (P, '0', Len), (P) += (Len))
  #endif
  
+ #if FPRINTFTIME
+ #define advance(p, _n) ;
+ #else
+ #define advance(p, _n) p += _n;
+ #endif 
+ 
  #define add(n, f)   \
do\
  {   \
***
*** 199,205 
memset_space (p, _delta); \
} \
  f;  \
! p += FPRINTFTIME ? 0 : _n;  \
} \
i += _incr;   \
  } while (0)
--- 205,211 
memset_space (p, _delta); \
} \
  f;  \
! advance(p, _n); \
} \
i += _incr;   \
  } while (0)

[patch] gnulib-tool --local-dir

[Charles Wilson]

Doesn't seem to work properly without the following (obvious?) patch.

--
Chuck

2006-10-18  Charles Wilson  

* gnulib-tool: trimming $local_gnulib_dir variable shouldn't
clobber $sourcebase.
Index: gnulib-tool
===
RCS file: /sources/gnulib/gnulib/gnulib-tool,v
retrieving revision 1.180
diff -u -r1.180 gnulib-tool
--- gnulib-tool 13 Oct 2006 12:40:22 -  1.180
+++ gnulib-tool 19 Oct 2006 01:13:40 -
@@ -678,7 +678,7 @@
   # m4base (to avoid an error in func_import) and optional for the others.
   sed_trimtrailingslashes='s,\([^/]\)//*$,\1,'
   case "$local_gnulib_dir" in
-*/ ) sourcebase=`echo "$local_gnulib_dir" | sed -e 
"$sed_trimtrailingslashes"` ;;
+*/ ) local_gnulib_dir=`echo "$local_gnulib_dir" | sed -e 
"$sed_trimtrailingslashes"` ;;
   esac
   case "$sourcebase" in
 */ ) sourcebase=`echo "$sourcebase" | sed -e "$sed_trimtrailingslashes"` ;;