Re: mingw32 and sockets

[John Vandenberg]

On 9/22/05, Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Mingw32 doesn't have sys/types.h, arpa/inet.h or netinet/in.h.  But if
> you include winsock2.h instead of those three header files, most (?)
> POSIX socket functions work.

I doubt that any POSIX socket functions in winsock2 will conform to
the specification, or even reasonably reliably be useful.  There are a
number of gotchas that need to be considered. e.g. errno is not set.

plibc is a very good POSIX compatibility library for mingw, and as an
example, here is the select implementation:

http://cvs.sourceforge.net/viewcvs.py/plibc/plibc/src/select.c?view=markup

Existing modules inet_ntop, getaddrinfo and poll, and any module that
depends on those (canon-host?), appear to use these headers, but only
a small part of the socket implementation is needed; supporting those
modules on Window sounds like a good start.

> Perhaps this should be considered a mingw32 bug instead?  Problem is
> this mingw32 cross compiler will likely be around for a while, since
> it is shipped with the latest Debian release..  So it might be useful
> to support even if it is broken.

MinGW does not consider this a bug because it aims to provide a
complete and compatible Win32 API, in order that programmers can
interchange MSVC and MinGW.

http://marc.theaimsgroup.com/?t=11247268191&r=1&w=2

--
John


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: mingw32 and sockets

[Paul Eggert]

Simon Josefsson <[EMAIL PROTECTED]> writes:

> Mingw32 doesn't have sys/types.h,

Ouch.  Lots of gnulib code assumes that sys/types.h exists and works.
(The only exception is the socklen module itself.)

> Perhaps this should be considered a mingw32 bug instead?

I would.  Google reports that other mingw32 users have ,
e.g., see .

With Debian, the mingw32 sys/types.h is part of the mingw32-runtime
package; you can't really cross-compile without it.


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

mingw32 and sockets

[Simon Josefsson]

Mingw32 doesn't have sys/types.h, arpa/inet.h or netinet/in.h.  But if
you include winsock2.h instead of those three header files, most (?)
POSIX socket functions work.

The simplest solutions would be to replace:

#include 
#include 
#include 

with:

#include "glsocket.h"

or something, and glsocket.h does the right thing.  But I don't like
that, including the POSIX headers in my application is more readable.

Would it be possible to create those three POSIX header files if they
don't exist on the system, and if winsock2.h do exist?  The created
files would simply #include .  Creating them would be done
like getopt_.h and others.  The complication is that this has to be
done in a sub-directory somehow, so that #include for sys/socket.h
works.

What do you think?

Perhaps this should be considered a mingw32 bug instead?  Problem is
this mingw32 cross compiler will likely be around for a while, since
it is shipped with the latest Debian release..  So it might be useful
to support even if it is broken.

Thanks,
Simon


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [PATCH] Re: wctype.h and wchar.h inclusion

[Paul Eggert]

Derek Price <[EMAIL PROTECTED]> writes:

> 2005-09-20  Yoann Vandoorselaere  <[EMAIL PROTECTED]>
> Derek Price  <[EMAIL PROTECTED]>
>
> * m4/mbchar.m4 (gl_MBCHAR): Check for wchar.h & wctype.h, compiling
> mbchar.c only when present.
> * modules/mbchar (lib_SOURCES): Remove mbchar.c.

That looks fine to me -- I don't know of any reason Bruno wouldn't
like it.  Bruno, have you had a chance to look at it?  If not, perhaps
we should wait a week or two and then install it.


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: regcomp.c Windows warning

[Paul Eggert]

Derek Price <[EMAIL PROTECTED]> writes:

> I assume that, since "strcase.h" provides a prototype for strcasecmp,
> other systems have a similar problem and regcomp.c should probably be
> #including "strcase.h".

Yes.  I'm preparing a patch to do that, except it'll be in regex_internal.h
since it's the file that includes .  I'm planning to add this:

#ifndef _LIBC
# include "strcase.h"
#endif

and modify the module file accordingly.

There's some other gnulib changes coming too; it's part of the merge
from coreutils.


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: unicodeio.c: accidental extern function: unicode_to_mb

[Bruno Haible]

Hi Jim,

Jim Meyering wrote:
> Since unicode_to_mb is not declared in any other file
> that I can see, nor is it used elsewhere in gnulib,
> I suspect it really should have file scope.

No. On the contrary. The declaration is missing in unicodeio.h.

