uname function in MSYS

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

uname function in MSYS

Damon Register
I am attempting to compile gnu-ghostscript using mingw-msys.  The configure part
was fairly easy but make dies with a error about not finding sys/utsname.h.  I see
that this is needed because one module uses the uname() function.  So far I haven't
found the header file though I have found the function exists within msys-1.0.dll.
 From http://www.mingw.org/wiki/HOWTO_Create_an_MSYS_Build_Environment
I see that this is where I might expect to find uname.

I downloaded some source for msysCORE  and I see the file uname.cc and sys/utsname.h
What I don't see is how I can have a mingw built app use this function.  Am I correct
in thinking that this header and function are not available to use from within a
standard (not built by me) mingw-msys environment?  What do I have to do to be
able to use uname?

Damon Register

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: uname function in MSYS

Ralph Engels
I had some succes using the cygwin port (part of my own msys package)
the hard part is compiling tiff as you need to do that one as a
mingw/msys cross. The cygwin port does not use the external versions of
the image libraries but i had to reenable that part to build it. The
built ghostscript works fine though :)

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: uname function in MSYS

Earnie Boyd
In reply to this post by Damon Register
On Thu, Jun 7, 2012 at 10:03 AM, Damon Register
<[hidden email]> wrote:

> I am attempting to compile gnu-ghostscript using mingw-msys.  The configure part
> was fairly easy but make dies with a error about not finding sys/utsname.h.  I see
> that this is needed because one module uses the uname() function.  So far I haven't
> found the header file though I have found the function exists within msys-1.0.dll.
>  From http://www.mingw.org/wiki/HOWTO_Create_an_MSYS_Build_Environment
> I see that this is where I might expect to find uname.
>
> I downloaded some source for msysCORE  and I see the file uname.cc and sys/utsname.h
> What I don't see is how I can have a mingw built app use this function.  Am I correct
> in thinking that this header and function are not available to use from within a
> standard (not built by me) mingw-msys environment?  What do I have to do to be
> able to use uname?
>

This really belongs in mingw-users list.  You need to port your
application to Windows such that it isn't requiring these POSIX
functions.  I know ghostscript is available for Windows so perhaps the
configure just needs to enable/disable some macro.

The documentation you point to is providing you a means to create an
environment to develop MSYS and creating applications that use the
msys-1.0.dll which is a POSIX runtime.  I don't think that is what you
are trying to accomplish.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: uname function in MSYS

Damon Register-4
On 6/7/2012 1:11 PM, Earnie Boyd wrote:
> This really belongs in mingw-users list.  You need to port your
Sorry I guess I wasn't very clear with my post.  There are really
two parts to what I want to know:
1. I want to build ghostscript with mingw/msys.
2. I want to tamper with an msys tool

While building ghostscript might belong in the mingw-users list, I believe that
tampering with msys might belong here.  I am aware of what I find on http://www.mingw.org/
"does not, and never will, attempt to provide a POSIX runtime environment for POSIX
application deployment on MS-Windows"
Since uname is one of those posix function (right?), I can only guess that
someone decided it was one of those few exceptions that are needed.

> application to Windows such that it isn't requiring these POSIX
In a way that is what I would like to do but I think I would like to do a
few steps before I get to that point.

> functions.  I know ghostscript is available for Windows so perhaps the
> configure just needs to enable/disable some macro.
I see from their documentation that there are several ways to build for Windows
including MSVC and cygwin but mingw/msys is  not one of the methods.  I would like
to take a shot at making it work with mingw/msys.

> The documentation you point to is providing you a means to create an
> environment to develop MSYS and creating applications that use the
> msys-1.0.dll which is a POSIX runtime.  I don't think that is what you
> are trying to accomplish.
yes and no.  I hope to do the actual building of ghostscript with the normal mingw/msys
setup, as in uname -s reports MINGW32_NT-5.1

The reason I got sidetracked with trying to build with the msys environment
(uname -s reports MSYS) is because of a problem I ran into while trying to build
ghostscript.  The build process uses the uname command to get some information for
the build.  uname options -p and -i return unknown.  From all that I could find with
Google, this seems to be an old problem and I get the impression that it won't get fixed
either due to lack of interest or perhaps there is some compelling reason to not tamper with
that.  I want to tamper with the uname command so I have my own custom uname.  This almost
certainly means that I have to build msys source with the msys toolset.

