Re: gethostname on 64-bit Windows

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

Re: gethostname on 64-bit Windows

- 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_gethostnam

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 diff -uNr

RE: Trouble with gethostname and mingw-w64 x86_64

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

Trouble with gethostname and mingw-w64 x86_64

h of how gnulib 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 co

RE: gethostname on HP-NonStop

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

Re: gethostname on HP-NonStop

; > +#ifdef __TANDEM /* HP-Nonstop has gethostname() in */ > +#include > +/* and MAXHOSTNAMELEN in */ > +#include > +#undef HOST_NAME_MAX > +#define HOST_NAME_MAX MAXHOSTNAMELEN > +#endif This goes in the right direction. HOST_NAME_MAX already being dealt with, this i

RE: gethostname on HP-NonStop

gethostname() in */ +#include +/* and MAXHOSTNAMELEN in */ +#include +#undef HOST_NAME_MAX +#define HOST_NAME_MAX MAXHOSTNAMELEN +#endif + #if !defined _GL_UNISTD_H && !defined _GL_INCLUDING_WINSOCK2_H #define _GL_UNISTD_H Fixes the HOST_NAME_MAX problem too... -Original Message--

RE: gethostname on HP-NonStop

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: > gethostn

Re: gethostname on HP-NonStop

Joachim Schmitz wrote: > gethostname missing (resp. not found, it is available and declared in > ), 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 /

Re: module gethostname

Bruno, On Thu, Sep 16, 2010 at 5:13 PM, Bruno Haible wrote: >> now I get a linking error: >> >> Warning: resolving _gethostname by linking to _gethostn...@8 >> Use --enable-stdcall-fixup to disable these warnings >> Use --disable-stdcall-fixup to disable these fixups >> libgnu_cl.a(sockets.o): In

Re: module gethostname

Sam, > now I get a linking error: > > Warning: resolving _gethostname by linking to _gethostn...@8 > Use --enable-stdcall-fixup to disable these warnings > Use --disable-stdcall-fixup to disable these fixups > libgnu_cl.a(sockets.o): In function `close_fd_maybe_socket': > /cygdrive/c/sds/dev/curr

Re: module gethostname

Bruno Haible wrote: I am now getting undefined reference to `_gethostname_used_without_requesting_gnulib_module_gethostname' This indicates that you have included gnulib , are using gethostname(), and have not asked for the gnulib module 'gethostname'. - If you want

Re: module libposix (was: module gethostname)

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,

Re: module libposix (was: module gethostname)

Hi Bruno, > On Wed, Sep 15, 2010 at 11:18 AM, Bruno Haible wrote: >> >> Have you tried to follow the approach of >>  ? >> I haven't, but I would like to hear about success or problems that >> you encounter. 1. A

Re: module libposix (was: module gethostname)

Hi Bruno, On Wed, Sep 15, 2010 at 11:18 AM, Bruno Haible wrote: > > Have you tried to follow the approach of >  ? > I haven't, but I would like to hear about success or problems that > you encounter. That should

Re: module gethostname

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 wi

Re: module gethostname

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! er

Re: module gethostname

On Wed, Sep 15, 2010 at 12:01 PM, Bruce Korb 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 libraries

Re: module gethostname

On Wed, Sep 15, 2010 at 10:04 AM, Ralf Wildenhues 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 and cover 99% of

Re: module gethostname

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

Re: module gethostname

On Wed, Sep 15, 2010 at 9:34 AM, Paul Eggert 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 that gnuli

Re: module gethostname

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 that gnulib has too many dependencies and I try to remove them when I ca

module gethostname

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

[PATCH] gethostname: further tweaks

* lib/unistd.in.h (includes): Only worry about if we are overriding gethostname. Suggested by Bruno Haible. Signed-off-by: Eric Blake --- > Would it be possible to conditionalize this with > #if @GNULIB_GETHOSTNAME@ > like it was before? In a package that has nothing to do with >

Re: [PATCHv4] gethostname: fix build on mingw

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 > +# undef _GL_INCLUDING_WINSOCK2_H > +#endif > Would it be possibl

Re: [PATCHv4] gethostname: fix build on mingw

2010/3/22 Eric Blake : > 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 replacemen

Re: [PATCHv4] gethostname: fix build on mingw

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

Re: [PATCHv4] gethostname: fix build on mingw

Eric Blake writes: > On 03/22/2010 11:39 AM, Simon Josefsson wrote: >> Eric Blake writes: >> >>> Since commit 4e86671a, gethostname failed to compile on mingw. >>> Gnulib's sys/socket.h includes winsock2.h, which then includes >>> unistd.h prior

Re: [PATCHv4] gethostname: fix build on mingw

On 03/22/2010 11:39 AM, Simon Josefsson wrote: > Eric Blake 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 e

Re: [PATCHv4] gethostname: fix build on mingw

Eric Blake 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 replacemen

[PATCHv4] gethostname: fix build on mingw

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

Re: [PATCH] gethostname: fix build on mingw

On 03/21/2010 01:45 PM, Matthias Bolte wrote: > 2010/3/20 Eric Blake : >> 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 >

