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

Keith Marshall wrote:
> Please DO NOT post in HTML; I'll make an exception just once, but 
> henceforth I will delete such messages, unread.
>   
I apologize for violating protocol.

Thank you for your patience.

I agree that Linux is a superior development environment, but I am just 
getting started and I am simply not comfortable working at the *nix 
shell command line after many years of doing everything through GUIs on 
Windows.  I haven't worked with a make file in almost 10 years!  I 
really did not want to have to understand all of the arcana of the 
installation process, so I simply took the first set of instructions 
that I came to and tried to execute them.  It is not my fault if those 
instructions are the wrong instructions and do not actually work.  I 
have been spoiled by applications that come with a GUI installation 
program.  Your advice to follow the *nix procedure was successful.  
Thank you.

-- 
Jim Cobban   jc...@ma...
34 Palomino Dr.
Kanata, ON, CANADA
K2M 1M1
+1-613-592-9438

Please DO NOT post in HTML; I'll make an exception just once, but 
henceforth I will delete such messages, unread.

On Saturday 30 August 2008 21:42:56 Jim Cobban wrote:
>>   $ mkdir -p ~/build/wxWidgets-2.8.8/msw
>>   $ cd !$
>>   $ ../../../src/wxWidgets-2.8.8/configure --prefix=$HOME/mingw32 \
>>       --build=i686-pc-linux --host=mingw32 --with-msw
>>   $ make
>>   $ make install
>>
>> This worked flawlessly, for me.  In your case, you can omit the
>> build and host specs, (because you are using a natively-hosted
>> compiler, where I have a cross-compiler), and use --prefix=/mingw,
>> (because that is where your MinGW-GCC will eventually look for the
>> installed headers and libraries*).
>
>  I am sorry, I understand the meaning of each individual command
> that you suggest issuing, but I don't understand why you are
> issuing them.

The first two, simply because I prefer to keep my source and build 
trees completely isolated.

> The second command only works under Linux of course.

Not at all; it works just the same with bash in MSYS or Cygwin, (or 
indeed, on any platform where bash is run -- in fact, it is C-shell 
shorthand, which bash has adopted).

> But I am not trying to install wxWidgets under Linux.

No.  You are using MSYS as a GNU/Linux-alike environment on Windows.

> I will do that too ... later.  The whole point of the exercise is to
> run the final programs under Windows.  I admit that it would
> probably be easier to develop the application on Linux and just
> port it to Mingw at the last moment,