I followed the instructions at http://www.mingw.org/wiki/HOWTO_Create_an_MSYS_Build_Environment
as well as I could understand them.  I did these things

mingw-get install msys-dvlpr
msys.bat MSYS

with that  I was able to build msyscore and coreutils.  For me this is a fairly big
accomplishment.  I even tried adding a printf("hello world\n") to the uname.cc file
just as an exercise to prove that I was getting the newly build uname.exe.

Now that I have done that, I would like to make a small change to my customized uname
to read an environment variable just as does the uname function in uname.c.  I want to
use the windows functino GetEnvironmentVariable just as does the uname function in
uname.cc.  The problem I have now is that when I try to rebuild coreutils with the
tampered uname.c, if fails with reference to unknown GetEnvironmentVariable.  This is
no suprise since almost certainly I don't have it link with the necessary library
that contains GetEnvironmentVariable.  I tried looking at the makefile for msyscore
but I could not figure out what I need to do for the coreutils makefile.

Can you please tell me what I would have to do to the coreutils makefile to make it
link to the library containing GetEnvironmentVariable?

When I first posted this I was wondering why I got no response.  The list seemed rather
dead.  Finally I realized that the address I had used to post this seems to have been
unsubscribed.  I tried re-subscribing but didn't even get the confirmation message.
perhaps that address is bouncing all the e-mail from this list?  For now I guess
I have to use this other address.

Damon Register


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: uname function in MSYS

Earnie Boyd
On Sun, Jun 10, 2012 at 8:28 PM, Damon Register <[hidden email]> wrote:

> On 6/7/2012 1:11 PM, Earnie Boyd wrote:
>> This really belongs in mingw-users list.  You need to port your
> Sorry I guess I wasn't very clear with my post.  There are really
> two parts to what I want to know:
> 1. I want to build ghostscript with mingw/msys.
> 2. I want to tamper with an msys tool
>
> While building ghostscript might belong in the mingw-users list, I believe that
> tampering with msys might belong here.  I am aware of what I find on http://www.mingw.org/
> "does not, and never will, attempt to provide a POSIX runtime environment for POSIX
> application deployment on MS-Windows"
> Since uname is one of those posix function (right?), I can only guess that
> someone decided it was one of those few exceptions that are needed.
>

Since MSYS is Cygwin with changes, that someone was Cygwin which
provides a POSIX emulation runtime library.

>> application to Windows such that it isn't requiring these POSIX
> In a way that is what I would like to do but I think I would like to do a
> few steps before I get to that point.
>
>> functions.  I know ghostscript is available for Windows so perhaps the
>> configure just needs to enable/disable some macro.
> I see from their documentation that there are several ways to build for Windows
> including MSVC and cygwin but mingw/msys is  not one of the methods.  I would like
> to take a shot at making it work with mingw/msys.
>

MSYS is a fork of an older version 1.3.x of Cygwin.  The goal of MSYS
is to provide a build environment for MinGW such as to be able to
execute configure, make and make install.  Anything beyond that is
gravy.  So, you should be able to follow the Cygwin methods and build
a MSYS dependent ghostscript assuming it doesn't require the newer
revisions of GCC and Cygwin.

>> The documentation you point to is providing you a means to create an
>> environment to develop MSYS and creating applications that use the
>> msys-1.0.dll which is a POSIX runtime.  I don't think that is what you
>> are trying to accomplish.
> yes and no.  I hope to do the actual building of ghostscript with the normal mingw/msys
> setup, as in uname -s reports MINGW32_NT-5.1
>

But in this OS realm the POSIX uname function isn't available, you'll
need to use Windows methods to get the equivalent information.

> The reason I got sidetracked with trying to build with the msys environment
> (uname -s reports MSYS) is because of a problem I ran into while trying to build
> ghostscript.  The build process uses the uname command to get some information for
> the build.  uname options -p and -i return unknown.  From all that I could find with
> Google, this seems to be an old problem and I get the impression that it won't get fixed
> either due to lack of interest or perhaps there is some compelling reason to not tamper with
> that.  I want to tamper with the uname command so I have my own custom uname.  This almost
> certainly means that I have to build msys source with the msys toolset.
>

