coapp-developers team mailing list archive

[Tom Hanrahan <hanrahat@xxxxxxxxxxxxx>]

Done.

     http://wiki.coapp.org/Process-for-installing-MinGW.ashx

-- Tom

-----Original Message-----
From: coapp-developers-bounces+hanrahat=microsoft.com@xxxxxxxxxxxxxxxxxxx [mailto:coapp-developers-bounces+hanrahat=microsoft.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Garrett Serack
Sent: Thursday, May 12, 2011 8:54 AM
To: Garrett Serack; Philip Allison; coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] MinGW and Gnulib

Process for installing Mingw (Could someone volunteer to put this into the wiki?):

==========================================================
from a command prompt:
    mkdir c:\MinGW
    cd c:\MinGW

    REM or download the following elsewise if you don't have wget
    wget "http://j.mp/kMkmzR";
    unzip mingw-get-0.2-mingw32-alpha-3-bin.zip
    cd bin
    mingw-get.exe install gcc g++ mingw32-make msys-base

    PATH=%PATH%;c:\mingw\bin
    
    C:\MinGW\msys\1.0\msys.bat

Which will open a new window, where you can run:

    /postinstall/pi.sh 
    
You will see:

    This is a post install process that will try to normalize between
    your MinGW install if any as well as your previous MSYS installs
    if any.  I don't have any traps as aborts will not hurt anything.
    Do you wish to continue with the post install? [yn ] 

Answer: y

You will see:
    
    Do you have MinGW installed? [yn ] 

Answer: y

You will see:

    Please answer the following in the form of c:/foo/bar.
    Where is your MinGW installation? 
    
Answer: c:/mingw

You will see:


    Creating /etc/fstab with mingw mount bindings.
            Normalizing your MSYS environment.

    You have script /bin/cmd

    Oh joy, you do not have c:/mingw/bin/make.exe. Keep it that way.

And it's done.
==========================================================


-----Original Message-----
From: coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx [mailto:coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Garrett Serack
Sent: Thursday, May 12, 2011 8:08 AM
To: Philip Allison; coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] MinGW and Gnulib

Hey Phillip,

First, thanks for the really good feedback. This will help a lot--this is the kind of stuff we need to know.

>> Unless I've misunderstood the details, I don't think tracing the 
>> build would help out here: it would tell us exactly which parts of 
>> Gnulib and MinGW-RT get used in the build, but it wouldn't magically 
>> fix the problem that the Windows SDK doesn't provide equivalents for 
>> all the headers and library functions the code needs.

Well, tracing a build with mingw DOES give us some of what we need--Its possible take the output from a mingw build and create Visual Studio project files from that data--it may require us to 'port' some of the dependent libraries, but that's kind of a goal here too.

I'm disturbed by that "#include_next " directive. That's the hackiest damn thing I've ever heard of...  I suspect we're gonna have to come up with some sort of fix for that. 

I propose a hybrid of your options #2 and #3:

If I add support for mingw to ptk (so that there is a compiler toolset choice for that), we can trace builds with mingw.  If we shallow-fork and build a few of the underlying libraries, we should be able to create projects for MSVC without excessive trouble. The only real issue we're going to face is compiler incompatabilities, and for that we're going to have to actually modify code to fix those oddities that aren't supported by MSVC.

Proposed Tasks:
-------------------------

[Phillip] - document on a page in the wiki ( http://wiki.coapp.org ) the exact tools/steps to install for mingw -- so that there is no question of how it's installed.
[Garrett] - add mingw toolchain support into pTk so that we can trace builds from mingw. (This should only take me a couple of hours once I've got mingw up) [Phillip] - build & trace a few of the libraries with the updated pTk, and report the results :D

We won't be able to find issues with the voodoo "#include_next" directive without getting to the compiling on VC stage. Wait.

We could update the CoApp scan tool to pick those out--that's kindof the thing that it was built for.  Perhaps Trevor could come out of hiding and add that for us (or anyone really... it's good code).  Then we could at least do something with that information.

Anyone else?

G



-----Original Message-----
From: coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx [mailto:coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Philip Allison
Sent: Thursday, May 12, 2011 5:12 AM
To: coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: [Coapp-developers] MinGW and Gnulib

Hullo all,

Buoyed by early success (read: dumb luck) at getting bzip to build, I thought I'd have a go at gzip.  Long story short, I haven't succeeded, but it's raised some interesting questions.  GNU gzip - http://www.gnu.org/software/gzip/ - seems to be actively maintained, unlike the stuff at gzip.org, but it depends on Gnulib, which in turn seems to depend on the MinGW runtime.

Gnulib is a bunch of reusable code, which provides implementations of various functionality "missing" from various environments.
Unfortunately it isn't a shared library, it really is just a bunch of reusable code: in terms of version control, people either check in a snapshot of the parts they need, or import it using a git submodule (as is the case with gzip), or whatever equivalent their VCS of choice provides.  The bigger problem is that it provides a *lot* of autoconf macros for configuring itself to suit the host platform, coupled with making various base assumptions about the host platform's functionality, and I'm not quite sure how we're going to replicate those.

Using MinGW and MSYS, it's actually possible to run all the way through gzip's configure script with CC=cl and LD=link, with a bit of environment mangling, but the end result doesn't build.  The problem essentially stems from the fact that Gnulib assumes a GNU toolchain and a certain underlying amount of "POSIXness" in the host platform.
For example, its replacement for dirent.h - which isn't a static bit of source, but generated locally by autoconf - ended up containing the line '#include_next <dirent.h>', which poses two problems: first of all, the #include_next directive is non-standard and not supported by MSVC; secondly, even if it was supported, the Windows SDK doesn't provide a native dirent.h to begin with.  The Gnulib version isn't self-contained, it uses lots of macro trickery to selectively override or augment an existing header.  There are also various header files which, once generated, end up containing '#include ""' - I'm not 100% sure what's going on, but I think it's a symptom of a similar problem, where an assumption has been made about the existence of a platform-native header file but the configure script hasn't found one.

If I was going to build with the toolchain provided by MinGW itself, this wouldn't be such a problem, because the MinGW runtime library
(MinGW-RT) itself meets some of these requirements, but the end goal is to build with MSVC.  Unless I've misunderstood the details, I don't think tracing the build would help out here: it would tell us exactly which parts of Gnulib and MinGW-RT get used in the build, but it wouldn't magically fix the problem that the Windows SDK doesn't provide equivalents for all the headers and library functions the code needs.  I see several options at this point, but I'm not sure which is
best:

1. Port gzip away from Gnulib and MinGW-RT entirely.  We would end up with something self-contained and buildable, but the changes would be fairly extensive, and we'd need to repeat the process every time we come across a package with one or both of these dependencies.

2. Support MinGW as an alternative toolchain within CoApp.  It's pretty easy to set up these days, and can create executables which run outside the MinGW shell, providing the software doesn't try to do anything too odd at runtime.  IMHO a non-starter due to the sheer amount of baggage and maintenance problems this would introduce.

3. Port MinGW-RT to MSVC and package it for CoApp.  We may still need MinGW itself to get an initial build of a given package going, but once that's been done & traced, at least we'll have a reasonable assurance that when we swap out the toolchain, we aren't also swapping out great chunks of API which the code relies on.

4. Something else I haven't thought of.  I may, of course, be approaching this entirely the wrong way - I do think it will be an ongoing issue, though, because for many developers, MinGW is the toolset of choice when trying to build portable software on Windows.

Thoughts?

Regards,
Phil

_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~coapp-developers
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~coapp-developers
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~coapp-developers
More help   : https://help.launchpad.net/ListHelp