Sat 02 Sep 2017 02:38:51 AM UTC, comment #36:
I now see that jwe posted on bug-gnulib about this very issue a year ago
https://lists.gnu.org/archive/html/bug-gnulib/2016-06/msg00066.html
I'm not following the logic of the patch at the moment or understanding why that patch used to work but stopped working at some point. But now that we've found the underlying issue and fixed Octave's configure, we might be able to drop src/default-octave-1-gnulib.patch. I'll try to remember to look at that someday.
We might also want to patch stable-octave so that it DTRT, in case there is a need to build another stable release.
|
Sat 02 Sep 2017 01:23:13 AM UTC, comment #35:
Both work on both GUI and CLI for me with a 64 bit build
|
Fri 01 Sep 2017 02:03:28 AM UTC, comment #34:
In my cross-build log I can see that libgnu/gethostname.o is now included in the build, so this should work. Let's wait for someone to actually test both gethostname and uname on Windows, both GUI and CLI, to be sure.
|
Thu 31 Aug 2017 11:20:31 PM UTC, comment #33:
I checked in the following changeset so that we are no longer adding -lws2_32 to the LIBS variable in the configure script and instead rely entirely on gnulib to provide dirent.h and the related directory handling functions.
http://hg.savannah.gnu.org/hgweb/octave/rev/3a07616e660b
I haven't checked yet to see whether this avoids the problem with gethostname or uname on Windows systems, but I think it should.
|
Thu 31 Aug 2017 12:24:15 AM UTC, comment #32:
I think calling urlread should also work around this until we work out a proper fix.
|
Thu 31 Aug 2017 12:21:25 AM UTC, comment #31:
I found something that reliably makes uname.nodename to return the correct name even if the same Octave instance gave localhost before. It's a strange work around, but here it is: If I go to the menu and open News->Community News, then the next (and folllowing) calls to uname work.
|
Wed 30 Aug 2017 07:30:12 PM UTC, comment #30:
Confirmed here, building with the default --enable-windows-64, the gethostname test passes, so the gnulib wrapper is not used. Building with --disable-windows-64, the gethostname test fails, so the gnulib wrapper is used. And I think this all has to do with the order of libraries, different depedencies between the two different msys runtimes maybe, and the fact that we are adding -lws2_32 by default on Windows builds.
|
Wed 30 Aug 2017 07:17:46 PM UTC, comment #29:
Mike: Yes, if gnulib actually does correctly provide replacements for those functions on Windows systems now.
|
Wed 30 Aug 2017 06:12:31 PM UTC, comment #28:
I have log files from 4.2.0, 4.2.1, and 4.3.0+ now, I'll try a fresh build of 4.3.0+ for 32-bit Windows next and see if the same results follow.
|
Wed 30 Aug 2017 05:59:05 PM UTC, comment #27:
You might be right about 32-bit vs 64-bit, someone should try building each and compare results with the same mxe-octave state and the same octave revision.
Here's what your config.log says
and here's mine with the same test, only difference is compiling for 64-bit:
After the test fails on 32-bit, the followup test then passes:
The important difference appears to be that "-lws2_32" is appended to the end of the list of libraries.
|
Wed 30 Aug 2017 05:40:46 PM UTC, comment #26:
The compile for octave in mxe-octave puts a copy of the log in the octave etc directory, which also gets installed in when mxe-octave does.
Mine attached for 4.2.0 as a 7z file
(file #41700)
|
Wed 30 Aug 2017 05:40:09 PM UTC, comment #25:
Maybe, are you suggesting we delete that block "OS-specific test for dirent, opendir" and use gnulib if needed for those functions?
|
Wed 30 Aug 2017 05:35:13 PM UTC, comment #24:
Shouldn't we be using gnulib for opendir, closedir, readdir, and rewinddir? I think there may have been a time when gnulib didnot provide those functions for Windows, but now it seems that it does.
|
Wed 30 Aug 2017 05:25:28 PM UTC, comment #23:
If we can't figure this out we could always override the config cache like we do for other cross-compiled functions. Just add ac_cv_func_gethostname=no and gl_cv_w32_gethostname=yes to the set of variables we precondition the configure script with.
|
Wed 30 Aug 2017 05:22:07 PM UTC, comment #22:
Does anyone happen to have a full config.log file from an Octave 4.2.0 mxe-octave build when the gethostname wrapper was used? I would like to compare it to the checks that are in the config.log I just got. Unfortunately the only way to save the log file is to make a copy of tmp-stable-octave/octave-4.2.0/.build/config.log while the build is still going.
I now see that we have some code in configure.ac that adds -lws2_32 to the default LIBS when building for Windows systems, and it has been there for quite a while. That's why I would like to see the full compiler command line that 4.2.0 configure was running when it determined that gethostname does not exist.
|
Wed 30 Aug 2017 05:14:45 PM UTC, comment #21:
I also notice (and may be a redherring) that my 4.2.0 and 4.0.3 are box 32bit builds, whereas my 4.2.1 and dev are 64bit
comment #3 is also 32 vs 64.
|
Wed 30 Aug 2017 05:06:48 PM UTC, comment #20:
I just started a new mxe-octave build with stable-octave reverted to 4.2.0, everything else current. The build log looks the same as 4.2.1 to me:
So I don't see the same 4.2.0 configuration as you saw in your log file. Could this be due to some other change in mxe-octave, maybe the msys update or some other core library updates?
Anyway, I think this hints that gethostname works when we use the gnulib wrapper, but not when we don't. And maybe something has changed in the cross-build environment so that the function is now detected as being present and ok to use, but it still suffers from this bug of needing to call WSAStartup before use.
If I understand the gnulib gethostname.m4 module correctly, they are testing to see if gethostname exists with no extra libraries linked in, this is the normal POSIX case. Then they are testing if gethostname exists after linking with -lws2_32. If that's the case, then it uses the gnulib wrapper function to initialize gethostname correctly.
The problem appears to be that all configure tests are being run with -lws2_32 added to the default set of libs. This tricks configure into thinking that gethostname is a standard library function, no additional libs needed, and it doesn't use the wrapper.
So how or why is -lws2_32 being added to the default LIBS variable in the mxe-octave cross-build now, was that intentional, is there something we can do in mxe-octave to undo that? If not, is there a way to improve the gnulib check so that the wrapper is used when needed even if the default libs already include -lws2_32?
|
Wed 30 Aug 2017 03:27:57 PM UTC, comment #19:
4.0.3: both uname and gethostname work correctly in gui and cli.
4.2.0: both uname and gethostname work correctly in gui and cli.
4.2.1: uname works in gui, gethostname fails in gui, both fail in cli.
4.3.0: uname works in gui, gethostname fails in gui, both fail in cli.
|
Wed 30 Aug 2017 03:14:53 PM UTC, comment #18:
When you said you always get localhost in the CLI, is that with both of Octave's gethostname and uname functions?
I don't see a gethostname.o in my last stable-octave build log either (4.2.1 vs 4.2.1). We did update gnulib between 4.2.0 and 4.2.1, but I don't see any changes in gnulib that stand out having to do with gethostname or unistd.
|
Wed 30 Aug 2017 03:11:20 PM UTC, comment #17:
In 4.2.0 after tha fail, there is also a config line of:
checking for gethostname in winsock2.h and -lws2_32 ... yes
|
Wed 30 Aug 2017 03:06:15 PM UTC, comment #16:
I was about to say the same thing.
Looking at my build log for default octave, it doesn't appear to using gethostname.c from gnulib
looking at config.h for dev, I see:
checking for gethostname ... yes
for the installed etc/config.h from a 4.2.0 I see:
checking for gethostname ... no
|
Wed 30 Aug 2017 03:02:42 PM UTC, comment #15:
I don't think we are using the gnulib gethostname wrapper, I think configure is detecting that it is not necessary. I do not see a libgnu/.libs/gethostname.o in my last mxe-octave build log.
So it looks like we do need to somehow initiate the WSAStartup function before gethostname is called in the gnulib uname replacement. Maybe this should be reported to gnulib rather than making our own workaround?
|
Wed 30 Aug 2017 01:43:09 PM UTC, comment #14:
I created a quick test function grabbing parts of gnulib that might be useful to start with.
If I run it without the initialization of winsock, I get the localhost in CLI, but the GUI is ok.
If I run with winsock initialization, both work ok.
File attached.
(file #41697)
|
Wed 30 Aug 2017 12:46:44 PM UTC, comment #13:
Responding to comment #7: Mike, you are right that uname uses gethostname, but gnulib also provides a wrapper for that. But ultimately, it does call the Windows gethostname function from -lws2_32. So either that function is returning localhost, or it is failing. You could maybe use the debugger or insert some print statements to figure out which.
However, the info from comment #8 makes me think that gethostname is just failing, because "unknown" is what Octave's wrapper for gethostname (octave::sys::get_host_name) will return if the system's gethostname function fails.
So in any case, I don't see how this is an Octave bug unless we are calling gethostname incorrectly. Otherwise, we are calling a function that is supposed to return the hostname and it fails. Fix that function and Octave will do what you want.
We have updated gnulib since Octave 4.2 was released. Have there been any changes in gnulib that could cause this failure to happen more often now? The code for gnulib's gethostname replacement on Windows systems is:
It doesn't look like this has changed since 4.2. What happens in gl_sockets_startup? That function also appears to be unchanged since 4.2, but is it possible that it fails to initialize something such that gethostname subsequently fails?
Can you create a simpler example program that just uses the gnulib functions independently from Octave that also demonstrates this problem?
|
Wed 30 Aug 2017 12:16:07 PM UTC, comment #12:
On my win 10 machine, I am unable to replicate the local host issue (but do see the error message) when running the GUI link.
But when running CLI link, it (so far) always shows as localhost.
|
Wed 30 Aug 2017 04:22:56 AM UTC, comment #11:
Just now, opening octave it gave the right answer:
When closing octave and re-opening it (not opening a second instance at the same time), it gave localhost again. Restarting the computer doesn't always seem to get it to work again: It didn't work this time I tried (after getting localhost).
|
Tue 29 Aug 2017 09:47:49 PM UTC, comment #10:
Marshall - any further details? Are you able to get Octave to report the host name again after restarting or is it now always "localhost"? If you are still seeing the same issue with multiple instances running simultaneously, does the gethostname function exhibit the same behavior?
Avinoam - if you can't get uname or gethostname to report the host name correctly at all with your dev build, but it always works fine in 4.2, then that seems like a completely separate bug. Please do continue to investigate, but let's keep this bug focused on the host name sometimes being right and sometimes being wrong in 4.2.
|
Sun 27 Aug 2017 05:55:36 PM UTC, comment #9:
I have opened a separate bug (bug #51869) for msg not being an empty string (comment #8)
|
Fri 25 Aug 2017 10:49:54 PM UTC, comment #8:
Checking again, I saw that in version 4.2.1 under Win-10,
I always get the correct nodename, and it does not depend on the number of Octave instances (I have tried 1-5).
In 4.3.0+ (dev) I get always "localhost", and again, it does not depend on the number of Octave instances.
In the help of uname I see:
"If successful, ERR is 0 and MSG is an empty string."
On both 4.2.1 & dev, ERR is 0, but MSG is not empty.
There is still a regression problem:
On 4.2.1
On dev:
|
Fri 25 Aug 2017 04:22:40 PM UTC, comment #7:
Like I said before, the msg only matters if err is non-zero.
So this indicates that the uname function in gnulib is not returning an error. When I look in the code for uname on Windows, it calls the gethostname function to fill in the nodename field, which is part of the Windows API.
If the Windows gethostname function returns with an error, it fills nodename with the string "localhost". So that's as much as I can tell at this point.
Can you also try gethostname with multiple running instances of Octave, along with uname, to see if it has the same behavior?
Can you not get Octave to report the correct host name at all now?
Avinoam - was your test also with multiple instances of Octave running at the same time? I don't think this is a regression since Marshall sees both good and bad results with version 4.2
|
Fri 25 Aug 2017 02:05:57 PM UTC, comment #6:
I got 'localhost' again. It happened when I opened a second instance of Octave. The first instance continued to give the correct name, but the second and later instances always gave 'localhost' even after closing all open Octave programs. Now I only get 'localhost' again even after hibernating or completely restarting the computer.
But err and msg are the same whether it gives the correct response or not.
|
Fri 25 Aug 2017 01:53:59 PM UTC, comment #5:
Of course, since reporting the bug, I haven't been able to get the 'localhost' response, but I had waited to report it until both machines were giving 'localhost'. Both machines are on 4.2.1.
I do see 'uname not supported on this system' for the msg return argument when it is successful.
|
Fri 25 Aug 2017 06:26:46 AM UTC, comment #4:
Note also that if the result of
from oct-uname.cc, err = 0, the msg field is not changed, and we still get the original error message
from oct-uname.h.
|
Fri 25 Aug 2017 05:38:34 AM UTC, comment #3:
Sorry.
With 4.2.1
On dev branch:
So, there seems to be a regression problem here.
|
Fri 25 Aug 2017 05:32:34 AM UTC, comment #2:
On Win 7
|
Thu 24 Aug 2017 12:23:35 AM UTC, comment #1:
Please try to figure out what set of conditions cause this to happen.
Also try calling uname with 3 output arguments
If err is nonzero, then msg should describe the error.
If err is zero and you still get localhost, then this is probably a failure in the gethostname function on Windows, which is outside of the scope of Octave to fix. If you can come up with a reproducible test case, it might be worth reporting to gnulib. We can help you debug this and work up a minimal test case for gnulib, but other than that it's probably not something Octave can do anything about.
|
Wed 23 Aug 2017 07:33:37 PM UTC, original submission:
I have been using uname.nodename recently to run different options depending on the computer the code is running on. I have found that sometimes it gives the pc name correctly, but other times it only gives "localhost". I can't track down yet what causes it, whether it is how Octave is started, or some other network settings... I have seen this on two different machines where it correctly gave the pc name, but then later only gave "localhost".
|