No, it really means you need to port it to use Windows methods.


> I followed the instructions at http://www.mingw.org/wiki/HOWTO_Create_an_MSYS_Build_Environment
> as well as I could understand them.  I did these things
>
> mingw-get install msys-dvlpr
> msys.bat MSYS
>
> with that  I was able to build msyscore and coreutils.  For me this is a fairly big
> accomplishment.  I even tried adding a printf("hello world\n") to the uname.cc file
> just as an exercise to prove that I was getting the newly build uname.exe.
>
> Now that I have done that, I would like to make a small change to my customized uname
> to read an environment variable just as does the uname function in uname.c.  I want to
> use the windows functino GetEnvironmentVariable just as does the uname function in
> uname.cc.  The problem I have now is that when I try to rebuild coreutils with the
> tampered uname.c, if fails with reference to unknown GetEnvironmentVariable.  This is
> no suprise since almost certainly I don't have it link with the necessary library
> that contains GetEnvironmentVariable.  I tried looking at the makefile for msyscore
> but I could not figure out what I need to do for the coreutils makefile.
>
> Can you please tell me what I would have to do to the coreutils makefile to make it
> link to the library containing GetEnvironmentVariable?

Yes, GetEnvironmentVariable is a Windows API and which isn't intended
to be used with the MSYS/Cygwin runtime.  However, the emulation must
use it so there are special instructions for adding the appropriate
libraries when MSYS itself is built.

I think your best bet will be to port ghostscript to windows methods.
I think that it has been done already, maybe you just need to follow
the correct set of documentation.  Or maybe you need to modify the
configure methods to consider MinGW and Windows.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: uname function in MSYS

Damon Register
In reply to this post by Earnie Boyd
On 6/7/2012 1:11 PM, Earnie Boyd wrote:
 >Since MSYS is Cygwin with changes, that someone was Cygwin which
 >provides a POSIX emulation runtime library.
I think I understand.  Does this mean that those components were
built with Cygwin, not with the MSYS development environment?

 >MSYS is a fork of an older version 1.3.x of Cygwin.  The goal of MSYS
I think I remember reading that somewhere.

 >gravy.  So, you should be able to follow the Cygwin methods and build
 >a MSYS dependent ghostscript assuming it doesn't require the newer
 >revisions of GCC and Cygwin.
That wasn't really my goal.  My ultimate goal is to create my own
uname function using Windows methods as you suggested.

 >But in this OS realm the POSIX uname function isn't available, you'll
 >need to use Windows methods to get the equivalent information.
I sort of figured that out while looking into the msys components and
trying to rebuild them.

 >> that.  I want to tamper with the uname command so I have my own custom uname.  This almost
 >> certainly means that I have to build msys source with the msys toolset.
 >No, it really means you need to port it to use Windows methods.
Sure, that is the ultimate goal.  I still would like to know, is it not true
that the current uname.exe provided by msys is built with the msys
toolset?  Since I have been able to rebuild msyscore and coreutils,
using the msys environment, I have to conclude the answer is yes.

By this point you are probably wondering why I am going to this much
trouble to do something that you don't think is a good idea.  Though I
have some experience with a few programming languages and development
environments, it was almost all learned on my own by trial and error.
It took me quite a while before I was able to learn enough of Mingw/msys
(and GTK) to where I could actually do some useful programming.  I am
not as well educated or experienced in this area as are many I see on
lists like this one.  The only learning method that I have had success
with is by taking little bits at a time.

 >> Can you please tell me what I would have to do to the coreutils makefile to make it
 >> link to the library containing GetEnvironmentVariable?
 >
 >Yes, GetEnvironmentVariable is a Windows API and which isn't intended
 >to be used with the MSYS/Cygwin runtime.  However, the emulation must
 >use it so there are special instructions for adding the appropriate
 >libraries when MSYS itself is built.
So would I be correct in understanding that it is built into the
runtime app like uname.exe but not available for linking into my
own app?

What are those special instructions?  how do I link to get that
GetEnvironmentVariable function available to coreutils, specifically
to the uname.c ?  Come to think of it, if my goal is supposed to be
to create a new uname.exe using windows methods, wouldn't I need
access to windows functions such as GetEnvironmentVariable?

 >I think your best bet will be to port ghostscript to windows methods.
 >I think that it has been done already, maybe you just need to follow
