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

Julien Lecomte wrote, quoting Greg Chicares:
>> I, too, frequently copy and paste to or from an MSYS shell,
>> but without using rxvt. Copy, by holding down the left button
>> and dragging the highlight over a rectangular region (which
>> can extend over more than one physical screen) then pressing
>> Enter. Paste, with the sequence 'alt-Spacebar E P' (icky, but
>> I've gotten used to it). This requires tweaking
>>   Properties | Options | Edit Options
>> but that only has to be done once.

Hmm.  No need to switch from mouse to keyboard, IME.  If you've
tweaked those "Properties/Options/Edit Options" to enable *both*
"Quick Edit Mode" and "Insert Mode", use the left button to drag
the highlight, as Greg describes, then click the right button once
to copy; each subsequent right click will paste.  (This is with
the MSYS shell in a native Win32 console on Win2K).

>> Am I missing anything aside from easier-to-use cut and paste
>> commands? I don't understand the point about fonts--I tried
>> copying from rxvt (with 'Lucide Console') to ms 'word', but
>> it pasted as times roman.

I *never* use MS-Weird -- groff is my preferred tool for document
processing -- but this is consistent with my experience pasting
from the MSYS shell into other Windows applications, (i.e. the
format specification in the destination overrides the font used
in the console).

> I think you should use the ~/.inputrc and /etc/inputrc files :
> 
http://sourceforge.net/tracker/index.php?func=detail&aid=1402213&group_id=2435&atid=102435

>
> More details can be found on the latter webpage.
>
> It binds the insert key to "paste-from-clipboard"; in other words,
> no longer do you have to "alt-space E P".
>
> This works for both, RXVT(term=msys) and Console(term=cygwin).

I haven't tried this; undoubtedly it will also work, and is well
worth considering, if it suits your way of working.  Thanks Julien.

The readline configuration, (which is what is established through
/etc/inputrc and ~/.inputrc), can also be customised for the shell,
using the `bind' command.  I find the following useful, in my
~/.profile:

   bind 'set completion-ignore-case on'
   bind '"\e[A":history-search-backward'
   bind '"\e[B":history-search-forward'
   bind '"\e[7~":beginning-of-line'
   bind '"\e[8~":end-of-line'
   bind '"\e[3~":delete-char'

The first makes `tab completion' insensitive to case distinctions
in file names, which to me makes more sense than the default case
sensitive matching mode, for the `case retentive but insensitive'
nature of the Win32 file system.  (This works best, when

   shopt -s nocaseglob

is also set).

Anyone who has ever used 4-DOS will appreciate the next pair; they
allow me to type the first few characters of a command, then use
the cursor-up and cursor-down keys to navigate the history, picking
out only those previous commands which match at start of line.

The final three make the `Home', `End' and `Delete' keys work in a
sane manner.

These work with my particular keyboard map; YMMV.  You can use
`cat -v' to check the particular scan codes returned by your own
keyboard -- invoke the `cat -v' command, type each key for which
you want to see the scan code, followed by the `Return' key;
finally, hit `Ctrl-D' on a line by itself, to quit.

HTH,
Keith.

Earnie Boyd wrote, quoting me:
>> The alternative is to do as Julien and I do -- rapidly condemn
>> RXVT to the trash, to get sane behaviour in a native Win32
>> console :-)
>
> Responding to your insistance on removing RXVT, there are good
> things about RXVT that make it worth keeping around.

The ONLY real advantage I've ever observed is faster scrolling text
in the RXVT window, compared to the native Win32 console.  (Ok, it
also supports easier window resizing, but for me that's a VERY
limited benefit).

I DON'T insist on removing RXVT; that would be diminishing the user's
choice -- very much contrary to the ethos of free software!  However,
the issues keep cropping up:  RXVT is problematic; for users who are
experiencing the problems to their disadvantage, I'm simply pointing
out that there IS an alternative, which may be better suited to their
needs; that is to junk RXVT, and run the MSYS shell in a native Win32
console window, where I find its behaviour to be much more stable
and sane.

> In my real job I support many applications across many servers and
> server flavors.  I am constantly using the highlight to copy to the
> clipboard and then paste by hitting the middle mouse button in some
> command for either that window or a different window.

I make extensive use of that feature too, but I DON'T need RXVT
to make it work.  In Win2K, I set up the console window properties,
such that both "Quick Edit Mode" and "Insert Mode" are active, in the 
"Properties/Options/Edit Options" category.  The only differences I
have to adapt to are that I use the right mouse button, where RXVT
would use the middle button, and I need ONE additional right button
click, after dragging with the left button to highlight text, to
initially COPY the highlighted text to the clipboard; each right
click thereafter, is a PASTE, just as your middle click would be.
That also works to paste into a different window, except that if
the destination is not also a console window, then I probably need
to use Ctrl-V, (or right click and select PASTE from the context
menu), to complete the paste operation.  (And yes, it DOES work
equally well when the destination window is connected to an
application running on a GNU/Linux server, a SunOS server,
or a VMS server, all of which I have to support).

> I also find myself highlighting the output of some command and
> pasting into an email in 'Lucinda Console' font.  I'm so used to
> RXVT I couldn't live without it without becoming frustrated.

I also use "Lucida Console" as my font of choice, in the native
Win32 console, and I copy and paste from there to my email client,
when I post examples to this list -- the pasted font usually gets
changed to "Courier New", but that's a feature of my email client,
which applies the formatting of the surrounding text to the pasted
text, at the point of insertion.

Regards,
Keith.

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3598184
By: earnie

The download page issue at hand is actually a MinGW problem and not a SourceForge
anomaly.  MinGW is not using the FRS the way that SF intended it to be used.
Therefore the onus of issue becomes ours to resolve when SF ``improves'' their
vision of how the FRS looks and feels.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3597978
By: nonperson

> I'm raising a support request, asking them to
> revert this nonsense; no doubt they'll ignore
> it.

MinGW project is currently number 17 in top 25 projects list. You'd think that
would lend you some credibility.

---
17. MinGW - Minimalist GNU for Windows
https://sourceforge.net/projects/mingw
MinGW: import libraries and header files for use with GCC to build
native Windows applications; now with added extensions to the MSVC
runtime to support C99 functionality.
---


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

On 25/02/2006 02:16, Greg Chicares wrote:
> 
> I, too, frequently copy and paste to or from an MSYS shell,
> but without using rxvt. Copy, by holding down the left button
> and dragging the highlight over a rectangular region (which
> can extend over more than one physical screen) then pressing
> Enter. Paste, with the sequence 'alt-Spacebar E P' (icky, but
> I've gotten used to it). This requires tweaking
>   Properties | Options | Edit Options
> but that only has to be done once.
> 
> Am I missing anything aside from easier-to-use cut and paste
> commands? I don't understand the point about fonts--I tried
> copying from rxvt (with 'Lucide Console') to ms 'word', but
> it pasted as times roman.

I think you should use the ~/.inputrc and /etc/inputrc files :

http://sourceforge.net/tracker/index.php?func=detail&aid=1402213&group_id=2435&atid=102435

More details can be found on the latter webpage.

It binds the insert key to "paste-from-clipboard"; in other words, no 
longer do you have to "alt-space E P".

This works for both, RXVT(term=msys) and Console(term=cygwin).

Julien

On 2006-2-24 23:24 UTC, Earnie Boyd wrote:
> 
> Responding to your insistance on removing RXVT, there are good things
> about RXVT that make it worth keeping around.  In my real job I support
> many applications across many servers and server flavors.  I am
> constantly using the highlight to copy to the clipboard and then paste
> by hitting the middle mouse button in some command for either that
> window or a different window.  I also find myself highlighting the
> output of some command and pasting into an email in 'Lucinda Console'
> font.  I'm so used to RXVT I couldn't live without it without becoming
> frustrated.

I, too, frequently copy and paste to or from an MSYS shell,
but without using rxvt. Copy, by holding down the left button
and dragging the highlight over a rectangular region (which
can extend over more than one physical screen) then pressing
Enter. Paste, with the sequence 'alt-Spacebar E P' (icky, but
I've gotten used to it). This requires tweaking
  Properties | Options | Edit Options
but that only has to be done once.

Am I missing anything aside from easier-to-use cut and paste
commands? I don't understand the point about fonts--I tried
copying from rxvt (with 'Lucide Console') to ms 'word', but
it pasted as times roman.

Quoting Keith Marshall <kei...@us...>:

> On Friday 24 February 2006 4:17 pm, Keith MARSHALL wrote:
>> By default, stdout is *line* buffered, so an automatic flush
>> should occur when you emit a newline.
>
> And I neglected to mention that, when connected to a tty type device, its
> default mode is supposed to become *unbuffered*; IIRC, it's failure to
> make this switch in buffering mode that causes so many problems in MSYS'
> RXVT.
>

It is really the inability to control the buffer mode of the spawned 
process.  Stdin and stderr are always unbuffered while stdout is always 
buffered by default.  The new Console APIs may help but only for XP and 
beyond.  I haven't had time to check them out.


Earnie Boyd

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Quoting Keith MARSHALL <kei...@to...>:

>
> By default, stdout is *line* buffered, so an automatic flush
> should occur when you emit a newline.

There wouldn't be an issue with RXVT if MSVCRT did that!


Earnie Boyd

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Quoting Keith MARSHALL <kei...@to...>:

> Earnie Boyd wrote, quoting me:
>>> Simon wrote:
>
>>>
>>>> Also, when programming for windows, is there a way to output to
>>>> the msys shell?
>>>
>>> What exactly do you mean?
>>
>> It's probably RXVT.  Simon needs to flush the output buffers with
>> ``_flushall();''.
>
> Doh!  I should have thought of that!
>
> The alternative is to do as Julien and I do -- rapidly condemn RXVT
> to the trash, to get sane behaviour in a native Win32 console :-)
>

Responding to your insistance on removing RXVT, there are good things 
about RXVT that make it worth keeping around.  In my real job I support 
many applications across many servers and server flavors.  I am 
constantly using the highlight to copy to the clipboard and then paste 
by hitting the middle mouse button in some command for either that 
window or a different window.  I also find myself highlighting the 
output of some command and pasting into an email in 'Lucinda Console' 
font.  I'm so used to RXVT I couldn't live without it without becoming 
frustrated.


Earnie Boyd

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

On Friday 24 February 2006 4:37 pm, Brian Dessent wrote:
> Keith MARSHALL wrote:
> > The alternative is to do as Julien and I do -- rapidly condemn RXVT
> > to the trash, to get sane behaviour in a native Win32 console :-)
>
> I think you need to be more specific in your automatic condemnation of
> rxvt, because you are specifically talking about the MSYS rxvt.  I have
> been using the Cygwin rxvt for years and it works like a dream without
> any of this nonsense about not being able to build certain programs.
> Going back to CMD.EXE would be torture.

I don't advocate going back to cmd.exe; I agree that to do so would be 
torture.  I'm talking about running MSYS' bash shell in a native Win32 
consolle window, where its behaviour is sane.  MSYS' RXVT is just too 
badly broken for the day to day service I demand from the shell, so I 
don't use it.  In the native console, I get a fully functional bash shell 
which is properly behaved.

I did try Cygwin's RXVT implementation briefly; a backspace key that 
could only with difficulty be coaxed into performing its proper function, 
and then only at the command line, reverting to emitting DEL characters 
in vim, very quickly put me off that too.  Oh, and trying to change the 
font size to something approaching usability broke the character spacing, 
such that there appeared to be an extra space character between each 
non-space; nope, I wasn't impressed by that either!

The only place I've found an xterm to be even remotely usable on Win32 is 
the Konsole in KDE-Cygwin, but KDE-Cygwin is just soooooooo dreadfully 
slooooooooow!

Regards,
Keith.

On Friday 24 February 2006 4:17 pm, Keith MARSHALL wrote:
> By default, stdout is *line* buffered, so an automatic flush
> should occur when you emit a newline.

And I neglected to mention that, when connected to a tty type device, its 
default mode is supposed to become *unbuffered*; IIRC, it's failure to 
make this switch in buffering mode that causes so many problems in MSYS' 
RXVT.

Regards,
Keith.

T24gMi8yNC8wNiwgQnJpYW4gRGVzc2VudCA8YnJpYW5AZGVzc2VudC5uZXQ+IHdyb3RlOgo+IEkg
dGhpbmsgeW91IG5lZWQgdG8gYmUgbW9yZSBzcGVjaWZpYyBpbiB5b3VyIGF1dG9tYXRpYyBjb25k
ZW1uYXRpb24gb2YKPiByeHZ0LCBiZWNhdXNlIHlvdSBhcmUgc3BlY2lmaWNhbGx5IHRhbGtpbmcg
YWJvdXQgdGhlIE1TWVMgcnh2dC4gIEkgaGF2ZQo+IGJlZW4gdXNpbmcgdGhlIEN5Z3dpbiByeHZ0
IGZvciB5ZWFycyBhbmQgaXQgd29ya3MgbGlrZSBhIGRyZWFtIHdpdGhvdXQKPiBhbnkgb2YgdGhp
cyBub25zZW5zZSBhYm91dCBub3QgYmVpbmcgYWJsZSB0byBidWlsZCBjZXJ0YWluIHByb2dyYW1z
Lgo+IEdvaW5nIGJhY2sgdG8gQ01ELkVYRSB3b3VsZCBiZSB0b3J0dXJlLgoKSSd2ZSBiZWVuIGZh
aXJseSBzYXRpc2ZpZWQgY3JlYXRpbmcgYSAiRE9TIEJveCIgd2luZG93IHJ1bm5pbmcgc2g7IEkK
aGF2ZSBhIHdpbmRvd3Mgc2hvcnRjdXQgd2l0aCAiQzpcaGFja2luZ1xNU3lzXGJpblxzaC5leGUg
LS1sb2dpbiAtaSIKYXMgaXRzIHRhcmdldCBhbmQgIkM6XGhhY2tpbmdcTVN5c1xob21lXGNoZXNr
eSIgYXMgaXRzICJTdGFydCBpbjoiCmRpcmVjdG9yeS4gIFNldCB0aGUgc2NyZWVuIGJ1ZmZlciBz
aXplIHRvIGl0cyBtYXhpbXVtIDk5OTkgYW5kIG1vc3QKcHJvZ3JhbXMgd29yayBwcmV0dHkgd2Vs
bC4KCi0tSm9lbAo=

Keith MARSHALL wrote:

> The alternative is to do as Julien and I do -- rapidly condemn RXVT
> to the trash, to get sane behaviour in a native Win32 console :-)

I think you need to be more specific in your automatic condemnation of
rxvt, because you are specifically talking about the MSYS rxvt.  I have
been using the Cygwin rxvt for years and it works like a dream without
any of this nonsense about not being able to build certain programs. 
Going back to CMD.EXE would be torture.

Brian

Greg Chicares wrote:
> Here's an MSYS-without-rxvt session:
>
>   $cat hello_world_no_flush.cpp
>   #include <iostream>
>
>   int main()
>   {
>       std::cout << "Hello, world!";
>   }
>   $/c/MinGW-20050120/bin/g++ hello_world_no_flush.cpp
>   $./a
>   Hello, world!$
>
> which can be seen as a cockpit error (no newline, no flush),

With respect Greg, that's perfectly correct behaviour, (and it's
exactly what I see with identical code, on my GNU/Linux box).

By default, stdout is *line* buffered, so an automatic flush
should occur when you emit a newline.  But your code never emits
a newline, so what you see is your output automatically flushed
on process termination, followed by the shell prompt; there's no
intervening newline, because *you* omitted it -- if you want it,
then you need:

    std::cout << "Hello, world!\n";

or, perhaps

    std::cout << "Hello, world!" << std::endl;

Your zsh example is more puzzling though.  Perhaps the shell
returns the cursor to the leftmost column, without a line advance,
and issues a `delete to end of line' request, before issuing the
prompt?  That would flash the output very briefly, perhaps too
briefly to even see, then immediately erase it before displaying
the next prompt.

Regards,
Keith.

On 2006-2-24 12:57 UTC, Keith MARSHALL wrote:
> Earnie Boyd wrote, quoting me:
> 
>>>Simon wrote:
> 
>>>>Also, when programming for windows, is there a way to output to
>>>>the msys shell?
>>>
>>>What exactly do you mean?
>>
>>It's probably RXVT.  Simon needs to flush the output buffers with 
>>``_flushall();''.

Or, using standard functions (which, unlike _flushall(), flush
only the streams and not the OS buffers):

    /* C */
    fflush(0);

    // C++
    std::cout << std::flush;
    std::cerr << std::flush;
    std::clog << std::flush;

> The alternative is to do as Julien and I do -- rapidly condemn RXVT
> to the trash, to get sane behaviour in a native Win32 console :-)

