Re: gethostname on 64-bit Windows

[John W. Eaton]

On 06/24/2016 11:01 PM, Tatsuro MATSUOKA wrote:



- Original Message -

From: John W. Eaton 
To: gnulib 
Cc: j...@octave.org
Date: 2016/6/25, Sat 04:46
Subject: gethostname on 64-bit Windows

I needed the attached change to cross compile Octave for i686-w64-mingw32.

Without it, rpl_gethostname was undefined because w64 has a gethostname function
so gethostname.c is not added to the list of files to build but gethostname was
still being redefined to rpl_gethostname.

jwe




gethostname on 64-bit Windows



I needed the attached change to cross compile Octave for i686-w64-mingw32.



This is not related to your patch.

The hostname Mingw w64 64 bit is x86_64-w64-mingw32.
The hostname Mingw w64 32 bit is i686-w64-mingw32.


Sorry, I copied the wrong system ID into the message.  It should have been:

  x86_64-w64-mingw32

I was cross compiling to x86_64-w64-mingw32, which appears to have a 
gethostname function (HAVE_GETHOSTNAME is defined to 1) but without my 
patch, the code in gnulib's unistd.in.h file will define gethostname to 
rpl_gethostname, and gethostname is not added to gl_LIBOBJS and 
gl_LTLIBOBJS.  I think it is sufficient to just avoid the #define in 
this case.


jwe

Re: gethostname on 64-bit Windows

[Tatsuro MATSUOKA]

- Original Message -
> From: John W. Eaton 
> To: gnulib 
> Cc: j...@octave.org
> Date: 2016/6/25, Sat 04:46
> Subject: gethostname on 64-bit Windows
> 
> I needed the attached change to cross compile Octave for i686-w64-mingw32.
> 
> Without it, rpl_gethostname was undefined because w64 has a gethostname 
> function 
> so gethostname.c is not added to the list of files to build but gethostname 
> was 
> still being redefined to rpl_gethostname.
> 
> jwe


> gethostname on 64-bit Windows

> I needed the attached change to cross compile Octave for i686-w64-mingw32.


This is not related to your patch.

The hostname Mingw w64 64 bit is x86_64-w64-mingw32.
The hostname Mingw w64 32 bit is i686-w64-mingw32.

Tatsuro

RE: gethostname on HP-NonStop

[Joachim Schmitz]

Thanks, that should do, I'll test

-Original Message-
From: Bruno Haible [mailto:br...@clisp.org] 
Sent: Friday, December 24, 2010 4:41 PM
To: Joachim Schmitz
Cc: bug-gnulib@gnu.org
Subject: Re: gethostname on HP-NonStop

Joachim Schmitz wrote:
 diff -u ./gllib/unistd.in.h.orig ./gllib/unistd.in.h
 --- ./gllib/unistd.in.h.orig2010-12-20 19:57:37.0 -0600
 +++ ./gllib/unistd.in.h 2010-12-23 07:57:13.0 -0600
 @@ -51,6 +51,14 @@
  # undef _GL_INCLUDING_WINSOCK2_H
  #endif
 
 +#ifdef __TANDEM /* HP-Nonstop has gethostname() in netdb.h */ 
 +#include netdb.h
 +/* and MAXHOSTNAMELEN in arpa/namser.h */ #include arpa/nameser.h 
 +#undef HOST_NAME_MAX #define HOST_NAME_MAX MAXHOSTNAMELEN #endif

This goes in the right direction. HOST_NAME_MAX already being dealt with, this 
is what I'm committing:


2010-12-24  Bruno Haible  br...@clisp.org

gethostname: Ensure declaration on NonStop Kernel.
* lib/unistd.in.h: Include netdb.h also on NonStop Kernel systems.
Reported by Joachim Schmitz j...@schmitz-digital.de.

--- lib/unistd.in.h.origFri Dec 24 16:37:08 2010
+++ lib/unistd.in.h Fri Dec 24 16:36:38 2010
@@ -88,9 +88,11 @@
 # include io.h
 #endif
 
-/* AIX and OSF/1 5.1 declare getdomainname in netdb.h, not in unistd.h.  */
+/* AIX and OSF/1 5.1 declare getdomainname in netdb.h, not in unistd.h.
+   NonStop Kernel declares gethostname in netdb.h, not in unistd.h.  
+*/
 /* But avoid namespace pollution on glibc systems.  */ -#if 
@GNULIB_GETDOMAINNAME@  (defined _AIX || defined __osf__) \
+#if ((@GNULIB_GETDOMAINNAME@  (defined _AIX || defined __osf__)) \
+ || (@GNULIB_GETHOSTNAME@  defined __TANDEM)) \
  !defined __GLIBC__
 # include netdb.h
 #endif

Re: gethostname on HP-NonStop

[Bruno Haible]

Joachim Schmitz wrote:
 gethostname missing (resp. not found, it is available and declared in 
 netdb.h), in various places. I added it to gllib/unistd.in.h
 source='test-fcntl-h-c++.cc' object='test-fcntl-h-c++.o' libtool=no  
 DEPDIR=.deps depmode=none /bin/sh ./../build-aux/depcomp  c++ -DHAVE_CONFIG_H 
 -I.   -DGNULIB_STRICT_CHECKING=1  -I. -I.  -I.. -I./..  -I../gllib 
 -I./../gllib -I/usr/local/include  -Wnowarn -c -o test-fcntl-h-c++.o 
 test-fcntl-h-c++.cc
   _GL_CXXALIAS_SYS_CAST (gethostname, int, (char *name, size_t len));
   ^
 /usr/local/Floss/gnulib/testdir-posix/gltests/./../gllib/unistd.h, line 
 972: error(363):
           the global scope has no gethostname

gethostname ought to be declared in unistd.h, not in netdb.h.

Reference:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/gethostname.html

Bruno

RE: gethostname on HP-NonStop

[Joachim Schmitz]

Oh well, it is not here. So some kind of workaround is needed.

-Original Message-
From: Bruno Haible [mailto:br...@clisp.org] 
Sent: Thursday, December 23, 2010 1:43 PM
To: Joachim Schmitz
Cc: bug-gnulib@gnu.org
Subject: Re: gethostname on HP-NonStop

Joachim Schmitz wrote:
 gethostname missing (resp. not found, it is available and declared in 
 netdb.h), in various places. I added it to gllib/unistd.in.h 
 source='test-fcntl-h-c++.cc' object='test-fcntl-h-c++.o' libtool=no  
 DEPDIR=.deps depmode=none /bin/sh ./../build-aux/depcomp  c++ 
 -DHAVE_CONFIG_H -I.   -DGNULIB_STRICT_CHECKING=1  -I. -I.  -I.. -I./..  
 -I../gllib -I./../gllib -I/usr/local/include  -Wnowarn -c -o 
 test-fcntl-h-c++.o test-fcntl-h-c++.cc
   _GL_CXXALIAS_SYS_CAST (gethostname, int, (char *name, size_t len));
   ^
 /usr/local/Floss/gnulib/testdir-posix/gltests/./../gllib/unistd.h, line 
 972: error(363):
   the global scope has no gethostname

gethostname ought to be declared in unistd.h, not in netdb.h.

Reference:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/gethostname.html

Bruno

Re: gethostname on Windows

[Simon Josefsson]

Bruno Haible br...@clisp.org writes:

 You are right. In summary:

- GetComputerNameEx(ComputerNameDnsHostname,...) returns the right 
 hostname,
  but it hard to use portably:
- It requires defining _WIN32_WINNT to at least 0x0500.
- With mingw, it also requires
  #define GetComputerNameEx GetComputerNameExA.
- With older versions of mingw, none of the declarations are present at
  all, not even of the enum value ComputerNameDnsHostname.
- GetComputerName() does not return the right kind of hostname.
- gethostname() requires linking with -lws2_32.

 I'm now convinced that linking with -lws2_32 is the least evil.
 I have applied your patch from 2009-03-31.

Great, thanks.  I fixed a minor typo in the comment and pushed that.

/Simon

Re: gethostname, socket need startup code

[Simon Josefsson]

