On 06/24/2016 11:01 PM, Tatsuro MATSUOKA wrote:
- Original Message -
From: John W. Eaton <j...@octave.org>
To: gnulib <bug-gnulib@gnu.org>
Cc: j...@octave.org
Date: 2016/6/25, Sat 04:46
Subject: gethostname on 64-bit Windows
I needed the attached change to cross co
- Original Message -
> From: John W. Eaton <j...@octave.org>
> To: gnulib <bug-gnulib@gnu.org>
> 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 f
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
diff -uNr
I have a follow-up to this.
What was happening is that in the check for `gethostname`, it tries to compile
without linking against ws2_32. Note that unistd.h includes winsock2.h on my
platform. Now, normally this check will fail (at linking), BUT since a check
has been made before for linking
acutually
works, so forgive me if this is a basic error.
I'll start off by saying that building with a 32-bit target works fine.
FontForge has `gethostname` as a requirement, so the `gethostname` module is
set from Gnulib. When building on 32-bit and when running the configure script
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
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
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
Hi Bruno,
On Wed, Sep 15, 2010 at 11:18 AM, Bruno Haible br...@clisp.org wrote:
Have you tried to follow the approach of
http://www.gnu.org/software/gnulib/manual/html_node/POSIX-Substitutes-Library.html?
I haven't, but I would like to hear about success or problems that
you encounter.
1.
Hi Bruce,
* Bruce Korb wrote on Thu, Sep 16, 2010 at 08:00:46PM CEST:
3. config.h needs to be installed. Now, where was that name munger
for the config.h header
Thinking of AX_PREFIX_CONFIG_H from the Autoconf Macro Archive?
BTW, that currently has a PR (with patch) open against it,
Bruno Haible wrote:
I am now getting
undefined reference to
`_gethostname_used_without_requesting_gnulib_module_gethostname'
This indicates that you have included gnulib unistd.h, are using
gethostname(),
and have not asked for the gnulib module 'gethostname'.
- If you want to use a POSIX
The only problem which gethostname module fixes is:
On mingw, this function has a prototype that differs from that
specified by POSIX, and it is defined only in the ws2_32 library.
why does it have such extensive dependencies? (sockets! errno!)
I have to reiterate my complaint that the gnulib
On Wed, Sep 15, 2010 at 9:34 AM, Paul Eggert egg...@cs.ucla.edu wrote:
On 09/15/2010 08:41 AM, Sam Steingold wrote:
I have to reiterate my complaint that the gnulib dependencies mean that one
has
to include (almost) the whole of gnulib if one includes (almost) any part
thereof.
I agree
Hi Bruce,
* Bruce Korb wrote on Wed, Sep 15, 2010 at 07:01:11PM CEST:
So, let's start that discussion again: let's make an installable
gnulib that basically does all the configure tests for the current
target and cover 99% of all configure runs.
How about a config.site file?
Cheers,
Ralf
On Wed, Sep 15, 2010 at 10:04 AM, Ralf Wildenhues
ralf.wildenh...@gmx.de wrote:
Hi Bruce,
* Bruce Korb wrote on Wed, Sep 15, 2010 at 07:01:11PM CEST:
So, let's start that discussion again: let's make an installable
gnulib that basically does all the configure tests for the current
target
On Wed, Sep 15, 2010 at 12:01 PM, Bruce Korb bk...@gnu.org wrote:
So, let's start that discussion again: let's make an installable
gnulib that basically does all the configure tests for the current
target and cover 99% of all configure runs. If someone has
a strange configuration with extra
Sam Steingold wrote:
The only problem which gethostname module fixes is:
On mingw, this function has a prototype that differs from that
specified by POSIX, and it is defined only in the ws2_32 library.
why does it have such extensive dependencies? (sockets! errno!)
Look at the source code
Bruce,
Once upon a time, long ago and far away, I proposed a new
library, libcompat that more-or-less would make all target
platforms look pretty much identical. Lo and behold, over the
past decade, gnulib has gradually grown up to provide all
that infrastructure. The only problem with it
Hi Bruno,
On Wed, Sep 15, 2010 at 11:18 AM, Bruno Haible br...@clisp.org wrote:
Have you tried to follow the approach of
http://www.gnu.org/software/gnulib/manual/html_node/POSIX-Substitutes-Library.html?
I haven't, but I would like to hear about success or problems that
you encounter.
On 03/21/2010 01:45 PM, Matthias Bolte wrote:
2010/3/20 Eric Blake ebl...@redhat.com:
Since commit 4e86671a, gethostname failed to compile on mingw.
Gnulib's sys/socket.h includes winsock2.h, which then includes
unistd.h prior to declaring gethostname. Therefore, unistd.h
cannot replace
Since commit 4e86671a, gethostname failed to compile on mingw.
Gnulib's sys/socket.h includes winsock2.h, which then includes
unistd.h prior to declaring gethostname. The fix is to ensure
that our replacement unistd.h does not declare any replacements
until we are sure that winsock2.h
Eric Blake ebl...@redhat.com writes:
Since commit 4e86671a, gethostname failed to compile on mingw.
Gnulib's sys/socket.h includes winsock2.h, which then includes
unistd.h prior to declaring gethostname. The fix is to ensure
that our replacement unistd.h does not declare any replacements
On 03/22/2010 11:39 AM, Simon Josefsson wrote:
Eric Blake ebl...@redhat.com writes:
Since commit 4e86671a, gethostname failed to compile on mingw.
Gnulib's sys/socket.h includes winsock2.h, which then includes
unistd.h prior to declaring gethostname. The fix is to ensure
that our
Eric Blake ebl...@redhat.com writes:
On 03/22/2010 11:39 AM, Simon Josefsson wrote:
Eric Blake ebl...@redhat.com writes:
Since commit 4e86671a, gethostname failed to compile on mingw.
Gnulib's sys/socket.h includes winsock2.h, which then includes
unistd.h prior to declaring gethostname
On 03/22/2010 11:56 AM, Simon Josefsson wrote:
Typo on line 26.
Thanks, now it works. Any reason not to push this?
Only that I was not set up to reproduce the failure (cross-compiling
from cygwin was running into its own set of problems, because cygwin's
gcc-3 compiler mistakenly picks up
2010/3/22 Eric Blake ebl...@redhat.com:
Since commit 4e86671a, gethostname failed to compile on mingw.
Gnulib's sys/socket.h includes winsock2.h, which then includes
unistd.h prior to declaring gethostname. The fix is to ensure
that our replacement unistd.h does not declare any replacements
Eric Blake wrote:
+/* Get all possible declarations of gethostname(). */
+#if @UNISTD_H_HAVE_WINSOCK2_H@ !defined _GL_INCLUDING_WINSOCK2_H
+# define _GL_INCLUDING_WINSOCK2_H
+# include winsock2.h
+# undef _GL_INCLUDING_WINSOCK2_H
+#endif
Would it be possible to conditionalize
this patch and can confirm that this patch fixes the
gethostname compile issue on MinGW. Thanks.
I think the patch works for including sys/socket.h first, but what
happens if you include unistd.h or winsock2.h first? I think
there's still some circularities that need to be resolved
2010/3/20 Eric Blake ebl...@redhat.com:
Since commit 4e86671a, gethostname failed to compile on mingw.
Gnulib's sys/socket.h includes winsock2.h, which then includes
unistd.h prior to declaring gethostname. Therefore, unistd.h
cannot replace gethostname until winsock2.h is complete, also
that this patch fixes the
gethostname compile issue on MinGW. Thanks.
I think the patch works for including sys/socket.h first, but what
happens if you include unistd.h or winsock2.h first? I think
there's still some circularities that need to be resolved. That is,
gnulib's unistd.h needs to be smarter
Since commit 4e86671a, gethostname failed to compile on mingw.
Gnulib's sys/socket.h includes winsock2.h, which then includes
unistd.h prior to declaring gethostname. Therefore, unistd.h
cannot replace gethostname until winsock2.h is complete, also
fixing things if a .c includes unistd.h (or even
Since commit 4e86671a, gethostname failed to compile on mingw.
Gnulib's sys/socket.h includes winsock2.h, which then includes
unistd.h prior to declaring gethostname. Therefore, unistd.h
cannot replace gethostname until winsock2.h is complete.
* lib/sys_socket.in.h (includes): Set witness when
2010/3/20 Eric Blake ebl...@redhat.com:
Since commit 4e86671a, gethostname failed to compile on mingw.
Gnulib's sys/socket.h includes winsock2.h, which then includes
unistd.h prior to declaring gethostname. Therefore, unistd.h
cannot replace gethostname until winsock2.h is complete.
* lib
#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
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
Simon Josefsson wrote:
Looks fine to me, please push it.
Pushed.
Likewise, the 'sys_utsname' and 'uname' modules are pushed as well.
Bruno
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
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
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
Good. No one asks worse than 1.1 so the patch is okay.
Paolo
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
Hello everybody,
W32 has gethostname in ws2_32.dll. This is not detected by
gethostname.m4, and gethostname is inadvertently replaced by a function
that always returns an empty string.
The following patch fixes this for me. It works on Debian and with a
MinGW cross compiler. I tried to change
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
? Without
it, the gethostname module is broken on W32.
Regards,
Martin
, 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
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
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
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
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
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
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
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
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
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
/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
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
]@
+# 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
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
Bruno, the patch causes build failures on mingw:
./unistd.h:313: error: conflicting types for 'gethostname'
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/include/winsock2.h:635:
error: previous declaration of 'gethostname' was here
The problem is that the native
:
error: conflicting types for 'gethostname'
./unistd.h:313: error: previous declaration of 'gethostname' was here
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
Bruno Haible [EMAIL PROTECTED] writes:
Hi Simon,
Here's a proposed patch so that on platforms where gethostname() is missing
and substituted by gnulib, it is declared in unistd.h. OK to commit?
Hi. Yes, please do.
Note that this does not resolve the issue with mingw. On mingw, winsock2.h
Hi Simon,
Here's a proposed patch so that on platforms where gethostname() is missing
and substituted by gnulib, it is declared in unistd.h. OK to commit?
Note that this does not resolve the issue with mingw. On mingw, winsock2.h
declares gethostname() also - but it requires linking
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 ...
...
---
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
-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
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
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
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
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
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
/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
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
://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
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
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
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
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
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
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
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
://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
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
reimplements every DLL, so in particular Wine's
winsock is a different implementation that Windows winsock.
I checked real Windows behaviour here, and it does indeed require that
WSAStartup is called before gethostname. Otherwise, gethostname will
return -1 and doesn't populate the buffer. So
Here is an updated patch to get gethostname working under MinGW. It
uses the recent new gnulib module 'sockets'.
The module works like this: If the gethostname function is not found on
the system, it pulls in gethostname.c into the gnulib library, and
defines gethostname to rpl_gethostname
Brian Dessent [EMAIL PROTECTED] writes:
Simon Josefsson wrote:
3) Is there any chance that the #define gethostname rpl_gethostname and
replacement prototype of gethostname in gnulib's unistd.h will cause
problems? Consider that gethostname in winsock2.h is declared with
PASCAL calling
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
Simon Josefsson wrote:
For mingw, @GNULIB_GETHOSTNAME@ will be 0 since it has a gethostname (if
sys/socket.h is pulled in).
Huh? GNULIB_GETHOSTNAME is set to 1 by the gl_MODULE_INDICATOR([gethostname])
line, independently of platforms. It is 0 if the gethostname module is not
used.
Bruno
Hi Simon,
But this is still not complete: The doc/functions/gethostname.texi file
says that the problem is that mingw lacks a gethostname function.
This is not the case now, and I'm not sure it ever was. Where did that
information come from?
I wrote it: I saw that the .m4 macro only
Simon,
If we modify gethostname.m4 as I suggested, it will detect that mingw do
have a gethostname function, and consequently, the gethostname module is
not be needed.
Actually, the replacement function is not needed. But the piece of
configure.ac from modules/gethostname is expanded
Simon Josefsson [EMAIL PROTECTED] writes:
For reference, the Windows documentation for gethostname is:
http://msdn2.microsoft.com/en-us/library/ms738527.aspx
Thanks for the reference. So, to accomodate this function, we need a
rpl_gethostname that calls gethostname and accomodates
1
Bruno Haible [EMAIL PROTECTED] writes:
Hi Simon,
But this is still not complete: The doc/functions/gethostname.texi file
says that the problem is that mingw lacks a gethostname function.
This is not the case now, and I'm not sure it ever was. Where did that
information come from?
I
Bruno Haible [EMAIL PROTECTED] writes:
Simon Josefsson wrote:
For mingw, @GNULIB_GETHOSTNAME@ will be 0 since it has a gethostname (if
sys/socket.h is pulled in).
Huh? GNULIB_GETHOSTNAME is set to 1 by the gl_MODULE_INDICATOR([gethostname])
line, independently of platforms. It is 0
Bruno Haible [EMAIL PROTECTED] writes:
Simon,
If we modify gethostname.m4 as I suggested, it will detect that mingw do
have a gethostname function, and consequently, the gethostname module is
not be needed.
Actually, the replacement function is not needed. But the piece of
configure.ac
Bruno Haible [EMAIL PROTECTED] writes:
Simon Josefsson wrote:
@@ -21,6 +21,8 @@
#ifdef HAVE_UNAME
# include sys/utsname.h
+#else
+# include string.h
#endif
/* Put up to LEN chars of the host name into NAME.
While at it, you could make the patch complete: The function strncpy
Simon Josefsson [EMAIL PROTECTED] writes:
1) Modify gethostname module to look for gethostname in winsock2.h and
-lws2_32, similar to what's in getaddrinfo.m4. This will make gethostname
depend on sys/socket.h, just like getaddrinfo does.
2) Modify unistd module to make sure
This will simplify gethostname module improvements. Applied.
/Simon
diff --git a/ChangeLog b/ChangeLog
index 776e8ff..f52d4c2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
2008-01-17 Simon Josefsson [EMAIL PROTECTED]
+ * modules/gethostname-tests: New file
Bruno Haible [EMAIL PROTECTED] writes:
Simon Josefsson wrote:
2008-01-16 Simon Josefsson [EMAIL PROTECTED]
* lib/unistd.in.h: Include sys/socket.h, to get to winsock2.h,
which declares gethostname on MinGW.
* modules/unistd (Depends-on): Add sys_socket.
Half OK
Bruno Haible [EMAIL PROTECTED] writes:
+ /* mingw fails to declare gethostname in unistd.h. */
+ #if @GNULIB_GETHOSTNAME@ ((defined _WIN32 || defined __WIN32__) !
defined __CYGWIN__)
+ # include sys/socket.h
+ #endif
+
I tried your patch now, to take care of problem 1), but it doesn't
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
Building shishi on mingw leads to:
../../../src/shishi-0.0.34/gl/xgethostname.c: In function 'xgethostname':
../../../src/shishi-0.0.34/gl/xgethostname.c:61: warning: implicit declaration
of function 'gethostname'
According to
http://www.opengroup.org/onlinepubs/009695399/functions
1 - 100 of 107 matches
Mail list logo
