#422 Bit number (32 bit or 64 bit) and OS name of working gnuplot to GPVAL_...

[Tatsuro MATSUOKA]

Hello

I have discussed with Shigeharu Takeno the way to get information of working gnuplot
1. 32 bit or 64 bit
2. working OS name (but not build OS name)

We know Build OS (in reality is is not as shown below) information is omitted at the change

2013-02-26 Ethan A Merritt merritt@u.washington.edu

src/show.c src/version.c src/version.h src/plot.c:
Remove the "Build system" line from the version information shown on
entry. It never did report the build system, only the system reported
by the machine it was currently running on. Could be replaced if
someone wants to figure out a generic way to have autoconf fill in the
OS definition in syscfg.h

The omitted information is just we want to know.
We talked that it is very convenient to get above 1. and 2. information as GPVAL_ variables like GPVAL_OSBITNUM, and GPVAL_OSNAME.

How do the developer think about that?

Tatsuro

[Ethan Merritt]

What is the information needed for?

I do not know the situation on Windows, but on linux it is complicated.
There is not a clear break between 32 and 64 bit support.

On linux the program may be compiled 32-bit even if the operating system is 64-bit. And for some purposes like LFS (large file support) the program may support 64-bit access even if the operating system is 32-bit.

The command uname -i reports the instruction set used in the linux kernel (for example i686 or x86_64), but does not tell you whether that same instruction set was used to compile a particular program.

The command file /usr/local/bin/gnuplot reports the architecture used to compile and link the executable (for example "ELF 32-bit LSB executable, Intel 80386") but does not tell you whether it is running on a 32- or 64- bit operating system.

[Tatsuro MATSUOKA]

Thanks for reply

First I tell situation on windows

For windows, on 64 bit OS, both 32bit and 64 bit applications can run, but on 32 OS, only 32 bit applications can work.

For 4.6.7, start up Screen tells on gnuplot for windows
Note that both binaries are built on 64 bit windows.
But 32 bit binary is built with 32 bit mingw toolkit and 64 bit binary is built with 64 bit mingw toolkit.

64 bit version gnuplot on windows 7 64bit

   G N U P L O T
   Version 4.6 patchlevel 7    last modified Apr 2015
   Build System: MS-Windows 64 bit

32 bit version gnuplot on windows 7 64bit

   G N U P L O T
   Version 4.6 patchlevel 7    last modified Apr 2015
   Build System: MS-Windows 32 bit

Therefore situation is simple.

The request on this ticket is Shigeharu's one. So I cannot surely say but he might want to get information whether gnuplot is working in 32 or 64 bit.

I will confirm this point from Shigeharu.

Tatsuro

[Shigeharu TAKENO]

The reasons that I want to know the OS information in gnuplot script and on command window are the followings:

For ms-win,
1) I want to know the binary version simply,
2) It may help us to install the newer version,
3) GPVAL_* may be used on "if" statements if there are some differences between 32bit version and 64bit version,
4) We can add the information to bug reports when we send it.

For unix,
5) if we can know the OS information by GPVAL* variable, we can use it on "if" statements in the gnuplot script which we run on several computers.

In fact, I use several OS ordinarily, FreeBSD, Solaris, and MS-Windows.

[Ethan Merritt]

I still do not understand exactly what information you want to store in a GPVAL* variable.

On unix, which of these do you want?

- 'uname -i" for the machine the executable was built on

- 'uname -i" for the machine the executable is running on

- elf header information for the current executable 
  https://en.wikipedia.org/wiki/Executable_and_Linkable_Format
  The "file" command reports this but I don't know how to query
  it from inside a program.

- something else such as support for 64-bit offsets?  large files?  
  sizeof(void *)? sizeof(int)?

[Shigeharu TAKENO]

I am sorry, but I don't need it strongly.
I want the information to distinguish computers gnuplot is running on.
Mainly, it is enough to show the OS name (uname -s) and
architecture name (uname -p).

Normally, the information of running machine may be better than
the one of build machine. But, for the the Windows binary,
I want to know whether it is the 32bit-version or not.

In some case, the value such as sizeof(int) or endian may be needed,
but I don't need it now.

By the way, the result of "uname -i" depends on OS.
'uname -i' returns the name of kernel configuration file (GENERIC)
on FreeBSD, and it returns platform name (SUNW,Ultra-5_10) on Solaris.
cf. https://en.wikipedia.org/wiki/Uname

I don't know the value of ELF header in the program, too.

[Tatsuro MATSUOKA]

To distinguish whether application is working on 32 bit or 64 bit on windows, you can use dumpbin /headers.

The file dumpbin.exe can be obtained it if you install Microsoft visual studio (Express Edition is enough.)

See:
https://msdn.microsoft.com/en-us/library/c1h23y6c.aspx

[Ethan Merritt]

The attached patch teaches gnuplot to fill in the variables
GPVAL_SYSNAME (e.g. linux)
GPVAL_MACHINE (e.g. 686 x86_64)
GPVAL_BITS (32 or 64)

The first two variables are filled in using the system call uname(),
and therefore they only work if HAVE_UNAME is defined.
Probably windows does not supply uname(), but I am not sure.

Please report back if Windows does supply uname(), or suggest
a different system call to use on Windows.

[Shigeharu TAKENO]

Please modify your patch

if (uname(&uts))

to

if (uname(&uts) < 0)

because Solaris' uname() returns 1 (manual says "non-negative value") when succeeded.

FreeBSD's uname() returns 0 when it succeeded.

[Tatsuro MATSUOKA]

Linux
* I have confirmed the change works on Ubuntu 64 bit and 32 bit.