Bruno Haible br...@clisp.org writes:

 Hi Simon,

 On mingw, the gethostname test fails for me:

   gethostname failed, rc -1 errno 10093
   FAIL: test-gethostname.exe

 The reason is that the WSAStartup function has not been called. Why not make
 this initialization implicitly in the gethostname function? And likewise for
 the socket() function? With that, the unit tests (test-select.c and 
 test-poll.c)
 don't need to do this initialization explicitly any more. One less portability
 problem when porting to mingw.

 Here are two proposed patches. I verified that the behaviour of test-select
 and test-poll does not change, and it fixes the gethostname failure.

Looks fine to me, please push it.

/Simon

Re: gethostname, socket need startup code

[Bruno Haible]

Simon Josefsson wrote:
 Looks fine to me, please push it.

Pushed.

Likewise, the 'sys_utsname' and 'uname' modules are pushed as well.

Bruno

Re: gethostname on Windows

[Bruno Haible]

Simon Josefsson wrote:
  I'm undecided.
 
 Avoiding -lws2_32 is good, but if the application links to -lws2_32
 anyway, there will be no saving.
 ...
 Some additional questions:
 
 1) How do I use it?  This doesn't seem to work:
 
 j...@mocca:~$ cat foo.c
 #define WINVER 0x0500
 #include windows.h
 #include stdio.h
 int main () {
   char out[1024];
   DWORD size = 1024;
   BOOL t = GetComputerNameEx(ComputerNameDnsHostname, out, size);
   printf(hi %d: %s, t, out);
 }
 j...@mocca:~$ i586-mingw32msvc-gcc -o foo.exe foo.c 
 /tmp/ccDXn2yi.o:foo.c:(.text+0x37): undefined reference to 
 `_GetComputerNameEx'
 collect2: ld returned 1 exit status
 j...@mocca:~$ 

 2) What is the maximum string size that GetComputerNameEx can return?
For the gethostname, the max size is documented.
 
 3) Is the GetComputerNameEx semantics right?

You are right. In summary:

   - GetComputerNameEx(ComputerNameDnsHostname,...) returns the right hostname,
 but it hard to use portably:
   - It requires defining _WIN32_WINNT to at least 0x0500.
   - With mingw, it also requires
 #define GetComputerNameEx GetComputerNameExA.
   - With older versions of mingw, none of the declarations are present at
 all, not even of the enum value ComputerNameDnsHostname.
   - GetComputerName() does not return the right kind of hostname.
   - gethostname() requires linking with -lws2_32.

I'm now convinced that linking with -lws2_32 is the least evil.
I have applied your patch from 2009-03-31.

Also, I'm fixing the handling of len  INT_MAX.


2009-08-02  Bruno Haible  br...@clisp.org

* lib/gethostname.c (gethostname): Fix handling of large len argument.
Add comments.

--- lib/gethostname.c.orig  2009-08-02 12:02:00.0 +0200
+++ lib/gethostname.c   2009-08-02 11:59:12.0 +0200
@@ -21,6 +21,7 @@
 #include config.h
 
 #if !((defined _WIN32 || defined __WIN32__)  !defined __CYGWIN__)
+/* Unix API.  */
 
 /* Specification.  */
 #include unistd.h
@@ -59,6 +60,17 @@
 }
 
 #else
+/* Native Windows API.  Which primitive to choose?
+   - gethostname() requires linking with -lws2_32.
+   - GetComputerName() does not return the right kind of hostname.
+   - GetComputerNameEx(ComputerNameDnsHostname,...) returns the right hostname,
+ but it hard to use portably:
+   - It requires defining _WIN32_WINNT to at least 0x0500.
+   - With mingw, it also requires
+ #define GetComputerNameEx GetComputerNameExA.
+   - With older versions of mingw, none of the declarations are present at
+ all, not even of the enum value ComputerNameDnsHostname.
+   So we use gethostname().  Linking with -lws2_32 is the least evil.  */
 
 #define WIN32_LEAN_AND_MEAN
 /* Get winsock2.h. */
@@ -70,9 +82,13 @@
 #undef gethostname
 
 int
-rpl_gethostname (char *name, size_t namelen)
+rpl_gethostname (char *name, size_t len)
 {
-  int r = gethostname (name, (int) namelen);
+  int r;
+
+  if (len  INT_MAX)
+len = INT_MAX;
+  r = gethostname (name, (int) len);
   if (r  0)
 set_winsock_errno ();
 

Re: gethostname, socket need startup code

[Bruno Haible]

Paolo Bonzini wrote:
 I'm wondering if some programs out there used WSAStartup autonomously 
 without going through the sockets module...

That would not hurt. WSAStartup succeeds when called repeatedly, even
when called with different version numbers:

$ cat foo.c
#include winsock2.h
#include ws2tcpip.h
#include stdio.h
int main()
{
  WSADATA data;
  int err;

  err = WSAStartup (0x101, data);
  printf (%d\n, err);
  err = WSAStartup (0x101, data);
  printf (%d\n, err);
  err = WSAStartup (0x201, data);
  printf (%d\n, err);
  err = WSAStartup (0x101, data);
  printf (%d\n, err);
  return 0;
}

$ gcc -mno-cygwin foo.c -lws2_32

$ ./a.exe 
0
0
0
0


Bruno

Re: gethostname on Windows

[Bruno Haible]

Martin Lambers wrote:
 This requires to include limits.h in gethostname.c, to get INT_MAX.
 
 Martin
 
 
 diff --git a/lib/gethostname.c b/lib/gethostname.c
 index ef58a40..422184a 100644
 --- a/lib/gethostname.c
 +++ b/lib/gethostname.c
 @@ -76,6 +76,9 @@ gethostname (char *name, size_t len)
  /* Get winsock2.h. */
  #include unistd.h
  
 +/* Get INT_MAX. */
 +#include limits.h
 +
  /* Get set_winsock_errno. */
  #include w32sock.h

Oops, you're right. Thanks. Applied.

Bruno

Re: gethostname, socket need startup code

[Paolo Bonzini]

Good.  No one asks worse than 1.1 so the patch is okay.

Paolo

Re: gethostname inadvertently replaced on W32

[Simon Josefsson]

Martin Lambers mar...@marlam.de writes:

 On Tue, 28. Jul 2009, 23:18:09 +0200, Simon Josefsson wrote:
 OTOH, I haven't tested whether my old patch still works.  Martin, have
 you?

 It applied cleanly (except for the ChangeLog entry) and I tested it on
 Debian lenny and with a MinGW cross compiler. This time I built from
 scratch, to avoid my earlier errors. The resulting W32 binary was also
 tested on Windows XP. So yes, it still works.

Great.  Bruno, any objections to pushing the old patch?

/Simon

Re: gethostname inadvertently replaced on W32

[Martin Lambers]

On Tue, Jul 28, 2009 at 10:08:34AM +0200, Martin Lambers wrote:
 The following patch fixes this for me.

Sorry, this is not true (I forgot to 'make clean' and did not see this
earlier). The unistd.h header from gnulib defines gethostname to
rpl_gethostname, but no such function is available, and this leads to a
linker error. I do not know how to fix these unistd.h related things;
for now I'm just using '--avoid gethostname'.

Martin

Re: gethostname inadvertently replaced on W32

[Martin Lambers]

Hello again,

I just noticed that this problem was already found and fixed by Simon in
March: http://www.mail-archive.com/bug-gnulib@gnu.org/msg13671.html

There was some discussion about the right approach, but no decision was
made.

Bruno, Simon, would you please reconsider applying the patch? Without
it, the gethostname module is broken on W32.

Regards,
Martin

Re: gethostname inadvertently replaced on W32

[Simon Josefsson]

Martin Lambers mar...@marlam.de writes:

 Hello again,

 I just noticed that this problem was already found and fixed by Simon in
 March: http://www.mail-archive.com/bug-gnulib@gnu.org/msg13671.html

 There was some discussion about the right approach, but no decision was
 made.

 Bruno, Simon, would you please reconsider applying the patch? Without
 it, the gethostname module is broken on W32.

Re-reading that thread, I think my patch is a reasonable way forward.
Avoiding linking to -lws2_32 is nice, but using GetComputerNameEx has
some issues (see my third e-mail in that thread) and ultimately it
doesn't seem worth it.

I propose we push my initial patch, and if Bruno feels strongly about
providing a gethostname function that works better under Windows,
without -lws2_32, that can be provided in a separate module (e.g.,
gethostname-lean).  Objections?

OTOH, I haven't tested whether my old patch still works.  Martin, have
you?

/Simon

Re: gethostname inadvertently replaced on W32

[Martin Lambers]

On Tue, 28. Jul 2009, 23:18:09 +0200, Simon Josefsson wrote:
 OTOH, I haven't tested whether my old patch still works.  Martin, have
 you?

It applied cleanly (except for the ChangeLog entry) and I tested it on
Debian lenny and with a MinGW cross compiler. This time I built from
scratch, to avoid my earlier errors. The resulting W32 binary was also
tested on Windows XP. So yes, it still works.

Martin

Re: gethostname on Windows

[Simon Josefsson]

Bruno Haible br...@clisp.org writes:

 Simon Josefsson wrote:
 The current gethostname module will return an empty string on mingw:
 
   strcpy (name, ); /* Hardcode your system name if you want.  */
 
 This is sub-optimal since Windows has a gethostname function in
 -lws2_32.
 
 The following patch should make gethostname return proper values.
 Tested on x86 debian lenny and mingw cross-compile.  Any objections to
 installing it?

 Well, I don't much like the dependency on an external library for the
 modules 'gethostname' and 'uname' (later, when we get an 'uname' module).

 I did some experiments with the GetComputerNameEx function [1], which is
 present in kernel32.dll. The parameters ComputerNameDnsHostname and
 ComputerNamePhysicalDnsHostname returned the same value as gethostname()
 for me, except that gethostname() returns a lowercased result (which can
 be simulated in 3 lines of code).

 OTOH, the gethostname() in -lws2_32 is a Unixy API, and it seems idiotic
 want to use a Windozy API instead.

 I'm undecided.

Avoiding -lws2_32 is good, but if the application links to -lws2_32
anyway, there will be no saving.

Maybe the gethostname module could detect this?  I.e., if the gnulib
module sys_sockets_h is also used, so the application is likely to link
to ws2_32 anyway, it can use -lws2_32 otherwise it will fall back on
GetComputerNameEx.  I'm not sure how to implement a M4 test like that
though?

Anyway, that solution isn't very reliable: you may want to use
gethostname in an application that doesn't use sockets otherwise.  Maybe
two different gnulib modules then?  gethostname uses -lws2_32 and
gethostname-lean uses GetComputerNameEx?

Some additional questions:

1) How do I use it?  This doesn't seem to work:

j...@mocca:~$ cat foo.c
#define WINVER 0x0500
#include windows.h
#include stdio.h
int main () {
  char out[1024];
  DWORD size = 1024;
  BOOL t = GetComputerNameEx(ComputerNameDnsHostname, out, size);
  printf(hi %d: %s, t, out);
}
j...@mocca:~$ i586-mingw32msvc-gcc -o foo.exe foo.c 
/tmp/ccDXn2yi.o:foo.c:(.text+0x37): undefined reference to `_GetComputerNameEx'
collect2: ld returned 1 exit status
j...@mocca:~$ 