As far as Ghostscript goes, you are probably right.  At this point I just
hate admitting defeat on the uname side.  I would really like to know
how to make coreutils link with GetEnvironmentVariable such that I can
do some tampering to get a uname.exe that does what I want and in the
process I hope to learn enough of how it works to be able to port it to
a regular windows app that can be built with mingw environment.

Damon Register

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: uname function in MSYS

Earnie Boyd
On Mon, Jun 11, 2012 at 1:39 PM, Damon Register
<[hidden email]> wrote:
> On 6/7/2012 1:11 PM, Earnie Boyd wrote:
> That wasn't really my goal.  My ultimate goal is to create my own
> uname function using Windows methods as you suggested.

Then you need to be in a MinGW build environment to provide that
function and not an MSYS build environment.

> Sure, that is the ultimate goal.  I still would like to know, is it not true
> that the current uname.exe provided by msys is built with the msys
> toolset?  Since I have been able to rebuild msyscore and coreutils,
> using the msys environment, I have to conclude the answer is yes.

The uname.exe program provided by MSYS depends on the MSYS runtime
which implements the uname() function.

>  >> Can you please tell me what I would have to do to the coreutils makefile to make it
>  >> link to the library containing GetEnvironmentVariable?
>  >
>  >Yes, GetEnvironmentVariable is a Windows API and which isn't intended
>  >to be used with the MSYS/Cygwin runtime.  However, the emulation must
>  >use it so there are special instructions for adding the appropriate
>  >libraries when MSYS itself is built.
> So would I be correct in understanding that it is built into the
> runtime app like uname.exe but not available for linking into my
> own app?

As stated previously uname.exe depends on the MSYS runtime so uname()
function is given.  The MSYS runtime depends on some of Windows API
and uses LoadLibrary/GetProcAddress to provide those functions.

>
> What are those special instructions?  how do I link to get that
> GetEnvironmentVariable function available to coreutils, specifically
> to the uname.c ?  Come to think of it, if my goal is supposed to be
> to create a new uname.exe using windows methods, wouldn't I need
> access to windows functions such as GetEnvironmentVariable?
>

Again, MSYS provides GetEnvironmentVariable to itself via
LoadLibrary()/GetProcAddress().  The coretuils uname.c depends on the
MSYS runtime to provide the functions it needs.

>  >I think your best bet will be to port ghostscript to windows methods.
>  >I think that it has been done already, maybe you just need to follow
> As far as Ghostscript goes, you are probably right.  At this point I just
> hate admitting defeat on the uname side.  I would really like to know
> how to make coreutils link with GetEnvironmentVariable such that I can
> do some tampering to get a uname.exe that does what I want and in the
> process I hope to learn enough of how it works to be able to port it to
> a regular windows app that can be built with mingw environment.

A native uname.exe is most likely doable but you'll need to be in a
MinGW build environment to create one.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: uname function in MSYS

Damon Register-4
On 6/11/2012 4:17 PM, Earnie Boyd wrote:
> Then you need to be in a MinGW build environment to provide that
> function and not an MSYS build environment.
yes, I know.  I was just wanting to get there in two steps, not one,
meaning that I first wanted to do what I thought would be minor tampering
with the current one before I started over in MinGW.

> The uname.exe program provided by MSYS depends on the MSYS runtime
> which implements the uname() function.
that's fine with me, at least for my first step that I mentioned above.

> function is given.  The MSYS runtime depends on some of Windows API
> and uses LoadLibrary/GetProcAddress to provide those functions.
aha, that's the secret.  I am familiar with that and have done it
with Borland, MSVC and MinGW.

> Again, MSYS provides GetEnvironmentVariable to itself via
> LoadLibrary()/GetProcAddress().  The coretuils uname.c depends on the
Got it.  Thanks

> A native uname.exe is most likely doable but you'll need to be in a
> MinGW build environment to create one.
I might still try that eventually once I can understand how it works.
Thanks for your help and patience.


Damon Register


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: uname function in MSYS

