mingw-msys Mailing List for MinGW - Minimalist GNU for Windows

Torsten Schlabach wrote:

> I just don't know how to install them as developers had waived the
> installer.

They're just tarballs.  They extract into the root directory, e.g. tar
jx -C / -f filename.tar.bz2.

Note that with the autotools there are two "flavors":

A) The MSYS-linked ones, which are to be used when *building* MSYS apps:

autoconf-2.61-MSYS-1.0.11.tar.bz2
automake-1.10-MSYS-1.0.11.tar.bz2
libtool1.5-1.5.25a-20070701-MSYS-1.0.11.tar.bz2
libiconv-1.11-MSYS-1.0.11.tar.bz2
gettext-0.16.1-MSYS-1.0.11.tar.bz2
gettext-devel-0.16.1-MSYS-1.0.11.tar.bz2

These are the analogs to what you'd find in the old msysDVLPR bundle. 
These install in /usr.

B) The "native" versions which install in /usr/local and are intended to
be used when *building* MinGW apps:

autoconf-4-1-bin.tar.bz2
autoconf2.1-2.13-3-bin.tar.bz2
autoconf2.5-2.61-1-bin.tar.bz2
automake-3-1-bin.tar.bz2
automake1.9-1.9.6-2-bin.tar.bz2
automake1.10-1.10-1-bin.tar.bz2
libtool1.5-1.5.25a-1-bin.tar.bz2
libtool1.5-1.5.25a-1-dll.tar.bz2
libiconv-1.11-1-bin.tar.bz2
libiconv-1.11-1-dll.tar.bz2
gettext-0.16.1-1-bin.tar.bz2
gettext-0.16.1-1-dll.tar.bz2

These come with wrapper scripts that do version detection, which allows
for multiple versions to be installed side by side (i.e. all of the
above work together.)

References:
http://sourceforge.net/project/shownotes.php?release_id=540763&group_id=2435
http://article.gmane.org/gmane.comp.gnu.mingw.user/23921

Brian

I got caught by this, too. You need to go to

http://sourceforge.net/project/showfiles.php?group_id=2435

and then click on MSYS Supplementary Tools in the left column in order 
to find and download and install the current release of the developer's 
toolkit (currently msysDTK-1.0.1.exe). Scroll down past the "Technology 
Preview" stuff to the "Current Release" section.

After installing msysDTK-1.0.1.exe, you need to download and install 
from the same source the following updates:
    msys-autoconf-2.59.2.59.tar.bz2
    msys-automake-1.8.2.tar.bz2
    msys-libtool-1.5.tar.bz2

Run MSYS, and cd to the folder where you have downloaded these .bz2 
files and execute
    tar -xjf msys-autoconf-2.59.2.59.tar.bz2
    tar -xjf msys-automake-1.8.2.tar.bz2
    tar -xjf msys-libtool-1.5.tar.bz2

This will produce a bunch of folders (bin, lib, and so on). Copy these 
folders to c:\msys\1.0. Note that Windows merges on copy, so you can 
simply drag all the folders to c:\msys\1.0.

Bruce Sherwood

Torsten Schlabach wrote:
> Johannes Schindelin wrote:
>> You might want to use Cygwin instead.  MingW is meant to compile programs 
>> as native Win32 programs,
> 
> No, I don't want to use Cygwin. I want to produce a native Windows 
> binary (myapp.exe) which any Windows user can download and run, without 
> having to install Cygwin first.
> 
> But in order to do that, I need an installation of MinGW + MSYS with a 
> somewhat recent autotools; basically a version which I can see is 
> available here:
> 
> http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=67879
> 
> I just don't know how to install them as developers had waived the 
> installer.
> 
> Regards,
> Torsten
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys

Dear list!

I would like to use these tools here:

http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=67879

To be more exact:

The newer version of autogen / autoconf / automake available under the 
above mentioned link for download.

Unfortunately, since 1.0.11 Technology Preview there is no installer 
anymore and the MinGW installed does not yet pick these MSYS tools up.

Unzipping the binary .tar.bz2 files does not look like the solution 
becuase paths seem to have changed.