I do that too, but alone it's not quite enough.
Here's an MSYS-without-rxvt session:

  $cat hello_world_no_flush.cpp
  #include <iostream>

  int main()
  {
      std::cout << "Hello, world!";
  }
  $/c/MinGW-20050120/bin/g++ hello_world_no_flush.cpp
  $./a
  Hello, world!$

which can be seen as a cockpit error (no newline, no flush),
except that it's worse in zsh:

  msw-native port of zsh-3.0.5:

  C:/tmp[0]$echo $ZSH_VERSION
  3.0.5-nt-beta-0.75
  C:/tmp[0]$./a
  C:/tmp[0]$

  cygwin-built zsh-4.2.4:

  /cygdrive/c/tmp[0]$echo $ZSH_VERSION
  4.2.4
  /cygdrive/c/tmp[0]$./a
  /cygdrive/c/tmp[0]$

Earnie Boyd wrote, quoting me:
>> Simon wrote:

>>
>>> Also, when programming for windows, is there a way to output to
>>> the msys shell?
>>
>> What exactly do you mean?
>
> It's probably RXVT.  Simon needs to flush the output buffers with 
> ``_flushall();''.

Doh!  I should have thought of that!

The alternative is to do as Julien and I do -- rapidly condemn RXVT
to the trash, to get sane behaviour in a native Win32 console :-)