Damon Register
In reply to this post by Earnie Boyd
On 6/7/2012 1:11 PM, Earnie Boyd wrote:
> The documentation you point to is providing you a means to create an
> environment to develop MSYS and creating applications that use the
> msys-1.0.dll which is a POSIX runtime.  I don't think that is what you
> are trying to accomplish.
I looked at the uname.exe using Dependency Walker.  I see that uname.exe
uses msys-1.0.dll (not really a surprise).  My only goal at this point
was to tamper with uname.exe enough so that it doesn't give unknown for
the -p and -i options.  I suppose that it might be nice to make a uname.exe
that doesn't need msys-1.0.dll but that might be a bit more difficult for
my level of programming skill.

Using the GetProcAddress as you suggested, I was able to tamper with uname.c
enough to have it look for environment variables that I provide.  I didn't
know enough yet to figure out how to get this info from the Windows OS so
I chose the environment variable route.  Could you please look at my edited
version of uname.c and tell me if this seems to be a reasonable approach?

Damon Register


/* uname -- print system information

    Copyright 1989, 1992, 1993, 1996, 1997, 1999, 2000, 2001, 2002,
    2003, 2004, 2005 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
    the Free Software Foundation; either version 2, or (at your option)
    any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software Foundation,
    Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.  */

/* Written by David MacKenzie <[hidden email]> */

#include <config.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/utsname.h>
#include <getopt.h>
#include <windows.h>

#if HAVE_SYSINFO && HAVE_SYS_SYSTEMINFO_H
# include <sys/systeminfo.h>
#endif

#if HAVE_SYS_SYSCTL_H
# if HAVE_SYS_PARAM_H
#  include <sys/param.h> /* needed for OpenBSD 3.0 */
# endif
# include <sys/sysctl.h>
# ifdef HW_MODEL
#  ifdef HW_MACHINE_ARCH
/* E.g., FreeBSD 4.5, NetBSD 1.5.2 */
#   define UNAME_HARDWARE_PLATFORM HW_MODEL
#   define UNAME_PROCESSOR HW_MACHINE_ARCH
#  else
/* E.g., OpenBSD 3.0 */
#   define UNAME_PROCESSOR HW_MODEL
#  endif
# endif
#endif

#ifdef __APPLE__
# include <mach/machine.h>
# include <mach-o/arch.h>
#endif

#include "system.h"
#include "error.h"
#include "quote.h"

/* The official name of this program (e.g., no `g' prefix).  */
#define PROGRAM_NAME "uname"

#define AUTHORS "David MacKenzie"

/* Values that are bitwise or'd into `toprint'. */
/* Kernel name. */
#define PRINT_KERNEL_NAME 1

/* Node name on a communications network. */
#define PRINT_NODENAME 2

/* Kernel release. */
#define PRINT_KERNEL_RELEASE 4

/* Kernel version. */
#define PRINT_KERNEL_VERSION 8

/* Machine hardware name. */
#define PRINT_MACHINE 16

/* Processor type. */
#define PRINT_PROCESSOR 32

/* Hardware platform.  */
#define PRINT_HARDWARE_PLATFORM 64

/* Operating system.  */
#define PRINT_OPERATING_SYSTEM 128

/* The name this program was run with, for error messages. */
char *program_name;

static struct option const long_options[] =
{
   {"all", no_argument, NULL, 'a'},
   {"kernel-name", no_argument, NULL, 's'},
   {"sysname", no_argument, NULL, 's'}, /* Obsolescent.  */
   {"nodename", no_argument, NULL, 'n'},
   {"kernel-release", no_argument, NULL, 'r'},
   {"release", no_argument, NULL, 'r'},  /* Obsolescent.  */
   {"kernel-version", no_argument, NULL, 'v'},
   {"machine", no_argument, NULL, 'm'},
   {"processor", no_argument, NULL, 'p'},
   {"hardware-platform", no_argument, NULL, 'i'},
   {"operating-system", no_argument, NULL, 'o'},
   {GETOPT_HELP_OPTION_DECL},
   {GETOPT_VERSION_OPTION_DECL},
   {NULL, 0, NULL, 0}
};