I am developing on GNU/Linux, for deployment on MS-Windows.  Thus, my 
third command is `configure' for a cross-compiler, which will compile 
directly to MS-Windows binary code, even though the compiler itself 
is run on my GNU/Linux box.  The equivalent command, for native use 
of MinGW from MSYS is

  ../../../src/wxWidgets-2.8.8/configure --prefix=/mingw --with-msw

and the remaining two commands are the same for both cases; all 
together we have the conventional *nix build paradigm.

> which appears to be at the 
> heart of your suggestion, but I am just not comfortable enough yet
> doing development under Linux, and the database the application is
> intended to work on is being created by a 3rd party Windows app,
> which I have not yet been able to get to work effectively under
> Linux.  If I can do the development using Mingw on Windows I can
> save having to reboot my computer to switch over to Linux.

I don't have MS-Windows on my box, at all.  I work exclusively in 
GNU/Linux, cross-compiling MS-Windows binaries, which I test using 
Wine.  Practically all of my code is cross-platform from the outset.

Regards,
Keith.

On 2008-08-30 20:42Z, Jim Cobban wrote:
> 
> Keith Marshall wrote:
[...]
>> This looks like you are using an MSYS + MinGW build environment, but 
>> are trying to follow the MSVC build procedure; that isn't likely to 
>> work.  With MSYS + MinGW, you should use the *nix build method.

Yes, I find that simpler and more robust. An important advantage is
that '--enable' options generally work from one version to the next,
so you don't have to edit 'wx/msw/setup.h' every time you upgrade.

> The instructions for the build explicitly say to NOT use the *nix build method.

http://trac.wxwidgets.org/browser/wxWidgets/trunk/docs/msw/install.txt
| Both Cygwin and MinGW can be used with configure (assuming you have MSYS
| installed in case of MinGW).

> Specifically the install.txt file says:
> 
> NOTE: The makefile.gcc makefiles are for compilation under MinGW using
>       Windows command interpreter (command.com/cmd.exe), they won't work in
>       other environments (such as UNIX or Unix-like, e.g. MSYS where you have
>       to use configure instead, see the section below)

           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Keith Marshall wrote:
<blockquote
 cite="mid:200...@us..."
 type="cite">
  <pre wrap="">On Friday 29 August 2008 18:12:30 Jim Cobban wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Specifically I am trying to install wxWidgets using gcc and the
commands that I issue are:

cd /c/wxWidgets-2.8.8/build/msw
make -f makefile.gcc BUILD=debug
    </pre>
  </blockquote>
  <pre wrap=""><!---->
This looks like you are using an MSYS + MinGW build environment, but 
are trying to follow the MSVC build procedure; that isn't likely to 
work.  With MSYS + MinGW, you should use the *nix build method.
  </pre>
</blockquote>
I also tried issuing the commands directly under the Windows command
prompt, but this did not change the error message.<br>
<br>
The instructions for the build explicitly say to NOT use the *nix build
method.&nbsp; Specifically the install.txt file says:<br>
<br>
<font face="Courier New, Courier, monospace">NOTE: The makefile.gcc
makefiles are for compilation under MinGW using<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Windows command interpreter (command.com/cmd.exe), they won't
work in<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; other environments (such as UNIX or Unix-like, e.g. MSYS where
you have<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to use configure instead, see the section below)<br>
<br>
Here are the steps required using the provided makefiles:<br>
<br>
- Use the makefile.gcc files for compiling wxWidgets and samples,<br>
&nbsp; e.g. to compile a debugging version of wxWidgets:<br>
&nbsp; &gt; cd c:\wx\build\msw<br>
&nbsp; &gt; make -f makefile.gcc BUILD=debug</font><br>
<br>
<blockquote
 cite="mid:200...@us..."
 type="cite">
  <pre wrap="">
Here's what I did, (GNU/Linux + MinGW):

  $ mkdir -p ~/build/wxWidgets-2.8.8/msw
  $ cd !$
  $ ../../../src/wxWidgets-2.8.8/configure --prefix=$HOME/mingw32 \
      --build=i686-pc-linux --host=mingw32 --with-msw
  $ make
  $ make install

This worked flawlessly, for me.  In your case, you can omit the build 
and host specs, (because you are using a natively-hosted compiler, 
where I have a cross-compiler), and use --prefix=/mingw, (because 
that is where your MinGW-GCC will eventually look for the installed 
headers and libraries*).
  </pre>
</blockquote>
I am sorry, I understand the meaning of each individual command that
you suggest issuing, but I don't understand why you are issuing them.&nbsp;
The second command only works under Linux of course.&nbsp; But I am not
trying to install wxWidgets under Linux.&nbsp; I will do that too ...
later.&nbsp; The whole point of the exercise is to run the final programs
under Windows.&nbsp; I admit that it would probably be easier to develop the
application on Linux and just port it to Mingw at the last moment,
which appears to be at the heart of your suggestion, but I am just not
comfortable enough yet doing development under Linux, and the database
the application is intended to work on is being created by a 3rd party
Windows app, which I have not yet been able to get to work effectively
under Linux.&nbsp; If I can do the development using Mingw on Windows I can
save having to reboot my computer to switch over to Linux.<br>
<br>
So bottom line I just want make the installation of wxWidgets work on
Windows.&nbsp; It doesn't right now, and I have no idea how to fix it.<br>
<pre class="moz-signature" cols="72">-- 
Jim Cobban   <a class="moz-txt-link-abbreviated" href="mailto:jc...@ma...">jc...@ma...</a>
34 Palomino Dr.
Kanata, ON, CANADA
K2M 1M1
+1-613-592-9438</pre>
</body>
</html>

It seems that the problem is in the new info.exe (not the new msys dll).

Things seems ok if you replace info.exe (from upgrade) with the one in MSys
1.0.10, keeping
the new msys dll.

I also tested new info with old msys dll, and the problem is still there. 

So new info.exe does not work.

Regards.
 

-- 
View this message in context: http://www.nabble.com/info%2C-less-etc-not-working-after-update-tp19232562p19236777.html
Sent from the MinGW - MSYS mailing list archive at Nabble.com.

JonY wrote:
> Hi,
> try typing "type -p make" under MSYS to see which make is invoked.
>   
This returns /bin/make.

> It is also possible that the Makefile is designed to run under the 
> "Command Prompt" instead of MSYS. In that case, use "mingw32-make" 
> instead of "make".
>   
If I just use "make" at the Windows command prompt I get exactly the 
same error as under Msys.  If I use "mingw32-make" from the command 
prompt I get:

process_begin: CreateProcess(NULL, -c "if not exist gcc_mswd mkdir 
gcc_mswd", ...) failed.
make (e=2): The system cannot find the file specified.
mingw32-make: [gcc_mswd] Error 2 (ignored)
if not exist ..\..\lib\gcc_lib mkdir ..\..\lib\gcc_lib
process_begin: CreateProcess(NULL, -c "if not exist ..\..\lib\gcc_lib 
mkdir ..\..\lib\gcc_lib", ...) failed.
make (e=2): The system cannot find the file specified.

-- 
Jim Cobban   jc...@ma...
34 Palomino Dr.
Kanata, ON, CANADA
K2M 1M1
+1-613-592-9438

You are right. There is a problem after the upgrade.
I did not get the same error message. info was not able to find the gcc.info
file.

How to confirm this:

First, to be sure that i have a clean and clear  situation, i completely
uninstalled MSYS.
I first used the uninstall procedure, which did not completely removed MSys.
So, i delete the MSys directory and all of its subdirectory.

I then, installed MSys 1.0.10.
info is working fine. do find *.info files in MingW and also do find *.info
files
pointed to by the INFOPATH env var.

ie: INFOPATH=E:\MingW\info;E:\cygwin\usr\share\info

Then i tried to untar the MSYS-1.0.11-20080821-dll.tar file.
Did not worked, because MSys tar do used (and lock) the MSys dll. On
Windows platform, a locked file cannot be replaced like this.

So i used Winzip to install the new dll, (TAR file smart CR/LF conversion
OFF)
and tried info again. Every thing is still ok.

You should know, that msysCore contains a newer msys dll.
After installing msysCORE-1.0.11-20080826.tar with Winzip, because tar
cannot replace the
locked MSys dll, info was not completely working.

The info files in MingW\info, (gcc.info for example), were not accessible
anymore.
info give error: Unable to find node referenced by `gcc' in `(dir)Top'