Regards,
Keith.

Quoting Keith MARSHALL <kei...@to...>:

> Simon wrote:

>
>> Also, when programming for windows, is there a way to output to the
>> msys shell?
>
> What exactly do you mean?

It's probably RXVT.  Simon needs to flush the output buffers with 
``_flushall();''.

Earnie Boyd

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Simon wrote:
> I recently went to the website and found MSYS and MinGW have gone
> much more difficult to install than it used to be.
>
> Thing is, I just want my windows compilation environment to look and
> feel as much like linux as possible, I'm always using "./configure;
> make; make install".  I tried following the instructions on the FAQ,

Which FAQ?  The most up to date, and currently maintained, is here:
http://www.mingw.org/MinGWiki/index.php/FAQ

There is also a no-longer-maintained one at:
http://mingw.org/mingwfaq.shtml

The latter will eventually disappear, once we are sure that all its
content has be reproduced in the MinGWiki.

> but never got as far as I did when it was just msys installer and
> mingw installer.  I was wondering what would be the simplest
> procedure to follow to get it working?  (Like "install everything"!)

Well, the MSYS installer still works, just as it always has, so I
guess your problem is with MinGW.  You can still find the old version
3.x installer, in our `Previous' package category, but that won't give
you the latest version of GCC.  The current 5.x series installer,
which can be found in the `Proposed' package category, will download
only the components you select, and install them as you run it.  This
does mean that you need an active internet connection, while you run
the installer, and it can cause problems if you are behind a proxy, or
a firewall, which blocks the individual components, as the installer
tries to download them.