2) What is the maximum string size that GetComputerNameEx can return?
   For the gethostname, the max size is documented.

3) Is the GetComputerNameEx semantics right?  It seems the gethostname
   result will be different in some configurations?  I'm not sure how
   important that is, but for gss/shishi the use of gethostname is to
   derive a Kerberos V5 principal name so there could be security
   implications if the value is not right.

/Simon

Re: gethostname on Windows

[Simon Josefsson]

I managed to rewrite the code in GSS to not need the gethostname
function at all, so I don't care strongly about the patch to make
gethostname work under mingw anymore.  My initial patch could be used,
but Bruno's concern about linking to -lws2_32 may be a reason against.

/Simon

Re: gethostname on Windows

[Bruno Haible]

Simon Josefsson wrote:
 The current gethostname module will return an empty string on mingw:
 
   strcpy (name, );  /* Hardcode your system name if you want.  */
 
 This is sub-optimal since Windows has a gethostname function in
 -lws2_32.
 
 The following patch should make gethostname return proper values.
 Tested on x86 debian lenny and mingw cross-compile.  Any objections to
 installing it?

Well, I don't much like the dependency on an external library for the
modules 'gethostname' and 'uname' (later, when we get an 'uname' module).

I did some experiments with the GetComputerNameEx function [1], which is
present in kernel32.dll. The parameters ComputerNameDnsHostname and
ComputerNamePhysicalDnsHostname returned the same value as gethostname()
for me, except that gethostname() returns a lowercased result (which can
be simulated in 3 lines of code).

OTOH, the gethostname() in -lws2_32 is a Unixy API, and it seems idiotic
want to use a Windozy API instead.

I'm undecided.

Bruno

[1] http://msdn.microsoft.com/en-us/library/ms724301(VS.85).aspx

Re: gethostname: LGPL - LGPLv2+

[Simon Josefsson]

Jim Meyering [EMAIL PROTECTED] writes:

 I'd like to use the gethostname module in libvirt (LGPLv2+),
 for use when building for mingw.

 Considering the size of the module (trivial, 10-line gethostname function
 and minimal gethostname.m4), would anyone object to relaxing its license
 from LGPL to LGPLv2+?

 This is mainly to avoid gnulib's link-time warning:

   ...: undefined reference to [EMAIL PROTECTED]'

 In this particular case, gethostname is essentially a no-op,
 and always returns the empty string, since mingw
 has no uname function, and in that case, gethostname's
 body reverts to this:

 strcpy (name, );/* Hardcode your system name if you want.  
 */

FWIW, I think it would be useful to have it as LGPLv2+ as well.

/Simon

Re: gethostname: LGPL - LGPLv2+

[Jim Meyering]

Jim Meyering [EMAIL PROTECTED] wrote:
 I'd like to use the gethostname module in libvirt (LGPLv2+),
 for use when building for mingw.

 Considering the size of the module (trivial, 10-line gethostname function
 and minimal gethostname.m4), would anyone object to relaxing its license
 from LGPL to LGPLv2+?

 This is mainly to avoid gnulib's link-time warning:

   ...: undefined reference to [EMAIL PROTECTED]'

 In this particular case, gethostname is essentially a no-op,
 and always returns the empty string, since mingw
 has no uname function, and in that case, gethostname's
 body reverts to this:

 strcpy (name, );/* Hardcode your system name if you want.  
 */

On this basis, I've gone ahead and made it LGPLv2+.

Re: gethostname fix for mingw (was: Re: Problem with gethostbyname)

[Bruno Haible]

Ben Pfaff wrote:
 Fix gethostname on mingw.
 * lib/unistd.in.h: Bypass bad winsock2 prototype for gethostname.
 Prevent calling gethostname on mingw without using the gethostname
 module.
 * gethostname.m4: Invoke gl_PREREQ_SYS_H_WINSOCK2 if it is
 available.
 * doc/posix-functions/gethostname.texi: Update.

Nearly good. I improved two things:

  - #include unistd.h would make the non-POSIX functions accept(), ...,
socket(), select() visible.

  - When the module 'gethostname' is requested and the module 'sys_socket'
is not, then the use of
  #include unistd.h
  #include winsock2.h
would lead to a clash of different prototypes of gethostname(). In other
words, every time you have an m4_ifdef() of a macro defined in another
gnulib module, there are chances that it's a bug.

and applied this:


2008-10-25  Ben Pfaff  [EMAIL PROTECTED]
Bruno Haible  [EMAIL PROTECTED]

* lib/unistd.in.h: Include winsock2.h.
(socket, connect,accept, bind, getpeername, getsockname, getsockopt,
listen, recv, send, recvfrom, sendto, setsockopt, shutdown, select):
Provide dummy declarations.
(gethostname): Override.
* lib/sys_socket.in.h (gethostname): Provide dummy declaration.
* m4/gethostname.m4 (gl_FUNC_GETHOSTNAME): Invoke
gl_PREREQ_SYS_H_WINSOCK2.
* modules/gethostname (Files): Add m4/sys_socket_h.m4.
* doc/posix-functions/gethostname.texi: More details.

--- lib/sys_socket.in.h.orig2008-10-25 23:00:21.0 +0200
+++ lib/sys_socket.in.h 2008-10-25 22:57:53.0 +0200
@@ -145,6 +145,11 @@
 #  define close close_used_without_including_unistd_h
 # endif
 
+# if @HAVE_WINSOCK2_H@  !defined _GL_UNISTD_H
+#  undef gethostname
+#  define gethostname gethostname_used_without_including_unistd_h
+# endif
+
 # if @GNULIB_SOCKET@
 #  if @HAVE_WINSOCK2_H@
 #   undef socket