The other info files, those  in E:\cygwin\usr\share\info, were still
available to info.

So, there is a problem with the upgrade.

fstab contains only: E:/MingW /mingw
Path=E:\MSys\bin;E:\Msys\local\bin;E:\MingW\bin

Hope that helps to fix the problem.

Regards.

-- 
View this message in context: http://www.nabble.com/info%2C-less-etc-not-working-after-update-tp19232562p19236518.html
Sent from the MinGW - MSYS mailing list archive at Nabble.com.

Zuxy Meng wrote:
> Hi,
> 
> Recently I extracted MSYS-1.0.11-20080821-dll.tar.gz  and 
> msysCORE-1.0.11-20080826.tar.gz  to my existing MSYS installation but 
> unfortunately some commands cease to work after the update:
> 
> C:\MSYS\home\Zuxy>info gcc
> info: Terminal type `cygwin' is not smart enough to run Info.
> 
> What's the problem? Is there any workaround?
> 

I am not seeing such a problem in my installation. Could you try 
unpacking msysCORE-1.0.11-20080826.tar.gz in a fresh directory and try 
it again?

Regards,
Cesar

Hi,

Recently I extracted MSYS-1.0.11-20080821-dll.tar.gz  and 
msysCORE-1.0.11-20080826.tar.gz  to my existing MSYS installation but 
unfortunately some commands cease to work after the update:

C:\MSYS\home\Zuxy>info gcc
info: Terminal type `cygwin' is not smart enough to run Info.