I didn't write this function with two callback arguments, just for the case
when used to print to a stdio stream. The function unicode_to_mb is used
in tar-1.13.25. Also it would make no sense to declare fwrite_success_callback()
in unicodeio.h without declaring unicode_to_mb.

Groveling in cvs logs, I can see that tar-1.13.25's unicodeio.h had the
declaration in unicodeio.h. On its way from tar to coreutils, the
declaration was apparently lost. Later, when gnulib was created, the file
came from coreutils.

I have added the missing declaration now.

Bruno


*** unicodeio.h 14 May 2005 06:03:58 -  1.7
--- unicodeio.h 21 Sep 2005 19:32:03 -
***
*** 1,6 
  /* Unicode character output to streams with locale dependent encoding.
  
!Copyright (C) 2000-2003 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
--- 1,6 
  /* Unicode character output to streams with locale dependent encoding.
  
!Copyright (C) 2000-2003, 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
***
*** 21,26 
--- 21,39 
  
  # include 
  # include 
+ 
+ /* Converts the Unicode character CODE to its multibyte representation
+in the current locale and calls the SUCCESS callback on the resulting
+byte sequence.  If an error occurs, invokes the FAILURE callback instead,
+passing it CODE and an English error string.
+Returns whatever the callback returned.
+Assumes that the locale doesn't change between two calls.  */
+ extern long unicode_to_mb (unsigned int code,
+  long (*success) (const char *buf, size_t buflen,
+   void *callback_arg),
+  long (*failure) (unsigned int code, const char *msg,
+   void *callback_arg),
+  void *callback_arg);
  
  /* Outputs the Unicode character CODE to the output stream STREAM.
 Upon failure, exit if exit_on_error is true, otherwise output a fallback



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

unicodeio.c: accidental extern function: unicode_to_mb

[Jim Meyering]

Hi Bruno,

Since unicode_to_mb is not declared in any other file
that I can see, nor is it used elsewhere in gnulib,
I suspect it really should have file scope.

Here's a patch:

Index: unicodeio.c
===
RCS file: /fetish/cu/lib/unicodeio.c,v
retrieving revision 1.23
diff -u -p -r1.23 unicodeio.c
--- unicodeio.c 14 May 2005 07:58:07 -  1.23
+++ unicodeio.c 21 Aug 2005 15:55:33 -
@@ -115,7 +115,7 @@ utf8_wctomb (unsigned char *r, unsigned
passing it CODE and an English error string.
Returns whatever the callback returned.
Assumes that the locale doesn't change between two calls.  */
-long
+static long
 unicode_to_mb (unsigned int code,
   long (*success) (const char *buf, size_t buflen,
void *callback_arg),


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: config.h inclusion

[Ralf Wildenhues]

Hi Paul, Bruno,

* Paul Eggert wrote on Mon, Sep 19, 2005 at 07:31:27PM CEST:
> 
> Since there was general agreement I installed all the
> patches, except for the following files:
> 
> mkdtemp.c
> setenv.c
> unsetenv.c
> 
> argp-eexst.c
> argp-fmtstream.c
> argp-fmtstream.h
> argp-fs-xinl.c
> argp-xinl.c
> 
> The first group of three is taken unaltered from GNU gettext.  Bruno,
> can you please look into patching them along the lines of Ralf's patch
> ?

For convenience, I have pasted below a patch to this extent.

> The last group of five files is taken directly from libc.  Ralf, can
> you please submit them as a glibc patch?

Done: http://sources.redhat.com/ml/libc-alpha/2005-09/msg00069.html

For your reference: the (Libtool-owned) argz.c file has been updated as
well similarly, but to also work with the libltdl special-casing, and
Noah's comment has been addressed.

Cheers, and thanks for applying these,
Ralf

2005-09-21  Ralf Wildenhues  <[EMAIL PROTECTED]>  (tiny change)

* mkdtemp.c, setenv.c, unsetenv.c: Standardize inclusion of
config.h.

Index: lib/mkdtemp.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/mkdtemp.c,v
retrieving revision 1.4
diff -u -r1.4 mkdtemp.c
--- lib/mkdtemp.c   14 May 2005 06:03:58 -  1.4
+++ lib/mkdtemp.c   20 Sep 2005 08:15:44 -
@@ -18,7 +18,7 @@
 /* Extracted from misc/mkdtemp.c and sysdeps/posix/tempname.c.  */
 
 #ifdef HAVE_CONFIG_H
-# include "config.h"
+# include 
 #endif
 
 /* Specification.  */
Index: lib/setenv.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/setenv.c,v
retrieving revision 1.13
diff -u -r1.13 setenv.c
--- lib/setenv.c14 May 2005 06:03:58 -  1.13
+++ lib/setenv.c20 Sep 2005 08:15:44 -
@@ -15,7 +15,7 @@
with this program; if not, write to the Free Software Foundation,
Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.  */
 
-#if HAVE_CONFIG_H
+#ifdef HAVE_CONFIG_H
 # include 
 #endif
 #include 
Index: lib/unsetenv.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/unsetenv.c,v
retrieving revision 1.5
diff -u -r1.5 unsetenv.c
--- lib/unsetenv.c  14 May 2005 06:03:58 -  1.5
+++ lib/unsetenv.c  20 Sep 2005 08:15:44 -
@@ -15,7 +15,7 @@
with this program; if not, write to the Free Software Foundation,
Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.  */
 
-#if HAVE_CONFIG_H
+#ifdef HAVE_CONFIG_H
 # include 
 #endif
 


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: regex-0.12's regex.h seems to have a little bug

[Simon Josefsson]

Stepan Kasal <[EMAIL PROTECTED]> writes:

> Hi,
>   I don't say I'm excited about the AC_LIBSOURCE macro, ...

To understand what I'm writing below: I think AC_LIBSOURCE probably is
the right solution, but it would have been nice to introduce it after
the autoconf/automake/libtool/m4 releases had happened.  Then we would
have avoided the conflict with existing use of AC_LIBOBJ and
AC_REPLACE_FUNCS.  Requiring modern tools for gnulib users is probably
ok, but requiring unreleased cvs releases probably is not.

> On Wed, Sep 21, 2005 at 11:02:24AM +0200, Simon Josefsson wrote:
>> I'm not sure what the supposed advantage with
>> AC_LIBSOURCES was compared to the old scheme.
>
> ... but I think I do remember what was the advantage:
>
> Imagine that a new file baz.c is added to a module.
> Then it is possible that you upgrade the existing files, including
> the m4 file which checks whether baz.c is needed, but that you forget
> to copy the new file, or you forget to add it to the list of distributed
> files.
>
> With the old scheme, the bug would be detected only on platforms where
> baz.c is needed.  Typically, the developper uses a variant of GNU system,
> so most of the replacements are not needed; so the bug is not detected
> on his platform.
>
> With the AC_LIBSOURCES, Automake uses traces to obtain the list of
> distributed files, so we are sure that baz.c will be distributed.
> (And if it wasn't copied into the project, Automake will complain on
> every platform, no matter whether the file would be actually built there.)
>
> Yes, you might object that the mistake described above will not happen
> when people use gnulib-tool.

Right.

> But:
> - with the old scheme, the module maintainer had to add the file to the
>   module description, _twice_: to the file list and to the
>   lib_SOURCES variable in Makefile.am section.

Module maintainers always has to do the right thing.  This potential
mistake is possible to detect through a script, so if this was a
genuine problem in the old scheme, we could write that script.

> - with the new scheme you only add something like
>   if test "$baz_works" != yes; then
>   AC_LIBOBJ([baz])
>   fi
>   and it expands to AC_LIBSOURCE([baz.c]) which is traced by Automake.

This doesn't seem like a huge improvement.

> Please note that almost always you need to add a check for the feature
> anyway, so the code required by the new scheme presents almost no overhead,
> and, more importantly, the risk that you forget to add it is minimal.

Problem is, the new scheme causes real problems if you used AC_LIBOBJ
or AC_REPLACE_FUNCS before, and put the LTLIBOBJ in another directory
than the gnulib files.

Regards,
Simon


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: regex-0.12's regex.h seems to have a little bug

[Bruno Haible]

Simon Josefsson wrote:
> If you invoke the tool as:
>
> gnulib-tool --create-testdir --dir=/tmp/testdir regex
>
> It will create an entire new project in /tmp/testdir for the regex
> module.  Then you can run it again:
>
> cd /tmp/testdir
> gnulib-tool --import --lgpl regex
>
> After that, you have the sources in lib/ and the required M4 macros in
> gl/.  You can copy them somewhere else, but you should call gl_EARLY
> early in configure.ac, and gl_INIT later on in your configure.ac.

Additionally, if you really don't want the autogenerated Makefile.am's,
you can use the low-level accessors that gnulib-tool offers, namely

  gnulib-tool --extract-filelist regex
  gnulib-tool --extract-dependencies regex
  gnulib-tool --extract-autoconf-snippet regex
  gnulib-tool --extract-automake-snippet regex

and integrate them in your package the way it fits you best.

> > Julien PUYDT <[EMAIL PROTECTED]> writes:
> >> I just need a posix regex library. Gnulib-tool doesn't seem to
> >> permit to just get the sources.

gnulib no longer provides just *.h and *.c files. It also provides
accompanying *.m4 files, an autoconf snippet, and an automake snippet,
for each module. If you don't use the *.m4 files, the autoconf snippet,
and the automake snippet, you are very likely to encounter problems.
The whole thing - *.h and *.c files, *.m4 files, autoconf snippet, and
automake snippet - were designed to fit together.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: regex-0.12's regex.h seems to have a little bug

[Stepan Kasal]

Hi,
  I don't say I'm excited about the AC_LIBSOURCE macro, ...

On Wed, Sep 21, 2005 at 11:02:24AM +0200, Simon Josefsson wrote:
> I'm not sure what the supposed advantage with
> AC_LIBSOURCES was compared to the old scheme.

... but I think I do remember what was the advantage:

Imagine that a new file baz.c is added to a module.
Then it is possible that you upgrade the existing files, including
the m4 file which checks whether baz.c is needed, but that you forget
to copy the new file, or you forget to add it to the list of distributed
files.

With the old scheme, the bug would be detected only on platforms where
baz.c is needed.  Typically, the developper uses a variant of GNU system,
so most of the replacements are not needed; so the bug is not detected
on his platform.

With the AC_LIBSOURCES, Automake uses traces to obtain the list of
distributed files, so we are sure that baz.c will be distributed.
(And if it wasn't copied into the project, Automake will complain on
every platform, no matter whether the file would be actually built there.)

Yes, you might object that the mistake described above will not happen
when people use gnulib-tool.  But:
- with the old scheme, the module maintainer had to add the file to the
  module description, _twice_: to the file list and to the
  lib_SOURCES variable in Makefile.am section.
- with the new scheme you only add something like
if test "$baz_works" != yes; then
AC_LIBOBJ([baz])
fi
  and it expands to AC_LIBSOURCE([baz.c]) which is traced by Automake.


Please note that almost always you need to add a check for the feature
anyway, so the code required by the new scheme presents almost no overhead,
and, more importantly, the risk that you forget to add it is minimal.

So that's it.

Stepan Kasal


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: regex-0.12's regex.h seems to have a little bug

[Simon Josefsson]

Paul Eggert <[EMAIL PROTECTED]> writes:

> Julien PUYDT <[EMAIL PROTECTED]> writes:
>> Paul Eggert a écrit :
>>> Julien PUYDT <[EMAIL PROTECTED]> writes:
Stepan Kasal a écrit :
>I suggest that you get the files from gnulib CVS on savannah.
Those are GPL and not LGPL ;
>>> No, they can be released under either the GPL or the LGPL.
>>> If you use gnulib-tool to obtain that source code, it turns the
>>> copyright notice into LGPL for you automatically.
>> Hmmm... gnulib-tool wants to install it in a project -- which I don't
>> want : I just need a posix regex library. Gnulib-tool doesn't seem to
>> permit to just get the sources.
>
> I'll CC: this to bug-gnulib to see if the gnulib-tool experts can
> help out on here.

If you invoke the tool as:

gnulib-tool --create-testdir --dir=/tmp/testdir regex

It will create an entire new project in /tmp/testdir for the regex
module.  Then you can run it again:

cd /tmp/testdir
gnulib-tool --import --lgpl regex

After that, you have the sources in lib/ and the required M4 macros in
gl/.  You can copy them somewhere else, but you should call gl_EARLY
early in configure.ac, and gl_INIT later on in your configure.ac.

Due to the use of AC_LIBSOURCES, you cannot use AC_LIBOBJ or
AC_REPLACE_FUNCS in your project, unless you put the regex library in
the same directory where you put your @[EMAIL PROTECTED]  Placing gnulib
files in a directory with other files is not the typical way to use
gnulib, but your usage already appear to be non-typical.  I agree with
Bruno that the consequences of AC_LIBSOURCES is serious flaw in gnulib
currently.  Hopefully it can be fixed with newer m4/automake/libtool
(I forget which newer versions were needed, they depended on each
other somehow).  I'm not sure what the supposed advantage with
AC_LIBSOURCES was compared to the old scheme.

Using gnulib modules without autoconf is not supported, as far as I
know.

Hope this helps,
Simon


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib