control of symbols exported by shared libraries
Hi,
gcc-4.0 now provides support for controlling the set of symbols exported
from a shared library in a reasonable, maintainable way. I have added a
gnulib module to this effect. With documentation, this time :-)
Bruno
= modules/visibility =
Description:
Control of symbols exported by shared libraries.
Files:
m4/visibility.m4
Depends-on:
configure.ac:
gl_VISIBILITY
Makefile.am:
Include:
License:
LGPL
Maintainer:
Bruno Haible
== m4/visibility.m4 ==
# visibility.m4 serial 1 (gettext-0.15)
dnl Copyright (C) 2005 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
dnl with or without modifications, as long as this notice is preserved.
dnl From Bruno Haible.
dnl Tests whether the compiler supports the command-line option
dnl -fvisibility=hidden and the function and variable attributes
dnl __attribute__((__visibility__("hidden"))) and
dnl __attribute__((__visibility__("default"))).
dnl Does *not* test for __visibility__("protected") - which has tricky
dnl semantics (see the 'vismain' test in glibc) and does not exist e.g. on
dnl MacOS X.
dnl Does *not* test for __visibility__("internal") - which has processor
dnl dependent semantics.
dnl Does *not* test for #pragma GCC visibility push(hidden) - which is
dnl "really only recommended for legacy code".
dnl Set the variable CFLAG_VISIBILITY.
dnl Defines and sets the variable HAVE_VISIBILITY.
AC_DEFUN([gl_VISIBILITY],
[
AC_REQUIRE([AC_PROG_CC])
CFLAG_VISIBILITY=
HAVE_VISIBILITY=0
if test -n "$GCC"; then
AC_MSG_CHECKING([for simple visibility declarations])
AC_CACHE_VAL(gl_cv_cc_visibility, [
gl_save_CFLAGS="$CFLAGS"
CFLAGS="$CFLAGS -fvisibility=hidden"
AC_TRY_COMPILE(
[extern __attribute__((__visibility__("hidden"))) int hiddenvar;
extern __attribute__((__visibility__("default"))) int exportedvar;
extern __attribute__((__visibility__("hidden"))) int hiddenfunc (void);
extern __attribute__((__visibility__("default"))) int exportedfunc
(void);],
[],
gl_cv_cc_visibility=yes,
gl_cv_cc_visibility=no)
CFLAGS="$gl_save_CFLAGS"])
AC_MSG_RESULT([$gl_cv_cc_visibility])
if test $gl_cv_cc_visibility = yes; then
CFLAG_VISIBILITY="-fvisibility=hidden"
HAVE_VISIBILITY=1
fi
fi
AC_SUBST([CFLAG_VISIBILITY])
AC_SUBST([HAVE_VISIBILITY])
AC_DEFINE_UNQUOTED([HAVE_VISIBILITY], [$HAVE_VISIBILITY],
[Define to 1 or 0, depending whether the compiler supports simple
visibility declarations.])
])
= doc/visibility.texi =
@c Documentation of gnulib module 'visibility'.
This module allows precise control of the symbols exported by a shared
library. This is useful because
@itemize @bullet
@item
It prevents abuse of undocumented APIs of your library. Symbols that
are not exported from the library cannot be used. This eliminates the
problem that when the maintainer of the library changes internals of the
library, maintainers of other projects cry "breakage". Instead, these
maintainers are forced to negotiate the desired API from the maintainer
of the library.
@item
It reduces the risk of symbol collision between your library and other
libraries. For example, the symbol @samp{readline} is defined in several
libraries, most of which don't have the same semantics and the same calling
convention as the GNU readline library.
@item
It reduces the startup time of programs linked to the library. This is
because the dynamic loader has less symbols to process.
@item
It allows the compiler to generate better code. Within a shared library,
a call to a function that is a global symbol costs a "call" instruction
to a code location in the so-called PLT (procedure linkage table) which
contains a "jump" instruction to the actual function's code. (This is
needed so that the function can be overridden, for example by a function
with the same name in the executable or in a shared library interposed
with @code{LD_PRELOAD}.) Whereas a call to a function for which the compiler
can assume that it is in the same shared library is just a direct "call"
instructions. Similarly for variables: A reference to a global variable
fetches a pointer in the so-called GOT (global offset table); this pointer
pointer to the variable's memory. So the code to access it is two memory
load instructions. Whereas for a variable which is known to reside in the
same shared library, it is just a direct memory access: one memory load
instruction.
@end itemize
There are traditionally three ways to specify the exported symbols of a
shared library.
@itemize @bullet
@item
The programmer specifies the list of symbols to be exported when the
shared library is created. Usually a command-line option is passed
to the linker, with the name
Re: control of symbols exported by shared libraries
Bruno Haible <[EMAIL PROTECTED]> writes: > Hi, > > gcc-4.0 now provides support for controlling the set of symbols exported > from a shared library in a reasonable, maintainable way. I have added a > gnulib module to this effect. With documentation, this time :-) How does this relate to something like Libtool's -export-symbols-regex '^(idn|pr29_|punycode_|stringprep|tld_).*'? That is what I have been using to control which symbols are exported or not. Your module look somewhat gcc-specific, whereas, in theory, libtool might work with other compilers too. Thanks. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: control of symbols exported by shared libraries
Simon Josefsson wrote: > > gcc-4.0 now provides support for controlling the set of symbols exported > > from a shared library in a reasonable, maintainable way. I have added a > > gnulib module to this effect. With documentation, this time :-) > > How does this relate to something like Libtool's -export-symbols-regex > '^(idn|pr29_|punycode_|stringprep|tld_).*'? That is what I have been > using to control which symbols are exported or not. According to Ulrich Drepper's paper, http://people.redhat.com/drepper/dsohowto.pdf, section 2.2.6, this libtool option is just a placebo - if libtool hasn't changed since Ulrich looked at it. Can you let us know, by showing the output of "nm --dynamic libidn.so"? > Your module look somewhat gcc-specific, whereas, in theory, libtool > might work with other compilers too. Do you know of other compilers than GCC 4 and MSVC that support the equivalent of "-fvisibility=hidden"? Bruno ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: control of symbols exported by shared libraries
On Mon, Jul 25, 2005 at 05:46:02PM +0200, Bruno Haible wrote:
> Simon Josefsson wrote:
> > Your module look somewhat gcc-specific, whereas, in theory,
> > libtool might work with other compilers too.
>
> Do you know of other compilers than GCC 4 and MSVC that support the
> equivalent of "-fvisibility=hidden"?
The AIX v7 compiler compiles the following:
$ cat vis.c
extern __attribute__((__visibility__("hidden"))) int hiddenvar;
extern __attribute__((__visibility__("default"))) int exportedvar;
extern __attribute__((__visibility__("hidden"))) int hiddenfunc (void);
extern __attribute__((__visibility__("default"))) int exportedfunc (void);
$ xlc -c vis.c
[no error]
--
albert chin ([EMAIL PROTECTED])
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
patch for regex.m4
Hi, I'm including a patch for regex.m4. I replaced AC_TRY_RUN with AC_RUN_IFELSE and removed the use of m4_syscmd/m4_sysval. The program was wrapped in [[ ... ]] which caused an error on Mac OS/X 10.3 with recent versions of autoconf/make/libtool (2.59, 1.9.6, 1.5.8, resp.). I added AC_LANG_SOURCE to fix the error and figured I might as well make the switch to RUN_IFELSE at the same time since the docs say TRY_RUN is obsolete. I removed m4_syscmd, ..., because they were not working on either Mac OS/X or RHEL3. I tested this patch on Mac OS/X, RHEL 3 and FC3. James *** m4/regex.m4 2005-07-07 02:08:39.0 -0600 --- ../libdap/gl/m4/regex.m42005-07-25 11:59:43.0 -0600 *** *** 36,42 # test #75' in grep-2.3. AC_CACHE_CHECK([for working re_compile_pattern], [gl_cv_func_working_re_compile_pattern], ! [AC_TRY_RUN( [[ #include #include --- 36,42 # test #75' in grep-2.3. AC_CACHE_CHECK([for working re_compile_pattern], [gl_cv_func_working_re_compile_pattern], ! [AC_RUN_IFELSE(AC_LANG_SOURCE( [[ #include #include *** *** 100,118 exit (0); } !]], [gl_cv_func_working_re_compile_pattern=yes], [gl_cv_func_working_re_compile_pattern=no], dnl When crosscompiling, assume it is broken. [gl_cv_func_working_re_compile_pattern=no])]) if test $gl_cv_func_working_re_compile_pattern = yes; then ac_use_included_regex=no fi ! test -n "$1" || AC_MSG_ERROR([missing argument]) ! m4_syscmd([test -f '$1']) ! ifelse(m4_sysval, 0, ! [ AC_ARG_WITH([included-regex], [ --without-included-regex don't compile regex; this is the default on systems with recent-enough versions of the GNU C --- 100,116 exit (0); } !]]), [gl_cv_func_working_re_compile_pattern=yes], [gl_cv_func_working_re_compile_pattern=no], dnl When crosscompiling, assume it is broken. [gl_cv_func_working_re_compile_pattern=no])]) + if test $gl_cv_func_working_re_compile_pattern = yes; then ac_use_included_regex=no fi ! if test -n "$1" || AC_MSG_ERROR([missing argument]); then AC_ARG_WITH([included-regex], [ --without-included-regex don't compile regex; this is the default on systems with recent-enough versions of the GNU C *** *** 123,130 AC_LIBOBJ([regex]) gl_PREREQ_REGEX fi ! ], ! ) ] ) --- 121,129 AC_LIBOBJ([regex]) gl_PREREQ_REGEX fi ! ! fi ! ] ) begin:vcard fn:James Gallagher n:Gallagher;James org:OPeNDAP, Inc. adr;dom:Suite 202;;125 W. Granite St.;Butte;MT;59701 email;internet:[EMAIL PROTECTED] tel;work:406.723.8663 tel;home:406.494.4597 tel;cell:401.575.3296 x-mozilla-html:TRUE url:http://www.opendap.org version:2.1 end:vcard ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: control of symbols exported by shared libraries
Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> > gcc-4.0 now provides support for controlling the set of symbols exported >> > from a shared library in a reasonable, maintainable way. I have added a >> > gnulib module to this effect. With documentation, this time :-) >> >> How does this relate to something like Libtool's -export-symbols-regex >> '^(idn|pr29_|punycode_|stringprep|tld_).*'? That is what I have been >> using to control which symbols are exported or not. > > According to Ulrich Drepper's paper, > http://people.redhat.com/drepper/dsohowto.pdf, > section 2.2.6, this libtool option is just a placebo - if libtool hasn't > changed > since Ulrich looked at it. Can you let us know, by showing the output of > "nm --dynamic libidn.so"? Yes, I recall that section, although it appeared to me that a preferable approach would be to fix libtool, and I thought that had been done. Joe Orton of RedHat even asked me to use Libtool's --export-symbols-regex in GnuTLS, for instance. I have been using it all of my libraries for a long time. No non-external symbols are exported, from what I can tell. Output below. >> Your module look somewhat gcc-specific, whereas, in theory, libtool >> might work with other compilers too. > > Do you know of other compilers than GCC 4 and MSVC that support the equivalent > of "-fvisibility=hidden"? No. Thanks. U calloc U __ctype_b_loc w __cxa_finalize U __errno_location U free U getenv w __gmon_start__ U iconv U iconv_close U iconv_open 5390 T idna_strerror 4320 T idna_to_ascii_4i 49c0 T idna_to_ascii_4z 4ca0 T idna_to_ascii_8z 4d10 T idna_to_ascii_lz 4900 T idna_to_unicode_44i 4d70 T idna_to_unicode_4z4z 4f50 T idna_to_unicode_8z4z 4fc0 T idna_to_unicode_8z8z 5040 T idna_to_unicode_8zlz 50b0 T idna_to_unicode_lzlz 5360 T idn_free w _Jv_RegisterClasses U malloc U memmove U nl_langinfo 5210 T pr29_4 52d0 T pr29_4z 5310 T pr29_8z 5450 T pr29_strerror 4090 T punycode_decode 3e10 T punycode_encode 5490 T punycode_strerror U realloc U strcasecmp U strcat U strcmp U strcpy U __strdup 3ab0 T stringprep 3570 T stringprep_4i 3a50 T stringprep_4zi 3290 T stringprep_check_version 30e0 T stringprep_convert 0002f560 D stringprep_iscsi 0002cf80 R stringprep_iscsi_prohibit 0002f160 D stringprep_kerberos5 3080 T stringprep_locale_charset 3120 T stringprep_locale_to_utf8 0002f080 D stringprep_nameprep 0002f420 D stringprep_plain 3bf0 T stringprep_profile 0002f020 D stringprep_profiles 0001a880 R stringprep_rfc3454_A_1 0001cdc0 R stringprep_rfc3454_B_1 0001d060 R stringprep_rfc3454_B_2 00025100 R stringprep_rfc3454_B_3 00029fc0 R stringprep_rfc3454_C_1_1 0002a000 R stringprep_rfc3454_C_1_2 0002a1c0 R stringprep_rfc3454_C_2_1 0002a220 R stringprep_rfc3454_C_2_2 0002a3c0 R stringprep_rfc3454_C_3 0002a420 R stringprep_rfc3454_C_4 0002a600 R stringprep_rfc3454_C_5 0002a640 R stringprep_rfc3454_C_6 0002a6e0 R stringprep_rfc3454_C_7 0002a720 R stringprep_rfc3454_C_8 0002a8a0 R stringprep_rfc3454_C_9 0002a900 R stringprep_rfc3454_D_1 0002ac60 R stringprep_rfc3454_D_2 0002f660 D stringprep_saslprep 0002d5a0 R stringprep_saslprep_space_map 54e0 T stringprep_strerror 0002f4c0 D stringprep_trace 3010 T stringprep_ucs4_nfkc_normalize 2fb0 T stringprep_ucs4_to_utf8 2f90 T stringprep_unichar_to_utf8 2fe0 T stringprep_utf8_nfkc_normalize 3160 T stringprep_utf8_to_locale 2fa0 T stringprep_utf8_to_ucs4 2f80 T stringprep_utf8_to_unichar 0002f240 D stringprep_xmpp_nodeprep 0002cea0 R stringprep_xmpp_nodeprep_prohibit 0002f340 D stringprep_xmpp_resourceprep U strlen 5bf0 T tld_check_4 5b30 T tld_check_4t 5b90 T tld_check_4tz 5c90 T tld_check_4z 5cf0 T tld_check_8z 5d70 T tld_check_lz 5840 T tld_default_table 58a0 T tld_get_4 59b0 T tld_get_4z 57e0 T tld_get_table 5a10 T tld_get_z 55a0 T tld_strerror ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: control of symbols exported by shared libraries
Albert Chin wrote:
> The AIX v7 compiler compiles the following:
> $ cat vis.c
> extern __attribute__((__visibility__("hidden"))) int hiddenvar;
> extern __attribute__((__visibility__("default"))) int exportedvar;
> extern __attribute__((__visibility__("hidden"))) int hiddenfunc (void);
> extern __attribute__((__visibility__("default"))) int exportedfunc (void);
>
> $ xlc -c vis.c
> [no error]
Thanks for the info. But does it have any effect? And is there a way to make
the default visibility in a compilation be "hidden" instead of "default"?
Bruno
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: patch for regex.m4
"James Gallagher" <[EMAIL PROTECTED]> writes:
> I added AC_LANG_SOURCE to fix the error and figured I might as well
> make the switch to RUN_IFELSE at the same time since the docs say
> TRY_RUN is obsolete.
That makes sense, yes. I installed the patch below (plus some
unimportant indenting changes) into gnulib and coreutils. I took the
opportunity to fix another bug: 'exit' wasn't declared.
> I removed m4_syscmd, ..., because they were not working on either Mac
> OS/X or RHEL3.
Hmm, why not? Shouldn't they be working? What versions of m4 and Autoconf
were you using? Let's try to see what the underlying problem is first,
before removing this from regex.m4.
2005-07-25 Paul Eggert <[EMAIL PROTECTED]>
* regex.m4 (gl_INCLUDED_REGEX): Use AC_RUN_ELSE instead of the
obsolescent AC_TRY_RUN. Include the default includes files, for 'exit'.
--- regex.m47 Jul 2005 08:08:39 - 1.39
+++ regex.m425 Jul 2005 19:28:26 - 1.40
@@ -1,4 +1,4 @@
-#serial 23
+#serial 24
# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005 Free
# Software Foundation, Inc.
@@ -36,15 +36,11 @@ AC_DEFUN([gl_INCLUDED_REGEX],
# test #75' in grep-2.3.
AC_CACHE_CHECK([for working re_compile_pattern],
[gl_cv_func_working_re_compile_pattern],
- [AC_TRY_RUN(
-[[
-#include
-#include
-#include
- int
- main ()
- {
- static struct re_pattern_buffer regex;
+ [AC_RUN_IFELSE(
+[AC_LANG_PROGRAM(
+ [AC_INCLUDES_DEFAULT
+#include ],
+ [[static struct re_pattern_buffer regex;
const char *s;
struct re_registers regs;
re_set_syntax (RE_SYNTAX_POSIX_EGREP);
@@ -98,9 +94,7 @@ AC_DEFUN([gl_INCLUDED_REGEX],
if (! REG_STARTEND)
exit (1);
- exit (0);
- }
-]],
+ exit (0);]])],
[gl_cv_func_working_re_compile_pattern=yes],
[gl_cv_func_working_re_compile_pattern=no],
dnl When crosscompiling, assume it is broken.
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: patch for regex.m4
>>> I removed m4_syscmd, ..., because they were not working on either Mac >>> OS/X or RHEL3. >> >> Hmm, why not? Shouldn't they be working? What versions of m4 and >> Autoconf >> were you using? Let's try to see what the underlying problem is first, >> before removing this from regex.m4. > > Well, I have to admit, I'm not an expert at autoconf or m4... The > versions I'm using are > > autoconf: 2.59; m4: 1.4 (on Mac OS/X 10.3) > Autoconf: 2.59; m4: 1.4.1 (on RHEL 3). You should upgrade to m4 1.4.3, unless these older m4 versions have been patched heavily. > In both cases running sh -vx configure showed that these looked like > they were not doing anything at all. That is, it was as if they were > comments and the enclosed code was just eliminated. That's the expected behavior. The m4_syscmd code is executed when 'autoconf' is run, not when 'configure' is run. So it sounds like things were working correctly for you. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
tempfailure: adding TEMP_FAILURE_RETRY
This module didn't take long to write, so I thought
I'd submit it before checking if it would be accepted
or not.
It "backports" the TEMP_FAILURE_RETRY macro from
GNU Libc to Gnulib.
Regards,
Oskar Liljeblad ([EMAIL PROTECTED])
diff -u1 ChangeLog.v0 ChangeLog
--- ChangeLog.v02005-07-26 00:18:51.0 +0200
+++ ChangeLog 2005-07-26 00:19:57.0 +0200
@@ -1 +1,7 @@
+2005-07-26 Oskar Liljeblad <[EMAIL PROTECTED]>
+
+ * modules/tempfailure: New file.
+ * lib/tempfailure.h: New file.
+ * MODULES.html.sh (Misc): Add tempfailure.
+
2005-07-24 Bruno Haible <[EMAIL PROTECTED]>
diff -u /dev/null lib/tempfailure.h
--- /dev/null 2005-04-15 16:25:26.0 +0200
+++ lib/tempfailure.h 2005-07-26 00:16:30.0 +0200
@@ -0,0 +1,37 @@
+/* tempfailure.h -- define the TEMP_FAILURE_RETRY macro from GNU Libc
+
+ Copyright (C) 2005 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software Foundation,
+ Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
+
+ */
+
+#ifndef _TEMPFAILURE_H
+#define _TEMPFAILURE_H
+
+#include
+#include
+
+#ifndef TEMP_FAILURE_RETRY
+#define TEMP_FAILURE_RETRY(expression) \
+({ \
+long int _result; \
+do _result = (long int) (expression); \
+while (_result == -1L && errno == EINTR); \
+_result; \
+})
+#endif
+
+#endif
diff -u MODULES.html.sh.v0 MODULES.html.sh
--- MODULES.html.sh.v0 2005-07-26 00:17:50.0 +0200
+++ MODULES.html.sh 2005-07-26 00:18:46.0 +0200
@@ -2004,6 +2004,7 @@
func_module readutmp
func_module sig2str
func_module sysexits
+ func_module tempfailure
func_module visibility
func_end_table
}
diff -u /dev/null modules/tempfailure
--- /dev/null 2005-04-15 16:25:26.0 +0200
+++ modules/tempfailure 2005-07-26 00:10:29.0 +0200
@@ -0,0 +1,20 @@
+Description:
+Defines the TEMP_FAILURE_RETRY macro from GNU Libc.
+
+Files:
+lib/tempfailure.h
+
+Depends-on:
+
+configure.ac:
+
+Makefile.am:
+
+Include:
+"tempfailure.h"
+
+License:
+LGPL
+
+Maintainer:
+all
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: tempfailure: adding TEMP_FAILURE_RETRY
"Oskar Liljeblad" <[EMAIL PROTECTED]> writes: > It "backports" the TEMP_FAILURE_RETRY macro from > GNU Libc to Gnulib. The proposed implementation isn't portable; it assumes GCC syntax. And it should probably defer to the unistd.h implementation if available. My kneejerk reaction is that it's a bit small to be a module. In my own code, I typically write EINTR-checking code inline; it's about as readable as using TEMP_FAILURE_RETRY, and it's one less thing to explain to the reader. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: patch for regex.m4
On Jul 25, 2005, at 3:49 PM, Paul Eggert wrote: I removed m4_syscmd, ..., because they were not working on either Mac OS/X or RHEL3. Hmm, why not? Shouldn't they be working? What versions of m4 and Autoconf were you using? Let's try to see what the underlying problem is first, before removing this from regex.m4. Well, I have to admit, I'm not an expert at autoconf or m4... The versions I'm using are autoconf: 2.59; m4: 1.4 (on Mac OS/X 10.3) Autoconf: 2.59; m4: 1.4.1 (on RHEL 3). You should upgrade to m4 1.4.3, unless these older m4 versions have been patched heavily. In both cases running sh -vx configure showed that these looked like they were not doing anything at all. That is, it was as if they were comments and the enclosed code was just eliminated. That's the expected behavior. The m4_syscmd code is executed when 'autoconf' is run, not when 'configure' is run. So it sounds like things were working correctly for you. OK. I'll work that back in (or up date from CVS if you've patched my patch...) and see if an upgrade to the newest m4 fixes things. Thanks, James PS. I'm still not able to get the regex.c/h code to compile on os/x 10.3; I'll work on that as time permits as well. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib -- James Gallagherjgallagher at opendap.org OPeNDAP, Inc 406.723.8663 ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