What's the problem? Is there any workaround?

-- 
Zuxy 

On Friday 29 August 2008 18:12:30 Jim Cobban wrote:
> Specifically I am trying to install wxWidgets using gcc and the
> commands that I issue are:
>
> cd /c/wxWidgets-2.8.8/build/msw
> make -f makefile.gcc BUILD=debug

This looks like you are using an MSYS + MinGW build environment, but 
are trying to follow the MSVC build procedure; that isn't likely to 
work.  With MSYS + MinGW, you should use the *nix build method.

Here's what I did, (GNU/Linux + MinGW):

  $ mkdir -p ~/build/wxWidgets-2.8.8/msw
  $ cd !$
  $ ../../../src/wxWidgets-2.8.8/configure --prefix=$HOME/mingw32 \
      --build=i686-pc-linux --host=mingw32 --with-msw
  $ make
  $ make install

This worked flawlessly, for me.  In your case, you can omit the build 
and host specs, (because you are using a natively-hosted compiler, 
where I have a cross-compiler), and use --prefix=/mingw, (because 
that is where your MinGW-GCC will eventually look for the installed 
headers and libraries*).

> I am puzzled that the install created two separate directories on
> my hard drive:  Msys/1.0 and MinGW.

This is correct.  In particular, if you are using an MSYS version 
prior to MSYS-1.0.11, then the two *must* be kept separate, and for 
later MSYS, it is still recommended to adopt this practice.

> I tried pointing my PATH 
> explicitly to C:\MinGW\bin, but that did not change the behavior.

It should already be there, as /mingw/bin;  MSYS maps this through its 
fstab, (/etc/fstab), to the native path for C:/MinGW/bin.

Regards,
Keith.

[*] One issue I did note: the make install put the wxDLLs in the wrong 
path; it put them in $prefix/lib, where they should be in $prefix/bin

Jim Cobban wrote:
> I have just installed MinGw 5.1.4 on Windows XP and I can get everything
> to work except make.  When I run make I get an error message "make :
> C:WINDOWSSystem32cmd.exe" : Command not found".  It would appear that
> the problem is that there are no slashes or backslashes in the file
> name.  I have checked my PATH and the contents of other environment
> variables and I cannot see anything under my control that would cause this.
>
> Specifically I am trying to install wxWidgets using gcc and the commands
> that I issue are:
>
> cd /c/wxWidgets-2.8.8/build/msw
> make -f makefile.gcc BUILD=debug
>
> I am puzzled that the install created two separate directories on my
> hard drive:  Msys/1.0 and MinGW.  I tried pointing my PATH explicitly to
> C:\MinGW\bin, but that did not change the behavior.
>

Hi,
try typing "type -p make" under MSYS to see which make is invoked.

Is there a "make" in places other than "/bin/make"?

It is also possible that the Makefile is designed to run under the 
"Command Prompt" instead of MSYS. In that case, use "mingw32-make" 
instead of "make".

> Why would you want to do that?

Because i am an alien who comes from a Windows world. I worked with
cygwin who maps /usr at the "other correct place".

>> So, the msys executables should not be executed in window console
>> (cmd.exe).

> Can't imagine any reason to do that.

Well, we are free to use our imagination to imagine strange ways to use
tools
done by others.

As long it's not against the law or nature..

> Possibly.  I never even dreamt of trying it.

I did :-) ( and i guess i am not alone )

>> And, is it a bug ?
> No.

You are right. I just tried it works ok. 
MSYS tar does honor the mounts point.

I am sorry...

But, I used both MSYS tar and, (cough) Winzip to untar the packages.
It works for the packages who dont includes /usr/local files.

Even if there are good reasons to have it implement in this way, this is
confusing
and not standard. In my view, this somewhat contribute to make the MSYS
installation
a little harder.

Thanks for your work and attention.
Regards

-- 
View this message in context: http://www.nabble.com/-usr-mounted-on-E%3A-MSys-instead-of-E%3A-MSys-usr-tp19224784p19228317.html
Sent from the MinGW - MSYS mailing list archive at Nabble.com.

On Friday 29 August 2008 22:32:51 Carlos-2 wrote:
> > use the MSYS  tar command to install or update MSYS components.
>
> That's what i did.

Ok.

> But, tar was executed in a window (cmd.exe) console (not under the
> msys sh). ie:

Why would you want to do that?

> E:\> cd MSys
> E:\MSys> tar -xf MSYS-archive.tar
>
> So, the msys executables should not be executed in window console
> (cmd.exe).

Can't imagine any reason to do that.

> because  then, they do not respect the mounts. 
>
> Is that correct ?

Possibly.  I never even dreamt of trying it.

> And, is it a bug ?

No.

Regards,
Keith.

> This is correct, and intentional.  There are sound technical reasons 
> for keeping it this way.

Ok. Wont argue this. :-)

> you have presumably used some unsupported Windows archive 

No. Only stuff from MSYS official distribution on SF.

> use the MSYS  tar command to install or update MSYS components.

That's what i did.

But, tar was executed in a window (cmd.exe) console (not under the msys sh).
ie:

E:\> cd MSys
E:\MSys> tar -xf MSYS-archive.tar

So, the msys executables should not be executed in window console (cmd.exe).
because  then, they do not respect the mounts.

Is that correct ?
And, is it a bug ?



-- 
View this message in context: http://www.nabble.com/-usr-mounted-on-E%3A-MSys-instead-of-E%3A-MSys-usr-tp19224784p19227777.html
Sent from the MinGW - MSYS mailing list archive at Nabble.com.

On Friday 29 August 2008 19:02:26 Carlos-2 wrote:
> I tried to mount /usr on E:/Msys/usr to no avail. Looks like /usr
> is permanently assigned and cannot be reassigned.

This is correct, and intentional.  There are sound technical reasons 
for keeping it this way.

> So, i made a copy of E:/MSys/usr/local

You should never have had any such directory, in the first place.  To 
create it, you have presumably used some unsupported Windows archive 
tool to unpack MSYS tarballs.  You should not do that; use the MSYS 
tar command to install or update MSYS components.

> under E:/MSys/local,

This the correct native path for /usr/local, in a standard MSYS 
installation.

> and all the "not found" commands becamed usable.
> (Because /usr is synonym of E:/Msys) 

As one might expect.

> How can we fix the /usr mount point ?

Why try to "fix" what isn't broken?  Fix your installation instead.  
You have already moved the /usr/local tree to its proper location.  
You may

  $ rm -rf /usr/usr

to get rid of the improperly installed copy.  Now use MSYS tar to 
manage and update your system.

Regards,
Keith.

On Friday 29 August 2008 19:10:44 Carlos-2 wrote:
> > seriously consider using Cygwin instead.  The MSYS System Builder
> > is not intended for such use; we do not tout it as an alternative
> > to Cygwin, (from which it is derived anyway, but it is a
> > derivative of an ancient Cygwin version).
>
> Ah, i did not knew that. This is interesting.
> I wont install MSYS sys builder then.
>
> Does it mean i could (possibly after some tweaking), use Cygwin to
> build MingW apps that have been auto-tooled ?

Yes, that is quite feasible, but you can also use MSYS for this 
purpose.  You do not need the System Builder to *use* MSYS; it is 
only necessary for those who *build* MSYS itself, (i.e. our own 
project developers).

Regards,
Keith.

> seriously consider using Cygwin instead.  The MSYS System Builder is 
> not intended for such use; we do not tout it as an alternative to 
> Cygwin, (from which it is derived anyway, but it is a derivative of 
> an ancient Cygwin version).