Windows
* As you expected, the change does not work.

x86_64-w64-mingw32-gcc -c -I/c/Programs/gplibs64_gcc492/include -fno-keep-inline-dllexport -D__USE_MINGW_ANSI_STDIO -DDEFAULTTERM=\"wxt\" -DHAVE_UNAME -O2 -pipe -I. -I../../src -I../../term/ -D_Windows -DHAVE_CONFIG_H -DPIPES -DWGP_CONSOLE -DCONSOLE_SWITCH_CP -DGNUPLOT_SHARE_DIR=\"share\" -DDEVELOPMENT_VERSION -DUSE_MOUSE=1 -DWIN_IPC -I/c/PROGRA~2/HELPWO~1/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG -DHAVE_GD_JPEG -DHAVE_GD_TTF -DHAVE_CAIROPDF -DWXWIDGETS -DQTTERM -DQT_NO_OPENGL -DHAVE_LUA -DHAVE_LIBCACA -DHAVE_ICONV -DHAVE_LIBCERF -DNEED_CEXP -MMD -MT 'eval.$(O)' -MF eval.d -o eval.co ../../src/eval.c
../../src/eval.c: In function 'fill_gpval_sysinfo':
../../src/eval.c:1012:25: fatal error: sys/utsname.h: No such file or directory
#include <sys/utsname.h>
^
compilation terminated.

As alternative way, I need time to find way.

[Tatsuro MATSUOKA]

I have collected information how to get GPVAL_SYSNAME (e.g. linux) GPVAL_MACHINE (e.g. 686 x86_64) on native windows.
(The way get GPVAL_BITS information is not related OS type. (outside #ifdef HAVE_UNAME))
I have a question how to implement the functionality on windows.(written in end part of the post.)

Before talking about native windows, I would like talk about cygwin
On 32 bit cygwin (working on 64 bit win 7)

GPVAL_SYSNAME CYGWIN_NT-6.1-WOW
GPVAL_MACHINE i686
GPVAL_BITS 32

On 64 bit cygwin (working on 64 bit win 7)

GPVAL_SYSNAME CYGWIN_NT-6.1
GPVAL_MACHINE x86_64
GPVAL_BITS 64

NT-6.1 means windows 7 (or Windows Server 2008 R2)

WOW means here WOW64 which is the system to run 32bit application on 64 bit windows OS. I have not executed patched gnuplot on 32 bit cygwin on 32 bit windows. But perhaps on 32 bit cygwin on 32 bit windows, value of GPVAL_SYSNAME is CYGWIN_NT-(version) (no WOW).

Now I talk about output info for windows.
I would like to set the value in the same way on cygwin.

Question

For GPVAL_MACHINE, 32 bit application on 64 bit windows works on WOW64 and processor uses only x86 instruction. Thus as in the case of cygwin, I would like to set GPVAL_MACHINE of 32 bit gnuplot working on 64 bit windows to i686 for consistency. Is this OK?

#
# Weekend I will have a trip and on next week I will have hard jobs.
# The code upload will be done after that.

[Tatsuro MATSUOKA]

I have made a patch for windows.
It should be applied after gpval_uname.patch is applied.
To get windows OS version, I used an external header file (findversion.h) from
https://bitbucket.org/AnyCPU/findversion

First I planned to use "GetVersionEx" function in windows api but it deprecated on windows 8.1 and Visual Studio 2013.
So I would like to use findversion.h for windows version determination.
This is an additional dependency so that it may be effective when HAVE_FINDVERSION_H is defined which will be defined in Makefile to add -DHAVE_FINDVERSION_H to CFLAGS.

For architecture determination, I used "GetSystemInfo" windows API.
I refereed here.
http://www.codeproject.com/Tips/117594/Getting-Processor-architecture-in-x-and-x-bit

To distinguish cpu among i386, i486, i586, or i686 is difficult,
GPVAL_MACHINE prints x86 for intel 32 bit (working) architecture.

For win7 64 bit

32bit binary

GPVAL_SYSNAME Windows_NT-6.1
GPVAL_MACHINE x86
GPVAL_BITS 32

64bit binary

GPVAL_SYSNAME Windows_NT-6.1
GPVAL_MACHINE x86_64
GPVAL_BITS 64

I have examined on win 8.1 and XP. Version numbers are printed as expected
(6.3 win 8.1, 5.1 win XP).

WOW64 detection is not implemented because of simplicity. If it will be better to be implemented I will consider the implement.

[Tatsuro MATSUOKA]

https://bitbucket.org/AnyCPU/findversion

I have attached cloned source.

[Tatsuro MATSUOKA]

I have discussed for this matter with Shigeharu Takeno.
I have modified the patch.

If flag "HAVE_FINDVERSION_H" is not set, GPVAL_SYSNAME mere returns "Windows" but not unimplemented.

[Tatsuro MATSUOKA]

I have confirmed the patches are included into the cvs tree and the cvs source works on windows, cygwin and ubuntu. Thanks!

[Bastian Märkisch]

findversion.h is simple and short enough and has a MIT license. So it's imho best to include it in CVS. There are two more places where we use GetVersionEx which could also use this macro.

[Bastian Märkisch]

On second thought, that might not be the best idea. First of all you cannot include this as is in several C files, as you get "multiple definition" errors. Second, and more importantly, [bugs:#1851] proofs that the work-around just worked for Windows 8.1 but now fails on Windows 10, see also Targeting your application for Windows on MSDN.

Since the patch attached to [bugs:#1851] makes GetVersionEx work again on Windows up to version 10, we should just rely on that everywhere. MS for some reason seems to be destined to make it difficult to determine the Windows version in a program.