RE: [Mingw-msys] Doubt with autoconf.
On Sun, Jun 10, 2012 at 8:28 PM, Damon Register <dregister@xxxxxxxxx> 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.
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