Ah, i did not knew that. This is interesting.
I wont install MSYS sys builder then.

Does it mean i could (possibly after some tweaking), use Cygwin to build
MingW apps that have been auto-tooled ?


-- 
View this message in context: http://www.nabble.com/Msys-installation-procedure-tp19136423p19224904.html
Sent from the MinGW - MSYS mailing list archive at Nabble.com.

Hi!,

I am trying to build the "D" compiler for MingW. This needs a lot of
pre-requisites.
I have installed almost of the most recent stuff for MSys.
Even then, there was some packages that cannot be found.

I think theses errors are related to the fact that /usr is mounted ont
E:/Msys instead
of E:/Msys/usr.

I tried those commands in sh, and as expected, they were not available, even
if they
were installed correctly.

I tried to mount /usr on E:/Msys/usr to no avail. Looks like /usr is
permanently assigned and
cannot be reassigned.

So, i made a copy of E:/MSys/usr/local under E:/MSys/local, and all the "not
found" commands 
becamed usable. (Because /usr is synonym of E:/Msys)

How can we fix the /usr mount point ?


-- 
View this message in context: http://www.nabble.com/-usr-mounted-on-E%3A-MSys-instead-of-E%3A-MSys-usr-tp19224784p19224784.html
Sent from the MinGW - MSYS mailing list archive at Nabble.com.

I have just installed MinGw 5.1.4 on Windows XP and I can get everything 
to work except make.  When I run make I get an error message "make : 
C:WINDOWSSystem32cmd.exe" : Command not found".  It would appear that 
the problem is that there are no slashes or backslashes in the file 
name.  I have checked my PATH and the contents of other environment 
variables and I cannot see anything under my control that would cause this.

Specifically I am trying to install wxWidgets using gcc and the commands 
that I issue are:

cd /c/wxWidgets-2.8.8/build/msw
make -f makefile.gcc BUILD=debug

I am puzzled that the install created two separate directories on my 
hard drive:  Msys/1.0 and MinGW.  I tried pointing my PATH explicitly to 
C:\MinGW\bin, but that did not change the behavior.

-- 
Jim Cobban   jc...@ma...
34 Palomino Dr.
Kanata, ON, CANADA
K2M 1M1
+1-613-592-9438

Hi,

On Tue, 26 Aug 2008, Florian Schricker wrote:

> I am trying to get "svncopy.pl" working on my MSYS installation. It's a 
> Perl script for SVN which let's you tag releases easily, esp. when 
> externals are involved.
> 
> As a dep, this script mentions Perl 5.8.0.
> 
> Has anyone any pointers on how to install Perl 5.8.0 on a (my) MSYS
> installation?

We have succeeded in building it for msysGit, with the same intention of 
getting SVN's Perl binding to run.

The biggest PITA was not even getting Perl to run, but the Subversion 
bindings.

You might get inspiration from looking at the script we used to download 
and build all required packages:

http://repo.or.cz/w/msysgit.git?a=tree;f=src/perl;h=72efa74e109a9f10ea8fa6940d3efc6d43c99ce1;hb=refs/heads/msys

(It is the script "release.sh", and getting it to run should be as easy as 
downloading the snapshot 
http://repo.or.cz/w/msysgit.git?a=snapshot;h=refs/heads/msys;sf=tgz 
unpacking it and calling msys.bat, then "cd /src/perl && sh release.sh", 
although the last steps will fail, since you do not have Git installed)

Hth,
Dscho

Florian Schricker wrote:
> I am trying to get "svncopy.pl" working on my MSYS installation. It's
> a Perl script for SVN which let's you tag releases easily, esp. when
> externals are involved.
> 
> As a dep, this script mentions Perl 5.8.0.
> 
> Has anyone any pointers on how to install Perl 5.8.0 on a (my) MSYS
> installation?

Install ActiveState's Perl in a directory with no spaces in the name, eg,
C:\ActiveState\Perl58, and place the bin directory at the front of your path.

http://www.activestate.com/Products/activeperl/index.mhtml

Florian Schricker wrote:
> Has anyone any pointers on how to install Perl 5.8.0 on a (my) MSYS
> installation?

I wrestled with it for about a week before finally giving up. The
msys-target compiler is gcc-2.95.3, and that coupled with the ancient
vintage cygwin on which msys is based means that newer perl just doesn't
build.  Sorry.

I suggest using installing cygwin, and using its (much more modern)
tools to manage your SVN repo.

--
Chuck

Hello dear MSYS-users,


I am trying to get "svncopy.pl" working on my MSYS installation. It's
a Perl script for SVN which let's you tag releases easily, esp. when
externals are involved.

As a dep, this script mentions Perl 5.8.0.

Has anyone any pointers on how to install Perl 5.8.0 on a (my) MSYS
installation?


Thanks in advance and regards,
Florian

PS: please CC me when replying as I am reading the list in digest mode

On Monday 25 August 2008 05:50:12 JonY wrote:
> Applications compiled for MSYS will only work under MSYS.

Applications compiled for MSYS should be considered as part of MSYS 
itself; only those who participate in MSYS development should ever 
need to create such applications.

> > Now, i am grateful for your work, but it is still not clear to me
> > how to install MSYS without asking here.
>
> The steps are as follows:
>
> 1. Use the MSYS setup exe to install MSYS
> 2. Install MsysDTK (Optional)
> 3. Install updated MSYS tools (recommended)

This is as far as the vast majority of users should ever need to go.

> 4. Install MSYS system builder.

This step is only necessary for those who would like to participate in 
the project, as developers of MSYS itself; if you find yourself using 
the MSYS System Builder tools for any other purpose, then you should 
seriously consider using Cygwin instead.  The MSYS System Builder is 
not intended for such use; we do not tout it as an alternative to 
Cygwin, (from which it is derived anyway, but it is a derivative of 
an ancient Cygwin version).

Regards,
Keith.

Carlos-3 wrote:
>> I specifically wrote to install to /mingw because it avoids the huge
>> mess when/if you do install MSYS versions of autotools (MSYS versions
>> being that they should only be used internally with MSYS, never with
>> MinGW) for msysdvlpr.
>
> Thanks, that helps.
>
> I have another question:
>
> Sourceforge, display 3 (or 4) sections of downloadables files or MSYS.
>
> 1. Msys base
> 2. Msys supplementary tools
>     2.1 Msys-dtk
> 3. Msys system builder.
>
> Let's say i download every thing.
>
> How do i install Msys tools + Msys dtk ?
> How do i install Msys system builder ?
>
> Some program (like autoconf) exist in many versions.
>
> Is it ok to say, that , as a general rule, i simply untar/unzip any
> package containing the word MSYS in it's name, in the c:/Msys/1.0
> directory to be safe ?
>

Use the tar program that came with MSYS, avoid WinZip or other Windows 
based untar utilities. Unpack the MSYS packages to "/".

Having MSYS system builder installed comes with several caveats, one 
being the MSYS targeting MSYS must not interfere or used when under 
MinGW mode. Make sure the libs meant for MSYS is not found when under 
MinGW mode, vice versa when under MSYS mode.

Applications compiled for MSYS will only work under MSYS.

> Now, i am grateful for your work, but it is still not clear to me how to
> install MSYS without asking here.
>

The steps are as follows:

1. Use the MSYS setup exe to install MSYS
2. Install MsysDTK (Optional)
3. Install updated MSYS tools (recommended)
4. Install MSYS system builder.

> And then, there is still another project who produce still another version
> of
> autoconf: GnuWin32.
>

GnuWin32 is a separate project, most GnuWin32 tools can be used under 
MinGW. I've never used the GnuWin32 autoconf, so I can't say if it works 
or not.

> If that may help you, i can write a small document containing all the
> questions i
> have. Those are the questions for "not exactly a newbe" but "not exactly a
> pro"
> Mingw type of user.
>
Sure, you can suggest improvements for the MSYS wiki page too.

> Thanks
>
>
>