What can I do?

Regards,
Torsten

Johannes Schindelin wrote:
> You might want to use Cygwin instead.  MingW is meant to compile programs 
> as native Win32 programs,

No, I don't want to use Cygwin. I want to produce a native Windows 
binary (myapp.exe) which any Windows user can download and run, without 
having to install Cygwin first.

But in order to do that, I need an installation of MinGW + MSYS with a 
somewhat recent autotools; basically a version which I can see is 
available here:

http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=67879

I just don't know how to install them as developers had waived the 
installer.

Regards,
Torsten

Hi,

On Thu, 14 Feb 2008, Torsten Schlabach wrote:

> I think I was suffering from the misconception that MSYS was something 
> like a "Linux on Windows" system, i.e. it was comparable with a Linux 
> distro.

You might want to use Cygwin instead.  MingW is meant to compile programs 
as native Win32 programs, not as POSIX programs.  With Cygwin, you get a 
POSIX emulation layer, which makes it trivial to "port" POSIX programs, at 
the cost of some runtime speed.

Hth,
Dscho

Dear Keith,

> Perhaps if you explained your objective, we could offer better advice.  

Indeed, let's try:

My objective is simple. I would like build this peace of software here on Windows:

http://svn.openmoko.org/trunk/src/host/dfu-util/
(Description: http://wiki.openmoko.org/wiki/Dfu-util)

This requires a more recent version of autotools than I can install using the .exe installers from the current version of MinGW + MSYS. I can spot the versions I need on SF in the Technology Preview releases, but I don't know how to get them installed. I tried downloading the .tar.bz2 files but that didn't do it. I am not sure, maybe I just have a dependency issue, i.e. automake >= 2.6 needs libxyz => X.Y, whatever.

Therefore I thought compiling from source will help.

I think I was suffering from the misconception that MSYS was something like a "Linux on Windows" system, i.e. it was comparable with a Linux distro. But I think I understood that basically MSYS is a shell (some kind of bash + terminal replacement) in order to be able to execute shell scripts which are often part of the build process of GNU / Linux flavor sources.

This leaves me with the question: Does MSYS / MinGW have some kind of package management system like apt+dpkg or yum/YaST+rpm or the like? I found a reference to the Cygwin Setup tool which is talking about repositories, but my impression when using the MinGW installer or the MSYS installer is that they can only install what's built-in right now.

I hope my objective did become clear. The easiest way of phrasing it would be:

I need a MSYS+MinGW setup with recent autotools.

Regards,
Torsten


-------- Original-Nachricht --------
> Datum: Thu, 14 Feb 2008 11:21:33 +0000
> Von: Keith Marshall <kei...@us...>
> An: min...@li...
> Betreff: Re: [Mingw-msys] Trying to build MSYS according to the Howto

> On Saturday 09 February 2008 23:20, Torsten Schlabach wrote:
> > > Use the msysdvlpr command to enter the MSYS Build Environment.
> >
> > I don't have that. This script is contained in
> > msysDVLPR-1.0.0-alpha-1.tar.gz which I am supposed to unpack to
> > /msys. But /msys/bin will only be on the PATH when I am already in
> > the MSYS build environment. Kind of a chicken and egg problem.
> 
> No, that is not correct.  You *must* first have installed MSYS, and be 
> running it.  You unpack msysDVLPR-1.0.0-alpha-1.tar.gz into the root of 
> your existing MSYS tree, and your MSYS /bin directory will already be 
> in the PATH, by virtue of you running MSYS.
> 
> > I have passed some other issues and was able to do a successful
> > configure + make in my /msys directory.
> >
> > But where do I go from here? What have I built now? How can I install
> > this? I mean, do I know have some new .exe file which I can use to
> > setup my MSYS-snapshot environment?
> 
> Perhaps if you explained your objective, we could offer better advice.  
> Since you appear not to know what msysDVLPR is for -- it is exclusively 
> for building and developing MSYS itself, *not* for general applications 
> development -- then it is probable that you don't need it at all.  If 
> it *is* your intention to build components for MSYS itself -- all of 
> which are dependent on msys-1.0.dll -- then what it provides you with 
> is a specialised version of GCC and its associated tools, for building 
> such components.
> 
> Regards,
> Keith.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys

Hi all, 

I post this thread because I recently installed mingw and msys (under
Windows XP) and I can´t compile a simple "hello world" program.

The steps I followed where:


Download MinGW using the installer MinGW-5.1.3.exe and install it in
c:/MinGW 
 
Download Msys using the installer MSYS-1.0.10.exe and install it in c:/Msys
(at the end of the installation progress I give the path to the minGW
directory (c:/MinGW)). 
 
Download Msys-DTK using the installes msysDTK-1.0.1.exe and install it
overwriting Msys installed files.


When I tried to compile I got:

$ gcc -o hello hello.c 
 
This application has requested the Runtime to terminate it in an unusual
way. 
Please contact the application's support team for more information. 

But the gcc command is correctly detected:

$ which gcc 
/mingw/bin/gcc 

And If I type: $ gcc -v I get:

Reading specs from c:/msys/1.0/mingw/bin/../lib/gcc/mingw32/3.4.5/specs 
Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld
--with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw
--enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java
--disable-win32-registry --disable-shared --enable-sjlj-exceptions
--enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm
--disable-libgcj-debug --enable-interpreter --enable-hash-synchronization
--enable-libstdcxx-debug 
Thread model: win32 
gcc version 3.4.5 (mingw special) 

Anyone has any ideas? One curious thing is that if I try to compile the same
file in the same directory, with the same gcc (I know is the same gcc
because if I remove "c:/msys/1.0/mingw/bin" from the PATH, gcc command is
not recognized) but from the MSDOS shell, the compilation is ok!!!!! why can
I compile perfectly from MS-DOS and not from Msys???

Thank you very much
-- 
View this message in context: http://www.nabble.com/Problems-with-gcc-tp15478049p15478049.html
Sent from the MinGW - MSYS mailing list archive at Nabble.com.

On Saturday 09 February 2008 23:20, Torsten Schlabach wrote:
> > Use the msysdvlpr command to enter the MSYS Build Environment.
>
> I don't have that. This script is contained in
> msysDVLPR-1.0.0-alpha-1.tar.gz which I am supposed to unpack to
> /msys. But /msys/bin will only be on the PATH when I am already in
> the MSYS build environment. Kind of a chicken and egg problem.

No, that is not correct.  You *must* first have installed MSYS, and be 
running it.  You unpack msysDVLPR-1.0.0-alpha-1.tar.gz into the root of 
your existing MSYS tree, and your MSYS /bin directory will already be 
in the PATH, by virtue of you running MSYS.

> I have passed some other issues and was able to do a successful
> configure + make in my /msys directory.
>
> But where do I go from here? What have I built now? How can I install
> this? I mean, do I know have some new .exe file which I can use to
> setup my MSYS-snapshot environment?

Perhaps if you explained your objective, we could offer better advice.  
Since you appear not to know what msysDVLPR is for -- it is exclusively 
for building and developing MSYS itself, *not* for general applications 
development -- then it is probable that you don't need it at all.  If 
it *is* your intention to build components for MSYS itself -- all of 
which are dependent on msys-1.0.dll -- then what it provides you with 
is a specialised version of GCC and its associated tools, for building 
such components.

Regards,
Keith.

  From: Mathijs Romans 
  Sent: Monday, February 11, 2008 7:08 PM
  To: min...@li... 
  Subject: [Mingw-msys] Msys recognizes shebang (!#), python does not


  Hi! 


  I hope somebody can help me with this problem, I am new to developing under Windows. I try to compile a third-party program using mingw+msys. It uses, among other things, SDL-libraries, and for making it I use "scons", which is a python-based replacement for "make". Building under linux poses no problems.


  In the configuration file for scons, the library flags are set with the command 

  env.ParseConfig('sdl-config --cflags')

  which is interpreted by python to run the program "sdl-config". So far so good. I am sure this program is in the path, and I can run it from the msys-prompt. However using either scons, or the native command-line "cmd" on windows, I get the error:

  'sdl-config' is not recognized as an internal or external command, operable program or batch file.


  I think this is because neither python nor cmd recognizes that this should be run with sh (starts with #!/bin/sh). 

  Is there anything I can do (apart from replacing "sdl-config --cflags" with "sh sdl-config --cflags" everywhere), to solve this problem? Am I doing anything wrong? I feel that it's supposed to work this way. Any help would be greatly appreciated!

  Mathijs

Hi,

Have you tried creating a sdl-config.bat which runs "sh c:\path\sdl-config %*" ?

Luke

Peter Selinger wrote:

> Googling has not helped. I also browsed the CVS repository at
> http://mingw.cvs.sourceforge.net/mingw/, but could not find the
> pertinent sources.

It's there.  The main portion of the DLL is at
<http://mingw.cvs.sourceforge.net/mingw/msys/rt/src/winsup/cygwin/>. 
Remember that MSYS is a fork of an old version of Cygwin so the
directory layout and most of the files' descriptions will say that
they're part of Cygwin.

> In particular, I would like to see the sources for libmsys-1.0.dll.a.
> More specifically, I would like to know how ioctl() and the termios
> stuff has been implemented.

Err, that's an import library.  There's no code in that.  I think you
mean the sources for msys-1.0.dll.

Brian

Hi,

I apologize in advance if I have overlooked the obvious answer to my
question: Where can I get the source code for the msysDVLPR package?

I have found the binary package at
http://sourceforge.net/project/showfiles.php?group_id=2435, and it is
essentially a tarball full of headers, executables, and libraries. But
unlike all the other MSYS/MinGW packages, there is no corresponding
*src* tarball.

Googling has not helped. I also browsed the CVS repository at
http://mingw.cvs.sourceforge.net/mingw/, but could not find the
pertinent sources.

In particular, I would like to see the sources for libmsys-1.0.dll.a.
More specifically, I would like to know how ioctl() and the termios
stuff has been implemented.

Thanks, -- Peter

Mathijs Romans wrote:

> I think this is because neither python nor cmd recognizes that this
> should be run with sh (starts with #!/bin/sh).

And how should they?  CMD would have no idea what or where /bin/sh is,
let alone what a shebang is.  And python -- I'm assuming you're using
the native Win32 build -- might be able to read shebangs but it
certainly won't have any idea what "/bin/sh" is supposed to mean since
it has no concept of MSYS or where MSYS might be installed or even if
you're using MSYS and not some other set of tools, etc.

I don't think there's any way to fix this that doesn't require modifying
something.  You could try replacing the shebang with the proper Win32
path to the shell (e.g. #!c:/msys/1.0/bin/sh.exe) and see if the Win32
python is smart enough to read it.  You could give the sdl-config script
an extension like .py and then associate .py files with python.exe in
the Windows file association database.  You could add sh explicitly like
you mentioned.  Is SHELL exported to the environment?  There's a chance
that python is choosing to run the command with cmd.exe if SHELL isn't
set, in which case setting it (to a Win32 path to sh.exe? I don't know)
might also work.

Brian

Hi!

I hope somebody can help me with this problem, I am new to developing under
Windows. I try to compile a third-party program using mingw+msys. It uses,
among other things, SDL-libraries, and for making it I use "scons", which is
a python-based replacement for "make". Building under linux poses no
problems.
In the configuration file for scons, the library flags are set with the
command

env.ParseConfig('sdl-config --cflags')

which is interpreted by python to run the program "sdl-config". So far so
good. I am sure this program is in the path, and I can run it from the
msys-prompt. However using either scons, or the native command-line "cmd" on
windows, I get the error:

'sdl-config' is not recognized as an internal or external command, operable
program or batch file.

I think this is because neither python nor cmd recognizes that this should
be run with sh (starts with #!/bin/sh).
Is there anything I can do (apart from replacing "sdl-config --cflags" with
"sh sdl-config --cflags" everywhere), to solve this problem? Am I doing
anything wrong? I feel that it's supposed to work this way. Any help would
be greatly appreciated!

Mathijs

Dear Cesar,

thanks for your help. Unfortunately, there are still issues.

 > Use the msysdvlpr command to enter the MSYS Build Environment.

I don't have that. This script is contained in 
msysDVLPR-1.0.0-alpha-1.tar.gz which I am supposed to unpack to /msys. 
But /msys/bin will only be on the PATH when I am already in the MSYS 
build environment. Kind of a chicken and egg problem. But I was able to 
enter the MSYS build environment using the patched version of start.bat.

I have passed some other issues and was able to do a successful 
configure + make in my /msys directory.

But where do I go from here? What have I built now? How can I install 
this? I mean, do I know have some new .exe file which I can use to setup 
my MSYS-snapshot environment?

Regards,
Torsten

Cesar Strauss schrieb:
> Torsten Schlabach wrote:
> 
>>Dear list!
>>
>>I am trying to follow the howtos:
>>
>>http://www.mingw.org/MinGWiki/index.php/MSYSBuildEnvironment
>>http://www.mingw.org/MinGWiki/index.php/Build%20MSYS
>>
>>Unfortunately, I don't get very far.
>>
>>
>>>Now you can enter the MSYS Build Environment by simply doing
>>>MSYSTEM=MSYS start /msys
>>
>>Calling this, after having done the preparations described, a Windows Command Windows (CMD.EXE) opens.
>>
>>Are these howtos still applicable? Am I missing the obvious?
>>
>>Regards,
>>Torsten
>>
> 
> 
> Use the msysdvlpr command to enter the MSYS Build Environment. I updated 
> the howto accordingly.
> 
> The former method didn't work for me as well, with the msys.bat file 
> shipped in MSYS 1.0.10. It couldn't find rxvt.exe nor sh.exe. The CVS 
> version has a fix for this. If you want, you can get it here:
> http://mingw.cvs.sourceforge.net/*checkout*/mingw/msys/dvlpr/bin/msys.bat
> 
> Regards,
> Cesar
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys

Torsten Schlabach wrote:
> Dear list!
> 
> I am trying to follow the howtos:
> 
> http://www.mingw.org/MinGWiki/index.php/MSYSBuildEnvironment
> http://www.mingw.org/MinGWiki/index.php/Build%20MSYS
> 
> Unfortunately, I don't get very far.
> 
>> Now you can enter the MSYS Build Environment by simply doing
>> MSYSTEM=MSYS start /msys
> 
> Calling this, after having done the preparations described, a Windows Command Windows (CMD.EXE) opens.
> 
> Are these howtos still applicable? Am I missing the obvious?
> 
> Regards,
> Torsten
> 

Use the msysdvlpr command to enter the MSYS Build Environment. I updated 
the howto accordingly.

The former method didn't work for me as well, with the msys.bat file 
shipped in MSYS 1.0.10. It couldn't find rxvt.exe nor sh.exe. The CVS 
version has a fix for this. If you want, you can get it here:
http://mingw.cvs.sourceforge.net/*checkout*/mingw/msys/dvlpr/bin/msys.bat

Regards,
Cesar

Dear list!

I am trying to follow the howtos:

http://www.mingw.org/MinGWiki/index.php/MSYSBuildEnvironment
http://www.mingw.org/MinGWiki/index.php/Build%20MSYS

Unfortunately, I don't get very far.

> Now you can enter the MSYS Build Environment by simply doing
> MSYSTEM=MSYS start /msys

Calling this, after having done the preparations described, a Windows Command Windows (CMD.EXE) opens.

Are these howtos still applicable? Am I missing the obvious?

Regards,
Torsten

Thanks much. I can offer insight into some of the problems that 
frustrated me. Improvements can't be made solely by improving 
instructions in the wiki (but thanks for doing some of that, as you 
comment in a following note).

1) I expected to find installation instructions in the 
download/installation section of mingw.org. But there is no link there 
to the minGWiki! And I had no reason to go to the MinGWiki in the left 
column, precisely because I was trying to find installation instructions.

2) The layout of file releases at sourceforge has columns "Package", 
"Release", "Date", "Notes/Monitor", "Downloads". This may be (partially) 
brain-dead, but it didn't occur to me to click in the left column 
because I was looking for recent releases. So specifically for MSYS, all 
I could see as being available was a "Technology Preview". The wiki 
instructions could alert the reader to this possible mechanism for not 
finding the MSYS installer.

3) Something you can't do anything about, but exacerbated by there being 
no link to installation instructions in the install section of 
mingw.org, is the fact that in my floundering around in Googleland I saw 
different statements about the order in which one should install MinGW 
and MSYS.

A general comment: It seems to be traditional, and I guess it must work 
for the experts, not to provide simple lists of what is in a package. 
For example, if I get the dev package, do I also need the runtime 
package, or is it included? (I've seen both.) The MinGW binary installer 
for Windows is very good in this respect, assuming that the list to 
choose from during installation is in fact complete.

Bruce Sherwood

Keith Marshall wrote:
> On Thursday 31 January 2008 20:05, Bruce Sherwood wrote:
>> I realize my questions must sound hopelessly naive, but I have been
>> able to use msys and mingw productively on Windows; it is the
>> installation that is difficult, and the installation instructions
>> aren't adequate...
> 
> Well, the installation instructions are on the MinGWiki:
> http://www.mingw.org/MinGWiki/index.php/GettingStarted
> 
> They seem fairly comprehensive to me, but sometimes what seems obvious 
> to us `old hands' isn't so obvious to the newcomer.  If you think they 
> are inadequate, then please do contribute by improving them.
> 
> Regards,
> Keith.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys

On Friday 01 February 2008 00:01, JonY wrote:
> The toolchain usually refers to gcc and binutils. About Vista,
> Microsoft changed =A0how msvcrt.dll reacts to access(), normally in XP
> and 2000, X_OK parameter is ignored, but Vista pukes on it. The MinGW
> gcc is affected by it. The patched version is found at:
>
> http://dessent.net/tmp/gcc-vista-3.4.5-20060117-1.tar.gz

We need to get those updates on to the official download page.  John E.,=20
of Twilight Dragon Media has offered to to that for us, but so far it=20
hasn't happened yet.

> For your convenience, you should install MinGW before MSYS. When the
> MSYS installer completes, it will ask for the location of MinGW, [and]=20
> it will automatically edit the mount table for you.

The installation instructions at=20
http://www.mingw.org/MinGWiki/index.php/GettingStarted

do say that, although the reference was a bit vague; I've just made it a=20
little more explicit, without the unnecessary complication of referring=20
to the mount table.

The mount table itself is described in the README files, which accompany=20
MSYS; I *strongly* urge new users to read those.

Regards,
Keith.

On Thursday 31 January 2008 20:05, Bruce Sherwood wrote:
> I realize my questions must sound hopelessly naive, but I have been
> able to use msys and mingw productively on Windows; it is the
> installation that is difficult, and the installation instructions
> aren't adequate...

Well, the installation instructions are on the MinGWiki:
http://www.mingw.org/MinGWiki/index.php/GettingStarted

They seem fairly comprehensive to me, but sometimes what seems obvious 
to us `old hands' isn't so obvious to the newcomer.  If you think they 
are inadequate, then please do contribute by improving them.

Regards,
Keith.

Many thanks! That is precisely the kind of information that someone like 
me needs, and which is hard to find.

Bruce Sherwood

JonY wrote:
> Bruce Sherwood wrote:
>> Thanks, but I have no idea what is meant by "toolchain" nor how I'm 
>> supposed to edit some "mount table", so I don't know what it is I'm 
>> supposed to do, or what the convenience would be.
>>
>> Are you saying that the most recent MinGW doesn't work with Vista? Thet 
>> there's some other MinGW I'm supposed to install?
>>
>> I realize my questions must sound hopelessly naive, but I have been able 
>> to use msys and mingw productively on Windows; it is the installation 
>> that is difficult, and the installation instructions aren't adequate (to 
>> take an immediate example, how would one know without asking that one 
>> must search the archives for "Vista" before doing an install, or change 
>> some mount table -- if you see what I mean).
>>
>> Bruce Sherwood
>>
>> Greg Chicares wrote:
>>> On 2008-01-31 19:01Z, Bruce Sherwood wrote:
>>>
>>>> I've used msys and mingw for several years but wanted to do a clean 
>>>> install on a machine I upgraded from XP to Vista. I've been quite 
>>>> baffled by ambiguous or incomplete installation instructions with 
>>>> respect to installing both msys and mingw. Should I install msys, then 
>>>> mingw, or the other way around? I think I've seen both instructions.
>>> If you always keep them distinct, then it doesn't matter
>>> because neither depends on the other.
>>>
>>> One optional last step for convenience after you've
>>> installed them both is to mount the MinGW toolchain's
>>> directory by editing the MSYS mount table.
>>>
>>> BTW, make sure you get the right MinGW stuff for vista:
>>> search the archives for "vista" or "X_OK".
> 
> Hi,
> 
> The toolchain usually refers to gcc and binutils. About Vista, Microsoft 
> changed  how msvcrt.dll reacts to access(), normally in XP and 2000, 
> X_OK parameter is ignored, but Vista pukes on it. The MinGW gcc is 
> affected by it. The patched version is found at:
> 
> http://dessent.net/tmp/gcc-vista-3.4.5-20060117-1.tar.gz
> 
> For your convenience, you should install MinGW before MSYS. When the 
> MSYS installer completes, it will ask for the location of MinGW, it will 
> automatically edit the mount table for you.
> 
> The mount table for MSYS, by default is located at 
> C:\msys\1.0\etc\fstab. It may contain something like this:
> 
> c:/mingw /mingw
> c:/java /java
> c:/perl /perl
> c:/python25 /python
> 
> It is fairly forward to understand. C:\MinGW will appear as /mingw in 
> MSYS shell.
> 
> Hope that helps.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys

Bruce Sherwood wrote:
> Thanks, but I have no idea what is meant by "toolchain" nor how I'm 
> supposed to edit some "mount table", so I don't know what it is I'm 
> supposed to do, or what the convenience would be.
> 
> Are you saying that the most recent MinGW doesn't work with Vista? Thet 
> there's some other MinGW I'm supposed to install?
> 
> I realize my questions must sound hopelessly naive, but I have been able 
> to use msys and mingw productively on Windows; it is the installation 
> that is difficult, and the installation instructions aren't adequate (to 
> take an immediate example, how would one know without asking that one 
> must search the archives for "Vista" before doing an install, or change 
> some mount table -- if you see what I mean).
> 
> Bruce Sherwood
> 
> Greg Chicares wrote:
>> On 2008-01-31 19:01Z, Bruce Sherwood wrote:
>>
>>> I've used msys and mingw for several years but wanted to do a clean 
>>> install on a machine I upgraded from XP to Vista. I've been quite 
>>> baffled by ambiguous or incomplete installation instructions with 
>>> respect to installing both msys and mingw. Should I install msys, then 
>>> mingw, or the other way around? I think I've seen both instructions.
>>
>> If you always keep them distinct, then it doesn't matter
>> because neither depends on the other.
>>
>> One optional last step for convenience after you've
>> installed them both is to mount the MinGW toolchain's
>> directory by editing the MSYS mount table.
>>
>> BTW, make sure you get the right MinGW stuff for vista:
>> search the archives for "vista" or "X_OK".

Hi,

The toolchain usually refers to gcc and binutils. About Vista, Microsoft 
changed  how msvcrt.dll reacts to access(), normally in XP and 2000, 
X_OK parameter is ignored, but Vista pukes on it. The MinGW gcc is 
affected by it. The patched version is found at:

http://dessent.net/tmp/gcc-vista-3.4.5-20060117-1.tar.gz

For your convenience, you should install MinGW before MSYS. When the 
MSYS installer completes, it will ask for the location of MinGW, it will 
automatically edit the mount table for you.

The mount table for MSYS, by default is located at 
C:\msys\1.0\etc\fstab. It may contain something like this:

c:/mingw /mingw
c:/java /java
c:/perl /perl
c:/python25 /python

It is fairly forward to understand. C:\MinGW will appear as /mingw in 
MSYS shell.

Hope that helps.