[Mingw-msys] Doubt with autoconf.
- Date: Sun, 10 Jun 2012 20:28:08 -0400
- From: Damon Register <dregister@xxxxxxxxx>
- Subject: Re: [Mingw-msys] uname function in MSYS
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
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.
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
Mingw-msys mailing list