From: Damon R. <dam...@lm...> - 2012-06-07 14:03:36
|
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 |
From: ralph e. <ral...@gm...> - 2012-06-07 15:05:10
|
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 :) |
From: Earnie B. <ea...@us...> - 2012-06-07 17:11:52
|
On Thu, Jun 7, 2012 at 10:03 AM, Damon Register <dam...@lm...> 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 |
From: Damon R. <dre...@cl...> - 2012-06-11 00:56:13
|
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 |
From: Earnie B. <ea...@us...> - 2012-06-11 16:08:27
|
On Sun, Jun 10, 2012 at 8:28 PM, Damon Register <dre...@cl...> 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 |
From: Damon R. <dam...@lm...> - 2012-06-11 17:40:21
|
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 |
From: Earnie B. <ea...@us...> - 2012-06-11 20:17:08
|
On Mon, Jun 11, 2012 at 1:39 PM, Damon Register <dam...@lm...> 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 |
From: Damon R. <dre...@cl...> - 2012-06-11 21:37:09
|
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 |
From: Damon R. <dam...@lm...> - 2012-06-19 12:11:23
|
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 <dj...@gn...> */ #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); } |
From: Earnie B. <ea...@us...> - 2012-06-19 12:23:35
|
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 |
From: Teemu N. <sti...@ya...> - 2012-06-19 15:42:32
|
> 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 |