--- lib/unistd.in.h.orig2008-10-25 23:00:21.0 +0200
+++ lib/unistd.in.h 2008-10-25 22:57:53.0 +0200
@@ -42,6 +42,47 @@
 # include sys/types.h
 #endif
 
+#if @GNULIB_GETHOSTNAME@
+/* Get all possible declarations of gethostname().  */
+# if @UNISTD_H_HAVE_WINSOCK2_H@
+#  include winsock2.h
+#  if !defined _GL_SYS_SOCKET_H
+#   undef socket
+#   define socket  socket_used_without_including_sys_socket_h
+#   undef connect
+#   define connect connect_used_without_including_sys_socket_h
+#   undef accept
+#   define accept  accept_used_without_including_sys_socket_h
+#   undef bind
+#   define bindbind_used_without_including_sys_socket_h
+#   undef getpeername
+#   define getpeername getpeername_used_without_including_sys_socket_h
+#   undef getsockname
+#   define getsockname getsockname_used_without_including_sys_socket_h
+#   undef getsockopt
+#   define getsockopt  getsockopt_used_without_including_sys_socket_h
+#   undef listen
+#   define listen  listen_used_without_including_sys_socket_h
+#   undef recv
+#   define recvrecv_used_without_including_sys_socket_h
+#   undef send
+#   define sendsend_used_without_including_sys_socket_h
+#   undef recvfrom
+#   define recvfromrecvfrom_used_without_including_sys_socket_h
+#   undef sendto
+#   define sendto  sendto_used_without_including_sys_socket_h
+#   undef setsockopt
+#   define setsockopt  setsockopt_used_without_including_sys_socket_h
+#   undef shutdown
+#   define shutdownshutdown_used_without_including_sys_socket_h
+#  endif
+#  if !defined _GL_SYS_SELECT_H
+#   undef select
+#   define select  select_used_without_including_sys_select_h
+#  endif
+# endif
+#endif
+
 /* The definition of GL_LINK_WARNING is copied here.  */
 
 
@@ -284,9 +325,16 @@
Null terminate it if the name is shorter than LEN.
If the host name is longer than LEN, set errno = EINVAL and return -1.
Return 0 if successful, otherwise set errno and return -1.  */
-# if [EMAIL PROTECTED]@
+# if @UNISTD_H_HAVE_WINSOCK2_H@
+#  undef gethostname
+#  define gethostname rpl_gethostname
+# endif
+# if @UNISTD_H_HAVE_WINSOCK2_H@ || [EMAIL PROTECTED]@
 extern int gethostname(char *name, size_t len);
 # endif
+#elif @UNISTD_H_HAVE_WINSOCK2_H@
+# undef gethostname
+# define gethostname 
gethostname_used_without_requesting_gnulib_module_gethostname
 #elif defined GNULIB_POSIXCHECK
 # undef gethostname
 # define gethostname(n,l) \
--- m4/gethostname.m4.orig  2008-10-25 23:00:21.0 +0200
+++ m4/gethostname.m4   2008-10-25 22:57:53.0 +0200
@@ -1,4 +1,4 @@
-# gethostname.m4 serial 3
+# gethostname.m4 serial 4
 dnl Copyright (C) 2002, 2008 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -7,6 +7,7 @@
 AC_DEFUN([gl_FUNC_GETHOSTNAME],
 [
   

Re: gethostname fix for mingw

[Simon Josefsson]

Ben Pfaff [EMAIL PROTECTED] writes:

 Michel reported on pspp-dev that PSPP fails to compile on mingw
 due to the following error:

 In file included from
 C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/windows.h:98,
  from lseek.c:26:
 C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/winsock2.h:635:
 error: conflicting types for 'gethostname'
 ./unistd.h:313: error: previous declaration of 'gethostname' was here

I've seen this as well recently.

 I can see what is going wrong:

 - The gethostname module fails to find gethostname()
   because it is in the ws2_32 library, which it doesn't
   try to link against.  Thus, it tries to replace it.

 - Thus, it adds a prototype for gethostname() to the
   replacement unistd.h.  This prototype has a length
   parameter of type size_t (per POSIX).

 - The lseek module needs unistd.h and windows.h.  The
   latter in turn includes winsock2.h, which contains the
   Windows prototype for gethostname(), which has an
   length parameter of type int (who knows why).

 I think that the following change will fix the problem.  Does it
 look like the right approach?  If so, I will generate a new
 snapshot for Michel to test before I commit it to gnulib.

If it works, I'm for it.

/Simon

Re: gethostname on mingw, LIBS

[Bruno Haible]

Hi Simon,

  Note that this does not resolve the issue with mingw. On mingw, winsock2.h
  declares gethostname() also - but it requires linking with -lws2_32,
  right?
 
 Yes.
 
 Win32 also has GetComputerName that does not need -lws2_32.  It would be
 easier to use, but which one is right semantically I don't know.

It's easy to google for site:msdn.microsoft.com gethostname and
site:msdn.microsoft.com GetComputerName. Just did that, and found that
  - GetComputerName is not the right thing, but GetComputerNameEx is.
  - While gethostname requires to link with -lws2_32, GetComputerNameEx
does not.

  2. Should this be done through immediate linking, or dynamic linking?
 
 getaddrinfo.m4 adds -lws2_32 to LIBS automatically now.

Please don't do that. A project builds several applications in general.
In gettext, just because I have one program which needs select() and another
program which does network requests, I don't want all programs, from 'msgfmt'
to 'xgettext', to link with unneeded libraries.

   It may be cleaner to define a MINGW_LIBS variable instead, and ask
   developers to add $(MINGW_LIBS) to automake LIBADD variables for
   executables that need it.  sockets.m4 has been fixed in this way
   already.

MINGW_LIBS is not specific enough. How could a developer know on which
programs he needs it or not. IMO all library requirements must be attached
to particular modules with a particular purpose. Like $(LIBSOCKET),
$(LIBICONV), $(LIBTHREAD).

   Possibly the -lws2_32/LIBSOCKET/MINGW_LIBS handling should be put in a
   separate module?  Then getaddrinfo and sockets can depend on it,
   rather than duplicating it.

Yes, you're welcome to do this. But call it LIBSOCKET, please.

 gethostname.c could also use GetModuleHandle, similar to how
 getaddrinfo.c works, to avoid the -lws2_32 requirement.  If the
 application would not otherwise link to -lws2_32 this approach may be
 nicer.  But if applications are linked to -lws2_32 because of other
 gnulib modules anyway, it doesn't make much sense.

Yes, when you need the host name, usually it's in the context of network
accesses.

 The GetModuleHandle approach, together with a fallback replacement
 function, results in better portability generally.  Some Windows
 releases does not have getaddrinfo, and if the application is linked
 against -lws2_32 that has it, and the binary is transferred to an old
 system, it won't work.

For my part, I drop portability requirements to Windows98/ME, and assume
Windows 2000 at least. Reason: The documentation on msdn.microsoft.com
does not even mention any more which functions were defined in Windows98/ME
or not.

 Maybe the same approach cannot be used for gethostname: ...
 
 I'm not sure.  It seems pretty clear that MINGW_LIBS and GetModuleHandle
 are two approaches that can solve this problem.

And with GetComputerNameEx, there is no link requirement at all.

I propose this, together with some WINVER tricks to make it work.


--- lib/gethostname.c.orig  2008-10-23 13:45:02.0 +0200
+++ lib/gethostname.c   2008-10-23 13:44:03.0 +0200
@@ -22,8 +22,10 @@
 /* Specification.  */
 #include unistd.h
 
-#ifdef HAVE_UNAME
+#if HAVE_UNAME
 # include sys/utsname.h
+#elif (defined _WIN32 || defined __WIN32__)  ! defined __CYGWIN__
+# include windows.h
 #endif
 
 #include string.h
@@ -37,7 +39,7 @@
 int
 gethostname (char *name, size_t len)
 {
-#ifdef HAVE_UNAME
+#if HAVE_UNAME
   struct utsname uts;
 
   if (uname (uts) == -1)
@@ -49,6 +51,14 @@
   len = sizeof (uts.nodename);
 }
   strncpy (name, uts.nodename, len);
+#elif (defined _WIN32 || defined __WIN32__)  ! defined __CYGWIN__
+  /* GetComputerName is not the right thing.  gethostname from winsock2.h
+ would be right, but requires linking with -lws2_32.  So we use
+ GetComputerNameEx.  */
+  DWORD size = (len = (DWORD)~0 ? len : (DWORD)~0);
+
+  if (!GetComputerNameEx (ComputerNameDnsHostname, name, size))
+return -1;
 #else
   strcpy (name, );   /* Hardcode your system name if you want.  */
 #endif

Re: gethostname fix for mingw (was: Re: Problem with gethostbyname)

[Bruno Haible]

Ben Pfaff wrote:
 --- a/lib/unistd.in.h
 +++ b/lib/unistd.in.h
 @@ -281,8 +281,17 @@ extern int getdtablesize (void);
 If the host name is longer than LEN, set errno = EINVAL and return -1.
 Return 0 if successful, otherwise set errno and return -1.  */
  # if [EMAIL PROTECTED]@
 +#  if HAVE_WINSOCK2_H
 +#   /* Bypass bad prototype for gethostname(). */
 +#   include winsock2.h
 +#   undef gethostname
 +#   define gethostname rpl_gethostname
 +#  endif
  extern int gethostname(char *name, size_t len);
  # endif
 +#elif @UNISTD_H_HAVE_WINSOCK2_H@
 +# undef gethostname
 +# define gethostname 
 gethostname_used_without_requesting_gnulib_module_gethostname
  #elif defined GNULIB_POSIXCHECK
  # undef gethostname
  # define gethostname(n,l) \

Yes, this looks all right. Only use @UNISTD_H_HAVE_WINSOCK2_H@ instead
of HAVE_WINSOCK2_H in line 284 above.

Thanks!

Bruno

Re: gethostname on mingw, LIBS

[Simon Josefsson]

Bruno Haible [EMAIL PROTECTED] writes:

 Maybe the same approach cannot be used for gethostname: ...
 
 I'm not sure.  It seems pretty clear that MINGW_LIBS and GetModuleHandle
 are two approaches that can solve this problem.

 And with GetComputerNameEx, there is no link requirement at all.

 I propose this, together with some WINVER tricks to make it work.

Looks fine, please push it, although I don't see any WINVER tricks?

/Simon


 --- lib/gethostname.c.orig2008-10-23 13:45:02.0 +0200
 +++ lib/gethostname.c 2008-10-23 13:44:03.0 +0200
 @@ -22,8 +22,10 @@
  /* Specification.  */
  #include unistd.h
  
 -#ifdef HAVE_UNAME
 +#if HAVE_UNAME
  # include sys/utsname.h
 +#elif (defined _WIN32 || defined __WIN32__)  ! defined __CYGWIN__
 +# include windows.h
  #endif
  
  #include string.h
 @@ -37,7 +39,7 @@
  int
  gethostname (char *name, size_t len)
  {
 -#ifdef HAVE_UNAME
 +#if HAVE_UNAME
struct utsname uts;
  
if (uname (uts) == -1)
 @@ -49,6 +51,14 @@
len = sizeof (uts.nodename);
  }
strncpy (name, uts.nodename, len);
 +#elif (defined _WIN32 || defined __WIN32__)  ! defined __CYGWIN__
 +  /* GetComputerName is not the right thing.  gethostname from winsock2.h
 + would be right, but requires linking with -lws2_32.  So we use
 + GetComputerNameEx.  */
 +  DWORD size = (len = (DWORD)~0 ? len : (DWORD)~0);
 +
 +  if (!GetComputerNameEx (ComputerNameDnsHostname, name, size))
 +return -1;
  #else
strcpy (name, ); /* Hardcode your system name if you want.  */
  #endif

Re: gethostname

[Bruno Haible]

Hello Ben,

 I missed seeing that in the show-portability output, even
 though it was right there.  I think that part of the reason was
 that the output is grouped by library.  When I adjust the sorting
 to be by OS, it is easier for me to see that ...
 ...
 --- tmp/various-symlists/show-portability   2008-01-13 12:51:54.0 
 -0800
 +++ various-symlists/show-portability   2008-08-12 19:46:40.0 -0700
 @@ -79,7 +79,7 @@
  -e 's,^librootbeos$,libc 
beos,'
  grep '^'$symbol'$' $d/* /dev/null || echo $os 13
done \
 -| sed -e 's,^\(\) *,\1,' | sort -k1,80
 +| sed -e 's,^\(\) *,\1,' | sort -b -k 2,2 -k 1,1
  } 3 .missing
  missing=`cat .missing`
  rm -f .missing

Makes sense. I applied your patch to my copy and will distribute it. Thanks.

Bruno

Re: gethostname

[Simon Josefsson]

Ben Pfaff [EMAIL PROTECTED] writes:

 libcsolaris-2.10
 libnsl  solaris-2.10
 libnsl  solaris-2.4
 libcsolaris-2.5.1
 libnsl  solaris-2.5.1
...
 -| sed -e 's,^\(\) *,\1,' | sort -k1,80
 +| sed -e 's,^\(\) *,\1,' | sort -b -k 2,2 -k 1,1

Is there a sort option that results in the output being something like
the below?

 libnsl  solaris-2.4
 libcsolaris-2.5.1
 libnsl  solaris-2.5.1
 libcsolaris-2.10
 libnsl  solaris-2.10

I.e., normal alphabetical, but sort digits in numeral order.

/Simon

Re: gethostname

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Simon Josefsson on 8/13/2008 4:59 AM:
| Is there a sort option that results in the output being something like
| the below?
|
|  libnsl  solaris-2.4
|  libcsolaris-2.5.1
|  libnsl  solaris-2.5.1
|  libcsolaris-2.10
|  libnsl  solaris-2.10
|
| I.e., normal alphabetical, but sort digits in numeral order.

Sounds like you want version comparison (based on strverscmp).  This has
been proposed for GNU coreutils, but is not present yet as of 6.12.

- --
Don't work too hard, make some time for fun as well!

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

iEYEARECAAYFAkiizLAACgkQ84KuGfSFAYDr1ACeJQpZyAzbP2hmTyIVINnzZnO4
GUUAoIv+MYqhWadUKtsZ6pk5zVXy586a
=U/xG
-END PGP SIGNATURE-

Re: gethostname

[Bruno Haible]

Sam Steingold asked:
 gnulib/lib/gethostname.c says:
 
 #ifdef HAVE_UNAME
 # include sys/utsname.h
 #endif
 
 1. why aren't you testing for HAVE_SYS_UTSNAME_H instead?

All systems that have uname() also have sys/utsname.h.
We estimate the probability that a system with sys/utsname.h also has uname()
to 99%.

 2. are there really systems without uname  sys/utsname.h, given that these 
 are in posix? 
 http://www.opengroup.org/onlinepubs/009695399/functions/uname.html

Yes, some old systems did not have uname() and sys/utsname.h: especially
SunOS 4. But these are not porting targets today any more.

Simon Josefsson wrote:
 I think the right solution here should be to apply the patch below.  If
 there are problems on any system caused by that, the solution to that
 problem should be to create a module for sys/utsname.h and uname.

The gnulib docs (doc/posix-functions/{gethostname,uname}.texi) say that
uname and gethostname are both missing on mingw systems. If your patch
is applied in the current state, it causes a link error on mingw.

Feel free to contribute an uname() substitute, however. With that in place,
your patch can be applied without damage.

 The gethostname module shouldn't depend on such modules, they need to be
 added manually by maintainers who want compatibility with non-POSIX
 systems.

mingw portability is requested quite often, therefore gnulib includes the
dependencies needed for mingw portability. We omit dependencies only for
extremely old systems (e.g. BSD 4.2 - missing memcpy()).

Sam Steingold wrote:
 note that gethostname is just as posix as uname,
 http://www.opengroup.org/onlinepubs/009695399/functions/gethostname.html
 so the gethostname module is only needed for non-posix systems.

Historically, uname came from SysV, and gethostname came from BSD.

Bruno

Re: gethostname

[Simon Josefsson]

Sam Steingold [EMAIL PROTECTED] writes:

 1. why aren't you testing for HAVE_SYS_UTSNAME_H instead?

 2. are there really systems without uname  sys/utsname.h, given
 that these are in posix?
 http://www.opengroup.org/onlinepubs/009695399/functions/uname.html

 I think the right solution here should be to apply the patch below.
 If there are problems on any system caused by that, the solution to
 that problem should be to create a module for sys/utsname.h and uname.
 The gethostname module shouldn't depend on such modules, they need to
 be added manually by maintainers who want compatibility with non-POSIX
 systems.  Thoughts?

 note that gethostname is just as posix as uname,
 http://www.opengroup.org/onlinepubs/009695399/functions/gethostname.html
 so the gethostname module is only needed for non-posix systems.

Indeed, so I am less sure my patch is the right thing.  Could you
explain why the current code causes problems for you?

 2. are there really systems without uname  sys/utsname.h, given that 
 these 
 are in posix? 
 http://www.opengroup.org/onlinepubs/009695399/functions/uname.html

 Yes, some old systems did not have uname() and sys/utsname.h: especially
 SunOS 4. But these are not porting targets today any more.

Didn't SunOS 4 have gethostname?

 Simon Josefsson wrote:
 I think the right solution here should be to apply the patch below.  If
 there are problems on any system caused by that, the solution to that
 problem should be to create a module for sys/utsname.h and uname.

 The gnulib docs (doc/posix-functions/{gethostname,uname}.texi) say that
 uname and gethostname are both missing on mingw systems. If your patch
 is applied in the current state, it causes a link error on mingw.

 Feel free to contribute an uname() substitute, however. With that in place,
 your patch can be applied without damage.

I'm not sure the patch makes sense any more -- if the gethostname module
is there only to make things work under mingw, my patch would break
things and requires maintainers to manually also add the uname module to
the mix.  How could that dependency be explained?  Having the
gethostname module depend on a uname module would be the wrong approach,
wouldn't it?  Otherwise, all POSIX-replacement modules in gnulib would
need to depend on modules for all POSIX features they use in its
implementation -- I suspect this can quickly become a clique, causing
any addition of a POSIX replacement function to drag in all POSIX
replacement functions in gnulib.

If there were a platform that has uname but doesn't have gethostname, I
can see some merit to my patch, but are there such beasts?

 The gethostname module shouldn't depend on such modules, they need to be
 added manually by maintainers who want compatibility with non-POSIX
 systems.

 mingw portability is requested quite often, therefore gnulib includes the
 dependencies needed for mingw portability. We omit dependencies only for
 extremely old systems (e.g. BSD 4.2 - missing memcpy()).

Agreed.

/Simon

Re: gethostname

[Sam Steingold]

Simon Josefsson wrote:

Sam Steingold [EMAIL PROTECTED] writes:


1. why aren't you testing for HAVE_SYS_UTSNAME_H instead?

2. are there really systems without uname  sys/utsname.h, given
that these are in posix?
http://www.opengroup.org/onlinepubs/009695399/functions/uname.html

I think the right solution here should be to apply the patch below.
If there are problems on any system caused by that, the solution to
that problem should be to create a module for sys/utsname.h and uname.
The gethostname module shouldn't depend on such modules, they need to
be added manually by maintainers who want compatibility with non-POSIX
systems.  Thoughts?

note that gethostname is just as posix as uname,
http://www.opengroup.org/onlinepubs/009695399/functions/gethostname.html
so the gethostname module is only needed for non-posix systems.


Indeed, so I am less sure my patch is the right thing.  Could you
explain why the current code causes problems for you?


no problems - just questions:

1. is this module ever needed on a unix system?
i.e., are there any unix systems still in use that lack gethostname?

2. are there any unix systems still in use that lack uname?

Re: gethostname

[Ben Pfaff]

Sam Steingold [EMAIL PROTECTED] writes:

 1. is this module ever needed on a unix system?
 i.e., are there any unix systems still in use that lack gethostname?

 2. are there any unix systems still in use that lack uname?

Among the platforms represented in Bruno Haible's collection of
library symbols, only mingw and nsk-G06 lack either one (and they
lack both of them).  Solaris has gethostname in libnsl, BeOS has
it in libnet, and other platforms have it in libc.  BeoS has
uname in libnet, and other platforms have it in libc.
-- 
...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver.
--Daniel Pead

Re: gethostname

[Sam Steingold]

Ben Pfaff wrote:

Sam Steingold [EMAIL PROTECTED] writes:


1. is this module ever needed on a unix system?
i.e., are there any unix systems still in use that lack gethostname?

2. are there any unix systems still in use that lack uname?


Among the platforms represented in Bruno Haible's collection of
library symbols, only mingw and nsk-G06 lack either one (and they
lack both of them).  Solaris has gethostname in libnsl, BeOS has
it in libnet, and other platforms have it in libc.  BeoS has
uname in libnet, and other platforms have it in libc.


but this makes the gethostname module completely useless, doesn't it?

Re: gethostname

[Simon Josefsson]

Sam Steingold [EMAIL PROTECTED] writes:

 Simon Josefsson wrote:
 Sam Steingold [EMAIL PROTECTED] writes:

 1. why aren't you testing for HAVE_SYS_UTSNAME_H instead?

 2. are there really systems without uname  sys/utsname.h, given
 that these are in posix?
 http://www.opengroup.org/onlinepubs/009695399/functions/uname.html
 I think the right solution here should be to apply the patch below.
 If there are problems on any system caused by that, the solution to
 that problem should be to create a module for sys/utsname.h and uname.
 The gethostname module shouldn't depend on such modules, they need to
 be added manually by maintainers who want compatibility with non-POSIX
 systems.  Thoughts?
 note that gethostname is just as posix as uname,
 http://www.opengroup.org/onlinepubs/009695399/functions/gethostname.html
 so the gethostname module is only needed for non-posix systems.

 Indeed, so I am less sure my patch is the right thing.  Could you
 explain why the current code causes problems for you?

 no problems - just questions:

 1. is this module ever needed on a unix system?
 i.e., are there any unix systems still in use that lack gethostname?

 2. are there any unix systems still in use that lack uname?

Ben answered those questions.  Even if the code may not be optimal for
some platform we aren't aware of, until we know of a real problem with
it I think we could leave the code as-is.

/Simon

Re: gethostname

[Ben Pfaff]

Sam Steingold [EMAIL PROTECTED] writes:

 Ben Pfaff wrote:
 Sam Steingold [EMAIL PROTECTED] writes:

 1. is this module ever needed on a unix system?
 i.e., are there any unix systems still in use that lack gethostname?

 2. are there any unix systems still in use that lack uname?

 Among the platforms represented in Bruno Haible's collection of
 library symbols, only mingw and nsk-G06 lack either one (and they
 lack both of them).  Solaris has gethostname in libnsl, BeOS has
 it in libnet, and other platforms have it in libc.  BeoS has
 uname in libnet, and other platforms have it in libc.

 but this makes the gethostname module completely useless, doesn't it?

To me, it looks like it has limited value: on mingw and nsk-G06
it provides a gethostname function that is otherwise missing.  I
don't think it will ever fall back on uname on the systems that
we know about, though, except possibly on Solaris (because the m4
code doesn't check for gethostname in libnsl).

Probably gethostname.m4 should check for gethostname in libnsl
and in libnet?
-- 
The sound of peacocks being shredded can't possibly be
 any worse than the sound of peacocks not being shredded.
Tanuki the Raccoon-dog in the Monastery

Re: gethostname

[Sam Steingold]

Simon Josefsson wrote:

Sam Steingold [EMAIL PROTECTED] writes:


Simon Josefsson wrote:

Sam Steingold [EMAIL PROTECTED] writes:


1. why aren't you testing for HAVE_SYS_UTSNAME_H instead?

2. are there really systems without uname  sys/utsname.h, given
that these are in posix?
http://www.opengroup.org/onlinepubs/009695399/functions/uname.html

I think the right solution here should be to apply the patch below.
If there are problems on any system caused by that, the solution to
that problem should be to create a module for sys/utsname.h and uname.
The gethostname module shouldn't depend on such modules, they need to
be added manually by maintainers who want compatibility with non-POSIX
systems.  Thoughts?

note that gethostname is just as posix as uname,
http://www.opengroup.org/onlinepubs/009695399/functions/gethostname.html
so the gethostname module is only needed for non-posix systems.

Indeed, so I am less sure my patch is the right thing.  Could you
explain why the current code causes problems for you?

no problems - just questions:

1. is this module ever needed on a unix system?
i.e., are there any unix systems still in use that lack gethostname?

2. are there any unix systems still in use that lack uname?


Ben answered those questions.  Even if the code may not be optimal for
some platform we aren't aware of, until we know of a real problem with
it I think we could leave the code as-is.


Please name the platform(s) which can benefit from this module.

Ben's answer suggests that the set is empty.

Re: gethostname

[Simon Josefsson]

Sam Steingold [EMAIL PROTECTED] writes:

 Simon Josefsson wrote:
 Sam Steingold [EMAIL PROTECTED] writes:

 Simon Josefsson wrote:
 Sam Steingold [EMAIL PROTECTED] writes:

 1. why aren't you testing for HAVE_SYS_UTSNAME_H instead?

 2. are there really systems without uname  sys/utsname.h, given
 that these are in posix?
 http://www.opengroup.org/onlinepubs/009695399/functions/uname.html
 I think the right solution here should be to apply the patch below.
 If there are problems on any system caused by that, the solution to
 that problem should be to create a module for sys/utsname.h and uname.
 The gethostname module shouldn't depend on such modules, they need to
 be added manually by maintainers who want compatibility with non-POSIX
 systems.  Thoughts?
 note that gethostname is just as posix as uname,
 http://www.opengroup.org/onlinepubs/009695399/functions/gethostname.html
 so the gethostname module is only needed for non-posix systems.
 Indeed, so I am less sure my patch is the right thing.  Could you
 explain why the current code causes problems for you?
 no problems - just questions:

 1. is this module ever needed on a unix system?
 i.e., are there any unix systems still in use that lack gethostname?

 2. are there any unix systems still in use that lack uname?

 Ben answered those questions.  Even if the code may not be optimal for
 some platform we aren't aware of, until we know of a real problem with
 it I think we could leave the code as-is.

 Please name the platform(s) which can benefit from this module.

 Ben's answer suggests that the set is empty.

Ben said MinGW doesn't have gethostname.  I don't know what nsk-G06 is,
is it a platform gnulib supports?

Hm.  I think MinGW actually does have a gethostname, but you need to
link to -lws2_32 to see it.  Yup.  I actually have a local tree of
gnulib that implements this test.  Patch below, but it is ancient and
there were likely some reason this was never installed.  I'll see if I
can revise it.

/Simon

diff --git a/ChangeLog b/ChangeLog
index f52d4c2..070a15e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,4 +1,22 @@
 2008-01-17  Simon Josefsson  [EMAIL PROTECTED]
+Bruno Haible  [EMAIL PROTECTED]
+
+   * lib/unistd.in.h: Include sys/socket.h conditionally.
+   * modules/unistd (Makefile.am): Substitute GNULIB_GETHOSTNAME.
+   * modules/gethostname (Depends-on): Add sys_socket and unistd.
+   (configure.ac): Invoke gl_MODULE_INDICATOR.
+   (Include): Document unistd.h.
+   * m4/unistd_h.m4: Default GNULIB_GETHOSTNAME to 0.
+
+2008-01-17  Simon Josefsson  [EMAIL PROTECTED]
+
+   * m4/gethostname.m4: Look for gethostname in winsock2.h and
+   -lws2_32 too, for mingw.
+
+   * modules/gethostname (Depends-on): Add sys_socket, needed for
+   proper mingw checks.
+
+2008-01-17  Simon Josefsson  [EMAIL PROTECTED]
 
* modules/gethostname-tests: New file.
 
diff --git a/lib/unistd.in.h b/lib/unistd.in.h
index 5400c86..809c14a 100644
--- a/lib/unistd.in.h
+++ b/lib/unistd.in.h
@@ -1,5 +1,5 @@
 /* Substitute for and wrapper around unistd.h.
-   Copyright (C) 2004-2007 Free Software Foundation, Inc.
+   Copyright (C) 2004-2008 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
@@ -33,6 +33,11 @@
 /* mingw fails to declare _exit in unistd.h.  */
 #include stdlib.h
 
+/* mingw fails to declare gethostname in unistd.h.  */
+#if [EMAIL PROTECTED]@  ((defined _WIN32 || defined __WIN32__)  ! defined 
__CYGWIN__)
+# include sys/socket.h
+#endif
+
 /* The definition of GL_LINK_WARNING is copied here.  */
 
 
diff --git a/m4/gethostname.m4 b/m4/gethostname.m4
index 1e9749d..359cdf1 100644
--- a/m4/gethostname.m4
+++ b/m4/gethostname.m4
@@ -1,13 +1,45 @@
-# gethostname.m4 serial 2
-dnl Copyright (C) 2002 Free Software Foundation, Inc.
+# gethostname.m4 serial 3
+dnl Copyright (C) 2002, 2008 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.
 
 AC_DEFUN([gl_FUNC_GETHOSTNAME],
 [
-  AC_REPLACE_FUNCS(gethostname)
-  if test $ac_cv_func_gethostname = no; then
+  AC_REQUIRE([gl_HEADER_SYS_SOCKET])dnl for HAVE_SYS_SOCKET_H, HAVE_WINSOCK2_H
+
+  AC_CACHE_CHECK([for gethostname], [gl_cv_func_gethostname], [
+AC_TRY_LINK([
+#include sys/types.h
+#ifdef HAVE_SYS_SOCKET_H
+#include sys/socket.h
+#endif
+#include stddef.h
+], [gethostname(, 0);],
+  [gl_cv_func_gethostname=yes],
+  [gl_cv_func_gethostname=no])])
+  if test $gl_cv_func_gethostname = no; then
+AC_CACHE_CHECK(for gethostname in winsock2.h and -lws2_32,
+  gl_cv_w32_gethostname, [
+  gl_cv_w32_gethostname=no
+  am_save_LIBS=$LIBS
+  LIBS=$LIBS -lws2_32
+  AC_TRY_LINK([
+#ifdef HAVE_WINSOCK2_H
+#include 

Re: gethostname

[Sam Steingold]

Ben Pfaff wrote:

Sam Steingold [EMAIL PROTECTED] writes:


Ben Pfaff wrote:

Sam Steingold [EMAIL PROTECTED] writes:


1. is this module ever needed on a unix system?
i.e., are there any unix systems still in use that lack gethostname?

2. are there any unix systems still in use that lack uname?

Among the platforms represented in Bruno Haible's collection of
library symbols, only mingw and nsk-G06 lack either one (and they
lack both of them).  Solaris has gethostname in libnsl, BeOS has
it in libnet, and other platforms have it in libc.  BeoS has
uname in libnet, and other platforms have it in libc.

but this makes the gethostname module completely useless, doesn't it?


To me, it looks like it has limited value: on mingw and nsk-G06
it provides a gethostname function that is otherwise missing.  I
don't think it will ever fall back on uname on the systems that
we know about, though, except possibly on Solaris (because the m4
code doesn't check for gethostname in libnsl).


so the logical approach would be to either drop the C code altogether or 
implement it for nsk-G06 (whatever that might be).


note: woe32 does have gethostname, so mingw is fully covered.


Probably gethostname.m4 should check for gethostname in libnsl
and in libnet?


sounds good.

Re: gethostname

[Ben Pfaff]

Simon Josefsson [EMAIL PROTECTED] writes:

 I don't know what nsk-G06 is, is it a platform gnulib supports?

I think it's the Tandem (now HP) NonStop Kernel.  I don't know
whether gnulib supports it.
-- 
Ben Pfaff 
http://benpfaff.org

Re: gethostname

[Simon Josefsson]

Sam Steingold [EMAIL PROTECTED] writes:

 note: woe32 does have gethostname, so mingw is fully covered.

Not quite, MinGW only has gethostname if you link to -lws2_32.  The
current m4 test doesn't check for this, so it fails to detect that
gethostname exists.  My patch attempts to test for gethostname in that
library, a'la similar code for getaddrinfo etc, but it is rather messy.
Possibly this link-to-ws2_32-if-it-makes-sense code should be
re-factored out to a separate m4 test.

/Simon

Re: gethostname

[Bruno Haible]

Ben Pfaff wrote:
 Solaris has gethostname in libnsl,

Solaris = 2.5.1 also has it in libc. Since Solaris 2.4 is not worth supporting
today any more, the current gethostname module is right in *not* testing for
-lnsl.

Bruno

Re: gethostname

[Ben Pfaff]

Bruno Haible [EMAIL PROTECTED] writes:

 Ben Pfaff wrote:
 Solaris has gethostname in libnsl,

 Solaris = 2.5.1 also has it in libc. Since Solaris 2.4 is not worth 
 supporting
 today any more, the current gethostname module is right in *not* testing for
 -lnsl.

You are right, of course.

I missed seeing that in the show-portability output, even
though it was right there.  I think that part of the reason was
that the output is grouped by library.  When I adjust the sorting
to be by OS, it is easier for me to see that:

libcaix-4.3.2
libcaix-5.1.0
libnet  beos
libccygwin
libccygwin
libcfreebsd-5.2.1
libcfreebsd-6.0
libcglibc-2.3.6
libchpux-11.00
libchpux-11.11
libcinterix-3.5
libcirix-6.5
libcmacosx-10.3
libcnetbsd-3.0
libcopenbsd-3.8
libcosf1-4.0d
libcosf1-5.1a
libcpips
libcsolaris-2.10
libnsl  solaris-2.10
libnsl  solaris-2.4
libcsolaris-2.5.1
libnsl  solaris-2.5.1
libcsolaris-2.6
libnsl  solaris-2.6
libcsolaris-2.7
libnsl  solaris-2.7
libcsolaris-2.8
libnsl  solaris-2.8
libcsolaris-2.9
libnsl  solaris-2.9
MISSING in  mingw nsk-G06

--- tmp/various-symlists/show-portability   2008-01-13 12:51:54.0 
-0800
+++ various-symlists/show-portability   2008-08-12 19:46:40.0 -0700
@@ -79,7 +79,7 @@
 -e 's,^librootbeos$,libc   
 beos,'
 grep '^'$symbol'$' $d/* /dev/null || echo $os 13
   done \
-| sed -e 's,^\(\) *,\1,' | sort -k1,80
+| sed -e 's,^\(\) *,\1,' | sort -b -k 2,2 -k 1,1
 } 3 .missing
 missing=`cat .missing`
 rm -f .missing


-- 
I love deadlines.
I love the whooshing noise they make as they go by.
--Douglas Adams

Re: gethostname

[Simon Josefsson]

Sam Steingold [EMAIL PROTECTED] writes:

 gnulib/lib/gethostname.c says:

 #ifdef HAVE_UNAME
 # include sys/utsname.h
 #endif

 1. why aren't you testing for HAVE_SYS_UTSNAME_H instead?

 2. are there really systems without uname  sys/utsname.h, given
 that these are in posix?
 http://www.opengroup.org/onlinepubs/009695399/functions/uname.html

I think the right solution here should be to apply the patch below.  If
there are problems on any system caused by that, the solution to that
problem should be to create a module for sys/utsname.h and uname.  The
gethostname module shouldn't depend on such modules, they need to be
added manually by maintainers who want compatibility with non-POSIX
systems.  Thoughts?

/Simon

diff --git a/ChangeLog b/ChangeLog
index 8d92122..b911473 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2008-08-11  Simon Josefsson  [EMAIL PROTECTED]
+
+   * lib/gethostname.c: Unconditionally include sys/utsname.h and
+   call uname.
+
+   * m4/gethostname.m4: Assume uname exists.
+
 2008-08-07  Paolo Bonzini  [EMAIL PROTECTED]
 
* lib/lock.c (glthread_recursive_lock_init_multithreaded)
diff --git a/lib/gethostname.c b/lib/gethostname.c
index 169dd4e..c9624f0 100644
--- a/lib/gethostname.c
+++ b/lib/gethostname.c
@@ -19,9 +19,7 @@
 
 #include config.h
 
-#ifdef HAVE_UNAME
-# include sys/utsname.h
-#endif
+#include sys/utsname.h
 
 #include string.h
 
@@ -34,7 +32,6 @@
 int
 gethostname (char *name, size_t len)
 {
-#ifdef HAVE_UNAME
   struct utsname uts;
 
   if (uname (uts) == -1)
@@ -46,8 +43,6 @@ gethostname (char *name, size_t len)
   len = sizeof (uts.nodename);
 }
   strncpy (name, uts.nodename, len);
-#else
-  strcpy (name, );   /* Hardcode your system name if you want.  */
-#endif
+
   return 0;
 }
diff --git a/m4/gethostname.m4 b/m4/gethostname.m4
index 1e9749d..616f9e4 100644
--- a/m4/gethostname.m4
+++ b/m4/gethostname.m4
@@ -1,5 +1,5 @@
-# gethostname.m4 serial 2
-dnl Copyright (C) 2002 Free Software Foundation, Inc.
+# gethostname.m4 serial 3
+dnl Copyright (C) 2002, 2008 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.
@@ -14,5 +14,5 @@ AC_DEFUN([gl_FUNC_GETHOSTNAME],
 
 # Prerequisites of lib/gethostname.c.
 AC_DEFUN([gl_PREREQ_GETHOSTNAME], [
-  AC_CHECK_FUNCS(uname)
+  :
 ])

Re: gethostname

[Sam Steingold]

 * Simon Josefsson [EMAIL PROTECTED] [2008-08-11 23:23:24 +0200]:

 Sam Steingold [EMAIL PROTECTED] writes:

 gnulib/lib/gethostname.c says:

 #ifdef HAVE_UNAME
 # include sys/utsname.h
 #endif

 1. why aren't you testing for HAVE_SYS_UTSNAME_H instead?

 2. are there really systems without uname  sys/utsname.h, given
 that these are in posix?
 http://www.opengroup.org/onlinepubs/009695399/functions/uname.html

 I think the right solution here should be to apply the patch below.
 If there are problems on any system caused by that, the solution to
 that problem should be to create a module for sys/utsname.h and uname.
 The gethostname module shouldn't depend on such modules, they need to
 be added manually by maintainers who want compatibility with non-POSIX
 systems.  Thoughts?

note that gethostname is just as posix as uname,
http://www.opengroup.org/onlinepubs/009695399/functions/gethostname.html
so the gethostname module is only needed for non-posix systems.


-- 
Sam Steingold (http://sds.podval.org/) on Fedora release 9 (Sulphur)
http://israelunderattack.slide.com http://camera.org http://memri.org
http://jihadwatch.org http://mideasttruth.com
Are you smart enough to use Lisp?

Re: gethostname-test

[Simon Josefsson]

Bruno Haible [EMAIL PROTECTED] writes:

 Hi Simon,

  2008-01-17  Simon Josefsson  [EMAIL PROTECTED]
  
 +* modules/gethostname-tests: New file.
 +
 +* tests/test-gethostname.c: New file.

 Thanks. A nice test. Just a fix to make it compile with gcc -Wall:

Oops, thanks.

/Simon


 2008-01-17  Bruno Haible  [EMAIL PROTECTED]

   * tests/test-gethostname.c (main): Fix printf statement.

 *** tests/test-gethostname.c.orig   2008-01-18 02:12:12.0 +0100
 --- tests/test-gethostname.c2008-01-18 02:11:08.0 +0100
 ***
 *** 36,42 
   
 if (rc != 0)
   {
 !   printf (gethostname failed, rc %d errno %d\n, errno);
 return 1;
   }
   
 --- 36,42 
   
 if (rc != 0)
   {
 !   printf (gethostname failed, rc %d errno %d\n, rc, errno);
 return 1;
   }
   

Re: gethostname-test

[Bruno Haible]

Hi Simon,

  2008-01-17  Simon Josefsson  [EMAIL PROTECTED]
  
 + * modules/gethostname-tests: New file.
 +
 + * tests/test-gethostname.c: New file.

Thanks. A nice test. Just a fix to make it compile with gcc -Wall:


2008-01-17  Bruno Haible  [EMAIL PROTECTED]

* tests/test-gethostname.c (main): Fix printf statement.

*** tests/test-gethostname.c.orig   2008-01-18 02:12:12.0 +0100
--- tests/test-gethostname.c2008-01-18 02:11:08.0 +0100
***
*** 36,42 
  
if (rc != 0)
  {
!   printf (gethostname failed, rc %d errno %d\n, errno);
return 1;
  }
  
--- 36,42 
  
if (rc != 0)
  {
!   printf (gethostname failed, rc %d errno %d\n, rc, errno);
return 1;
  }