void
usage (int status)
{
     if (status != EXIT_SUCCESS)
         fprintf (stderr, _("Try `%s --help' for more information.\n"),
             program_name);
     else
     {
         printf (_("Usage: %s [OPTION]...\n"), program_name);
         fputs (_("\
Print certain system information.  With no OPTION, same as -s.\n\
\n\
   -a, --all                print all information, in the following order,\n\
                              except omit -p and -i if unknown:\n\
   -s, --kernel-name        print the kernel name\n\
   -n, --nodename           print the network node hostname\n\
   -r, --kernel-release     print the kernel release\n\
"), stdout);
       fputs (_("\
   -v, --kernel-version     print the kernel version\n\
   -m, --machine            print the machine hardware name\n\
   -p, --processor          print the processor type or \"unknown\"\n\
   -i, --hardware-platform  print the hardware platform or \"unknown\"\n\
   -o, --operating-system   print the operating system\n\
"), stdout);
       fputs (HELP_OPTION_DESCRIPTION, stdout);
       fputs (VERSION_OPTION_DESCRIPTION, stdout);
       printf (_("\nReport bugs to <%s>.\n"), PACKAGE_BUGREPORT);
     }
     exit (status);
}

/* Print ELEMENT, preceded by a space if something has already been
    printed.  */

static void
print_element (char const *element)
{
     static bool printed;
     if (printed)
         putchar (' ');
     printed = true;
     fputs (element, stdout);
}