If this is your problem, then you may need to download all the
components you require, before you run the installer; AFAIK, all the
components you will need are listed in the MinGWiki-FAQ.  If the
installer can find all the required components locally, then AIUI, it
should not try to download them again, so shouldn't fail on a blocked
download request.

> Also, when programming for windows, is there a way to output to the
> msys shell?

What exactly do you mean?  If you are looking for something like a
`system()' function call, which will invoke a specified command in an
MSYS shell, then yes, that is achievable; you can spawn the MSYS
shell, with the appropriate `-c command' argument list, either using
`CreateProcess()', or `_spawnl()'.  There is a gotcha -- getting the
argument quoting right can be tricky.  If your application is GPL
compatible, then I've provided the `run_system_command()' function in
http://prdownloads.sourceforge.net/mingw/mingw-execwrap-1.0.0.tar.gz?download

This is a drop-in replacement for `system()', which uses the first
available Bourne compatible shell found in your PATH, rather than
`cmd.exe', to execute the specified command; it uses a `_spawnlp()'
call, and handles argument quoting in a completely natural manner,
working around the gotchas in the Microsoft implementation.

HTH,
Keith.

Hi there,
  first time on this list >> Hello world! << and having some trouble
with my msys installation.  One source file I have doesn't compile
properly on windows (but it does on linux).  I decided I may need to
install a more recent version of msys and mingw and recompile the
whole thing from scratch.

  Now, I have to tell you I hate windows, but I am forced to compile
for it (and compile on windows too, can't just cross-compile).  I
recently went to the website and found MSYS and MinGW have gone much
more difficult to install than it used to be.

  Thing is, I just want my windows compilation environment to look and
feel as much like linux as possible, I'm always using "./configure;
make; make install".  I tried following the instructions on the FAQ,
but never got as far as I did when it was just msys installer and
mingw installer.  I was wondering what would be the simplest procedure
to follow to get it working?  (Like "install everything" !)

Also, when programming for windows, is there a way to output to the msys sh=
ell?

Thanks!
  Simon

Keith MARSHALL schrieb:
>> Marc Höper wrote, quoting me:
>>     
>>> What installation paths did you specify?  Using msys-1.0.10, you
>>> must *not* have mingw32-make in /bin.
>>>       
>> I did install mingw32-make into the default install directory. That
>> is the mingw dir, e.g. c:\program files\mingw32.
>>     
>
> No, that isn't the default installation directory.  The executable
> installers ship with preconfigured defaults:
>
>   C:\mingw        for MinGW
>   C:\msys\1.0     for MSYS and friends
>
> You may move these to a different disk device, but changing the path
> beyond this is *not* recommended.  In particular, if you move them to
> "C:\Program Files\...", you are being much too clever for your own
> good; that assinine space in the path name is going to bite you one
> day, probably sooner rather than later.
>
> (At this point, a wise man will uninstall from "C:\Program Files\..."
>  and reinstall properly).
>   

Ok. I did uninstall and reinstalled msys properly.

>> Changing the installation dir manually to
>> c:\program files\mingw32\mingw worked. Now, I have command line
>> options of mingw32-make, too.
>>
>> I also install msysDTK. Are there install contraints for this
>> package?
>>     
>
> Installing with msysDTK-1.0.1.exe, you should specify the same path
> as for MSYS itself; the default is C:\msys\1.0
>   

So msysDTK goes to the root directory of msys. What if I use the tar.gz 
files instead:
  bison-2.0-MSYS.tar.gz
  msys-autoconf-2.59.tar.bz2
  msys-automake-1.8.2.tar.gz
  msys-libtool-1.5.tar.bz2

Do I have to unpack those to / or to /mingw? Could you recommend a 
webpage where I can find those information? I read 
http://mingw.sourceforge.net/MinGWiki/index.php/GettingStarted and 
http://mingw.sourceforge.net/MinGWiki/index.php/RealDumbQuickstart.

Marc

> Marc H=F6per wrote, quoting me:
>> What installation paths did you specify?  Using msys-1.0.10, you
>> must *not* have mingw32-make in /bin.
>
> Thanks for you help. It seems to be ok now.
>
> I did install mingw32-make into the default install directory. That
> is the mingw dir, e.g. c:\program files\mingw32.

No, that isn't the default installation directory.  The executable
installers ship with preconfigured defaults:

  C:\mingw        for MinGW
  C:\msys\1.0     for MSYS and friends

You may move these to a different disk device, but changing the path
beyond this is *not* recommended.  In particular, if you move them to
"C:\Program Files\...", you are being much too clever for your own
good; that assinine space in the path name is going to bite you one
day, probably sooner rather than later.

(At this point, a wise man will uninstall from "C:\Program Files\..."
 and reinstall properly).

> Changing the installation dir manually to
> c:\program files\mingw32\mingw worked. Now, I have command line
> options of mingw32-make, too.
>
> I also install msysDTK. Are there install contraints for this
> package?

Installing with msysDTK-1.0.1.exe, you should specify the same path
as for MSYS itself; the default is C:\msys\1.0

HTH,
Keith.

Keith MARSHALL schrieb:
> Marc Höper wrote:
>   
>> I had some trouble with make and tried to figure out why. It
>> turned out that my scripts want to use mingw32-make which seems
>> to be mixed up.
>>
>> For using mingw32-make I installed MSys 1.0.10 and after that 
>> mingw32-make-3.80.0-3. For both I used the exe installers.
>> Requesting the make version outputs what I have expected. This is
>> the GNU Make which is installed with MSys.
>>
>> Calling mingw32-make --version returns nothing but an error. What
>> did I [do] wrong?
>>     
>
> What installation paths did you specify?  Using msys-1.0.10, you must
> *not* have mingw32-make in /bin.
>   

Thanks for you help. It seems to be ok now.

I did install mingw32-make into the default install directory. That is 
the mingw dir, e.g. c:\program files\mingw32. Changing the installation 
dir manually to c:\program files\mingw32\mingw worked. Now, I have 
command line options of mingw32-make, too.

I also install msysDTK. Are there install contraints for this package?

The how-tos I found described that packages have to be deflated into the 
/mingw dir but I didn't know that I also have to do this for the exe 
installers. I'm still not sure how to handle the packages named msys*, 
like msys-libtool. Do I have to install them into / or /mingw?

Marc

Marc H=F6per wrote:
> I had some trouble with make and tried to figure out why. It
> turned out that my scripts want to use mingw32-make which seems
> to be mixed up.
>
> For using mingw32-make I installed MSys 1.0.10 and after that=20
> mingw32-make-3.80.0-3. For both I used the exe installers.
> Requesting the make version outputs what I have expected. This is
> the GNU Make which is installed with MSys.
>
> Calling mingw32-make --version returns nothing but an error. What
> did I [do] wrong?

What installation paths did you specify?  Using msys-1.0.10, you must
*not* have mingw32-make in /bin.

$ which make
/bin/make.exe

$ make --version
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i686-pc-msys
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
        Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

Report bugs to <bug...@gn...>.

$ which mingw32-make
/mingw/bin/mingw32-make.exe

$ mingw32-make --version
GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

$ which gnumake
/mingw/bin/gnumake.exe

$ gnumake --version
GNU Make 3.81beta4
Copyright (C) 2003  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i686-pc-mingw32

(The latter is the latest beta from
 ftp://alpha.gnu.org/gnu/make/make-3.81beta4.tar.bz2
 built from source, using MinGW under msys-1.0.10, configured with:
   --prefix=3D`cd /mingw; pwd -W`
   --program-prefix=3Dgnu
   --enable-largefile
   --enable-case-insensitive-file-system
   --disable-job-server
   --disable-rpath
   --disable-nls
)

Regards,
Keith.

Hi,

I had some trouble with make and tried to figure out why. It turned out 
that my scripts want to use mingw32-make which seems to be mixed up.

For using mingw32-make I installed MSys 1.0.10 and after that 
mingw32-make-3.80.0-3. For both I used the exe installers. Requesting 
the make version outputs what I have expected. This is the GNU Make 
which is installed with MSys.

Calling mingw32-make --version returns nothing but an error. What did I 
wrong?

-----------------

$ make --version
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i686-pc-msys
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
        Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

Report bugs to <bug...@gn...>.

-----------------

$ mingw32-make --version
d:\local\mingw10\bin\mingw32-make.exe: *** No targets specified and no 
makefile found.  Stop.

-----------------

Thanks for your help,

Marc

--- Keith MARSHALL <kei...@to...>写道:

> Haibin Zhang wrote, quoting me:
> >> As Earnie and I have both pointed out, it's your
> monolithic
> >> packaging format that we object to, not what you
> provide in
> >> your package.  Any user who needs those latest
> versions of
> >> the autotools, or gettext, will be well capable
> of updating
> >> their own installations, using our mingwPORTs.
> >
> > This is a temporary schema, If I have time, I will
> package it
> > as cygwin install.exe. so that many people can
> upgrade mingw
> > as cygwin.
> 
> I hope you mean "like cygwin", rather than "as
> cygwin"; I don't
> think the Cygwin folks will be too enamoured of you
> trying to
> replace a Cygwin install with a MinGW rip-off.  Nor
> will we be
> best pleased, if upgrading a MinGW installation
> turns it into
> Cygwin.  (That aside, there is already significant
> co-operation
> between the Cygwin and MinGW projects).
> 
> >> If you *really* want to assist those users who
> you say need
> >> your package, then why not offer them an even
> better service,
> >> by helping us to keep the appropriate mingwPORTs
> up to date,
> >> instead of creating yet another software
> distribution?
> >
> > I think that if you spend much time to update
> mingwPORTS, maybe
> > you can create a intall.exe like cygwin.  Sorry,
> maybe I am wrong,
> > maybe I don't understand mingwPORTS.
> 
> We like the mingwPORT concept, because it allows
> users to select
> those packages they want/need, download the PORT
> file, and run
> `mingwPORT.sh' to handle the details of downloading,
> building
> and installing the required package, while also
> optimising it to
> best fit their own system configuration.
> 
> In many respects, each mingwPORT is like a mini
> installer, with
> each one dedicated to its own optional add-on
> package for a MinGW
> or MSYS system.  Certainly, there isn't currently
> any single
> integrated installer, which can handle both a basic
> MinGW
> installation, and also manage the optional add-ons. 
> It would be
> nice to offer one, but that needs development
> effort, which in
> turn needs time, and that is a scarce commodity. 
> That would
> appear to be your goal, but isn't your effort
> misdirected?
> Instead of impatiently going it alone, wouldn't you
> be better
> working *with* us, to achieve that goal?  Together
> we could
> achieve so much more than we can each produce
> independently.
> I have no issue with letting you join the MinGW
> Developer Team,
> and allowing you to participate in development
> discussions.
> We already have a couple of developers, with an
> interest in
> installers; why not share your ideas with them?  But
> please,
> show some patience; you must give us an opportunity
> to review
> your work, *before* we adopt it into MinGW, or give
> you carte
> blanche to upload to our project pages.

Thank you Keith, If I have some idea of mingw, I will
first share with mingw group !

regards

Zhang haibin


> Regards,
> Keith.
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do
> you grep through log files
> for problems?  Stop!  Download the new AJAX search
> engine that makes
> searching your log files as easy as surfing the 
> web.  DOWNLOAD SPLUNK!
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
>
https://lists.sourceforge.net/lists/listinfo/mingw-msys
> 



	

	
		
___________________________________________________________ 
雅虎1G免费邮箱百分百防垃圾信 
http://cn.mail.yahoo.com/