Re: [PATCH] gethostname: fix build on mingw

2010/3/20 Eric Blake : > 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, als

Re: [PATCH] gethostname: fix build on mingw

2010/3/20 Eric Blake : > 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, als

Re: [PATCH] gethostname: fix build on mingw

g00183.html >>> >> >> I tested this patch and can confirm that this patch fixes the >> gethostname compile issue on MinGW. Thanks. > > I think the patch works for including first, but what > happens if you include or first?  I think > there's still

[PATCH] gethostname: fix build on mingw

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 (or even )

[PATCH] gethostname: fix build on mingw

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 (or even )

Re: [PATCH] gethostname: fix build on mingw

ted this patch and can confirm that this patch fixes the > gethostname compile issue on MinGW. Thanks. I think the patch works for including first, but what happens if you include or first? I think there's still some circularities that need to be resolved. That is, gnulib's unist

Re: [PATCH] gethostname: fix build on mingw

2010/3/20 Eric Blake : > 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 co

[PATCH] gethostname: fix build on mingw

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

Re: gethostname, socket need startup code

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, socket need startup code

Bruno Haible 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 im

Re: gethostname on Windows

ngw, 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 host

Re: gethostname, socket need startup code

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

Re: gethostname on Windows

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 @@ g

Re: gethostname on Windows

.422184a 100644 --- a/lib/gethostname.c +++ b/lib/gethostname.c @@ -76,6 +76,9 @@ gethostname (char *name, size_t len) /* Get winsock2.h. */ #include +/* Get INT_MAX. */ +#include + /* Get set_winsock_errno. */ #include "w32sock.h"

Re: gethostname, socket need startup code

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 #include #include i

Re: gethostname, socket need startup code

On 08/02/2009 04:45 PM, Bruno Haible wrote: 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, socket need startup code

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

Re: gethostname on Windows

msvc-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 geth

Re: gethostname inadvertently replaced on W32

Martin Lambers 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 t

Re: gethostname inadvertently replaced on W32

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

Re: gethostname inadvertently replaced on W32

gt; 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

Re: gethostname inadvertently replaced on W32

? Without it, the gethostname module is broken on W32. Regards, Martin

Re: gethostname inadvertently replaced on W32

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 a

gethostname inadvertently replaced on W32

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

Re: gethostname on Windows

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 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 geth

Re: gethostname on Windows

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. > &g

gethostname on Windows

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 valu

Re: gethostname: LGPL -> LGPLv2+

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 r

Re: gethostname: LGPL -> LGPLv2+

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 obje

gethostname: LGPL -> LGPLv2+

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 gnu

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

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

Re: gethostname on mingw, LIBS

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 GetCom

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

f [EMAIL PROTECTED]@ > +# if HAVE_WINSOCK2_H > +# /* Bypass bad prototype for gethostname(). */ > +# include > +# undef gethostname > +# define gethostname rpl_gethostname > +# endif > extern int gethostname(char *name, size_t len); > # endif > +#elif @UNI

Re: gethostname on mingw, LIBS

Hi Simon, > > Note that this does not resolve the issue with mingw. On mingw, > > 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 > easi

Re: gethostname fix for mingw

seek.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

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

e/winsock2.h:635: > 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 libr

Re: declare gethostname in unistd.h

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 proble

Re: declare gethostname in unistd.h

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 . OK to commit? Hi. Yes, please do. > Note that this does not resolve the issue with mi

declare gethostname in unistd.h

Hi Simon, Here's a proposed patch so that on platforms where gethostname() is missing and substituted by gnulib, it is declared in . OK to commit? Note that this does not resolve the issue with mingw. On mingw, declares gethostname() also - but it requires linking with -lws2_32, right

Re: gethostname

-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 solar

Re: gethostname

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,' | so

Re: gethostname

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-po

Re: gethostname

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 f

Re: gethostname

Simon Josefsson wrote: > 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

Re: gethostname

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

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 attemp

Re: gethostname

Ben Pfaff wrote: 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. Sounds right, and not really ;-). I was trying to get a bunch of stuff work

Re: gethostname

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

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 u

Re: gethostname

nctions/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 un

Re: gethostname

p://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 sho

Re: gethostname

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? >>> &g

Re: gethostname

lly systems without uname & , 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

Re: gethostname

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 Ha

Re: gethostname

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 Haib

Re: gethostname

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

Re: gethostname

695399/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 mod

Re: gethostname

on 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,unam

Re: gethostname

gt; 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-P

Re: gethostname

hese 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.

gethostname

gnulib/lib/gethostname.c says: #ifdef HAVE_UNAME # include #endif 1. why aren't you testing for HAVE_SYS_UTSNAME_H instead? 2. are there really systems without uname & , given that these are in posix? http://www.opengroup.org/onlinepubs/009695399/functions/uname.html

Re: (x)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 wi

Re: (x)gethostname

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 conventions, so the pro

Re: (x)gethostname

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_g

Re: (x)gethostname

behaviour of Windows by testing on > Wine. You know that Wine 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. Otherw

Re: (x)gethostname

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 func

  1   2   >