int
main (int argc, char **argv)
{
     int c;
     static char const unknown[] = "unknown";
     char msystem[128];
     HINSTANCE hInstkernel32 = NULL;
     typedef DWORD (WINAPI *PKPROC)(LPCTSTR,LPTSTR,DWORD);
     PKPROC pKPROC = NULL;

     /* Mask indicating which elements to print. */
     unsigned int toprint = 0;

     initialize_main (&argc, &argv);
     program_name = argv[0];
     setlocale (LC_ALL, "");
     bindtextdomain (PACKAGE, LOCALEDIR);
     textdomain (PACKAGE);

     atexit (close_stdout);

     hInstkernel32 = LoadLibrary("kernel32.dll");
     if(hInstkernel32)
     {
         pKPROC = (PKPROC)GetProcAddress(hInstkernel32,"GetEnvironmentVariableA");
         if(pKPROC == NULL)
         {
             printf("getprocaddress failed\n");
         }
     }
     //if (! GetEnvironmentVariable("MSYSTEM", msystem, sizeof (msystem)))
     //    strcpy (msystem, "MINGW32");

     while ((c = getopt_long (argc, argv, "asnrvmpio", long_options, NULL)) != -1)
     {
         switch (c)
         {
             case 'a':
                 toprint = UINT_MAX;
                 break;

             case 's':
                 toprint |= PRINT_KERNEL_NAME;
                 break;

             case 'n':
                 toprint |= PRINT_NODENAME;
                 break;

             case 'r':
                 toprint |= PRINT_KERNEL_RELEASE;
                 break;

             case 'v':
                 toprint |= PRINT_KERNEL_VERSION;
                 break;

             case 'm':
                 toprint |= PRINT_MACHINE;
                 break;

             case 'p':
                 toprint |= PRINT_PROCESSOR;
                 break;

             case 'i':
                 toprint |= PRINT_HARDWARE_PLATFORM;
                 break;

             case 'o':
                 toprint |= PRINT_OPERATING_SYSTEM;
                 break;

             case_GETOPT_HELP_CHAR;

             case_GETOPT_VERSION_CHAR (PROGRAM_NAME, AUTHORS);

             default:
                 usage (EXIT_FAILURE);
         }
     }

     if (argc != optind)
     {
         error (0, 0, _("extra operand %s"), quote (argv[optind]));
         usage (EXIT_FAILURE);
     }

     if (toprint == 0)
         toprint = PRINT_KERNEL_NAME;

     if (toprint
         & (PRINT_KERNEL_NAME | PRINT_NODENAME | PRINT_KERNEL_RELEASE
         | PRINT_KERNEL_VERSION | PRINT_MACHINE))
     {
         struct utsname name;

         if (uname (&name) == -1)
             error (EXIT_FAILURE, errno, _("cannot get system name"));

         if (toprint & PRINT_KERNEL_NAME)
             print_element (name.sysname);
         if (toprint & PRINT_NODENAME)
             print_element (name.nodename);
         if (toprint & PRINT_KERNEL_RELEASE)
             print_element (name.release);
         if (toprint & PRINT_KERNEL_VERSION)
             print_element (name.version);
         if (toprint & PRINT_MACHINE)
             print_element (name.machine);
     }

     if (toprint & PRINT_PROCESSOR)
     {
         char const *element = unknown;
         #if HAVE_SYSINFO && defined SI_ARCHITECTURE
         {
             static char processor[257];
             if (0 <= sysinfo (SI_ARCHITECTURE, processor, sizeof processor))
                 element = processor;
         }
         #endif
         if (element == unknown)
         {
             #ifdef UNAME_PROCESSOR
             static char processor[257];
             size_t s = sizeof processor;
             static int mib[] = { CTL_HW, UNAME_PROCESSOR };
             if (sysctl (mib, 2, processor, &s, 0, 0) >= 0)
                 element = processor;

             # ifdef __APPLE__
             /* This kludge works around a bug in Mac OS X.  */
             if (element == unknown)
             {
                 cpu_type_t cputype;
                 size_t s = sizeof cputype;
                 NXArchInfo const *ai;
                 if (sysctlbyname ("hw.cputype", &cputype, &s, NULL, 0) == 0
                     && (ai = NXGetArchInfoFromCpuType (cputype,
                             CPU_SUBTYPE_MULTIPLE))
                     != NULL)
                 {
                     element = ai->name;
                 }

                 /* Hack "safely" around the ppc vs. powerpc return value. */
                 if (cputype == CPU_TYPE_POWERPC
                     && strncmp (element, "ppc", 3) == 0)
                     element = "powerpc";
             }
             # endif  //# ifdef __APPLE__
             #else    //#ifdef UNAME_PROCESSOR
             //dwr kludge
             static char env_var_proc[128];
             if(pKPROC)
             {
                 DWORD env_ret;
                 env_ret = pKPROC("UNAME_P_OPTION", env_var_proc, sizeof(env_var_proc));
                 if(env_ret)
                 {
                     element = env_var_proc;
                 }
             }
             #endif   //#ifdef UNAME_PROCESSOR
         }
         if (! (toprint == UINT_MAX && element == unknown))
         {
             print_element (element);
         }
     }

     if (toprint & PRINT_HARDWARE_PLATFORM)
     {
         char const *element = unknown;
         #if HAVE_SYSINFO && defined SI_PLATFORM
         {
             static char hardware_platform[257];
             if (0 <= sysinfo (SI_PLATFORM,
                 hardware_platform, sizeof hardware_platform))
                 element = hardware_platform;
         }
         #endif
         if (element == unknown)
         {
             #ifdef UNAME_HARDWARE_PLATFORM
             static char hardware_platform[257];
             size_t s = sizeof hardware_platform;
             static int mib[] = { CTL_HW, UNAME_HARDWARE_PLATFORM };
             if (sysctl (mib, 2, hardware_platform, &s, 0, 0) >= 0)
                 element = hardware_platform;
             #else
             //dwr kludge
             static char env_var_plat[128];
             if(pKPROC)
             {
                 DWORD env_ret;
                 env_ret = pKPROC("UNAME_I_OPTION", env_var_plat, sizeof(env_var_plat));
                 if(env_ret)
                 {
                     element = env_var_plat;
                 }
             }
             #endif
         }
         if (! (toprint == UINT_MAX && element == unknown))
             print_element (element);
     }

     if (toprint & PRINT_OPERATING_SYSTEM)
         print_element (HOST_OPERATING_SYSTEM);

     putchar ('\n');

     if(hInstkernel32)
     {
         FreeLibrary(hInstkernel32);
     }

     exit (EXIT_SUCCESS);
}




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: uname function in MSYS

Earnie Boyd
On Tue, Jun 19, 2012 at 8:11 AM, Damon Register wrote:
> Could you please look at my edited
> version of uname.c and tell me if this seems to be a reasonable approach?

I really don't have the time to do that; maybe someone else?

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: uname function in MSYS

Teemu Nätkinniemi
In reply to this post by Damon Register
> I chose the environment variable route.  Could you please look at my edited
> version of uname.c and tell me if this seems to be a reasonable approach?

The best way to test if your uname works is to use it with a configure script and see if it works.

Teemu


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys