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

Announcing the initial release of Road-bash and Road Intranet.

Road-bash is a portable bash command shell for Unix, Windows, and Mac OS. It contains scripts for initializing the Bash shell, logging, and error handling. For standalone operation under Windows, Road-bash redistributes MSYS and selections from GnuWin32, Outwit, and UnxUtils. 
        http://www.qhull.org/bash/doc/road-bash.html

Road Intranet is a collection of FAQs and links for software development infrastructure. It emphasizes Windows-based development in a mixed Windows and Unix environment. Hopefully, you will find some useful material here. 
        http://www.qhull.org/road

Please send comments and suggestions to br...@sh... 

                                        --Brad

On Monday 20 August 2007 19:53, Tug Russel wrote:
> I have been using MSYS a lot recently and a lot of packages are out
> of date. Can some of the devs please upgrade the packages because
> some of the old ones like coreutils and cvs are really needed. Thank
> you for the help

Have you looked in the `Snapshot' section, where Cesar is assembling the=20
release candidate for MSYS-1.0.11?

It's a question of someone having both time, and incentive.  Unless you=20
want them badly enough, and can put in the effort to supply appropriate=20
patches, then please don't expect this to magically just happen.

> PS: I found out the latest versions of the packages and pointed out
> the sources

Let's see:

> autoconf =A02.59 =A0 =A0 2.61a=20
> ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.61a.tar.gz

AFAIK, the canonical FSF source builds and installs OOTB in MSYS; (2.61=20
certainly does -- I'm using it myself).  I've no plans to issue any=20
further MSYS specific releases of autoconf; grab the canonical source,=20
and install it.

> automake =A01.8.2 =A0 =A01.10
> ftp://ftp.gnu.org/gnu/automake/automake-1.10.tar.gz

I don't use automake myself, but I believe this is in the same category=20
as autoconf, WRT supporting it in MSYS.

> bash =A0 =A0 =A03.1 =A0 =A0 =A03.2-017
> ftp://ftp.gnu.org/gnu/bash/bash-3.2.tar.gz +
> ftp://ftp.gnu.org/gnu/bash/bash-3.2-patches

Cesar's snapshot is already 3.1.  If someone supplies patches for 3.2,=20
he may consider them for MSYS-1.0.11; it's his call.

> binutils =A02.11 =A0 =A0 2.17
> ftp://ftp.gnu.org/gnu/binutils/binutils-2.17.tar.gz

Don't know where you're looking, but our *current* binutils is 2.17.50;
furthermore, the FSF sources may not incorporate our patches.

> bison =A0 =A0 2.3 =A0 =A0 =A02.3a =A0 =A0 =A0
> ftp://alpha.gnu.org/gnu/bison/bison-2.3a.tar.gz

This is *alpha* status, and therefore may not be stable.  Unless it=20
fixes a *major* defect in 2.3, I don't think we should consider it yet.

> bizp2 =A0 1.0.1 =A0  =A01.0.4
> http://www.bzip.org/1.0.4/bzip2-1.0.4.tar.gz

Well, Cesar's latest snapshot is 1.0.3.  He may consider patches for=20
1.0.4, if you'd care to submit them please!

> coreutils 5.7 =A0 =A0 6.9
> ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.9.tar.gz

Cesar may already have done some work on this; it's his call.

> cvs =A0 =A0 =A0 1.11.22 =A01.12.13.1
> ftp://ftp.gnu.org/non-gnu/cvs/source/nightly-snapshots/feature/cvs-1.
>12.13.1.tar.gz

We are *not* going to maintain MSYS on the basis of nightly snapshots=20
from other projects; feel free to experiment with them for yourself.

> findutils 4.3.0 =A0 =A04.3.8=20
> ftp://alpha.gnu.org/gnu/findutils/findutils-4.3.8.tar.gz

Again, it's *alpha*; let them stabilise it.

> gzip =A0 =A0 =A01.2.4 =A0 =A01.3.11 =A0 =A0
> ftp://alpha.gnu.org/gnu/gzip/gzip-1.3.11.tar.gz

Likewise.

> m4 =A0 =A0 =A0 =A01.4.0 =A0 =A01.4.10 =A0 =A0=20
ftp://ftp.gnu.org/gnu/m4/m4-1.4.10.tar.gz

Once more, you have overlooked 1.4.7, which is our current release, (and=20
which is needed for autoconf-2.61).  If you can successfully build=20
m4-1.4.10, please submit patches.

> perl =A0 =A0 =A05.6.1  =A0 =A05.9.5
> http://www.perl.com/CPAN/src/perl-5.9.5.tar.gz

I tried this a while back.  It's a nightmare.  I gave up.  If anyone=20
wants to devote the time and energy, again, please submit patches.

> tar =A0 =A0   1.13.19 =A01.18 =A0 =A0 =A0=20
ftp://ftp.gnu.org/gnu/tar/tar-1.18.tar.gz

Once again, it's Cesar's call; I'm sure he'll consider patches.

Regards,
Keith.

Hi,
I have been using MSYS a lot recently and a lot of packages are out of
date. Can some of the devs please upgrade the packages because some of
the old ones like coreutils and cvs are really needed. Thank you for
the help

PS: I found out the latest versions of the packages and pointed out the sources
autoconf  2.59     2.61a
ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.61a.tar.gz
automake  1.8.2    1.10
ftp://ftp.gnu.org/gnu/automake/automake-1.10.tar.gz
bash      3.1      3.2-017
ftp://ftp.gnu.org/gnu/bash/bash-3.2.tar.gz +
ftp://ftp.gnu.org/gnu/bash/bash-3.2-patches
binutils  2.11     2.17
ftp://ftp.gnu.org/gnu/binutils/binutils-2.17.tar.gz
bison     2.3      2.3a       ftp://alpha.gnu.org/gnu/bison/bison-2.3a.tar.gz
bizp2     1.0.1    1.0.4      http://www.bzip.org/1.0.4/bzip2-1.0.4.tar.gz
coreutils 5.7      6.9
ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.9.tar.gz
cvs       1.11.22  1.12.13.1
ftp://ftp.gnu.org/non-gnu/cvs/source/nightly-snapshots/feature/cvs-1.12.13.1.tar.gz
findutils 4.3.0    4.3.8
ftp://alpha.gnu.org/gnu/findutils/findutils-4.3.8.tar.gz
gzip      1.2.4    1.3.11     ftp://alpha.gnu.org/gnu/gzip/gzip-1.3.11.tar.gz
m4        1.4.0    1.4.10     ftp://ftp.gnu.org/gnu/m4/m4-1.4.10.tar.gz
perl      5.6.1    5.9.5      http://www.perl.com/CPAN/src/perl-5.9.5.tar.gz
tar       1.13.19  1.18       ftp://ftp.gnu.org/gnu/tar/tar-1.18.tar.gz

On 2007-08-17 23:29Z, Daniel C. Bastos wrote:
> On 8/17/07, Keith Marshall <kei...@us...> wrote:
>> On Friday 17 August 2007 19:37, Ulf Nyman wrote:
>>> I have found that the make (GNU Make version 3.79.1, have try other
>>> version) is very slow in the start of building a source.
>> Yes.  Woe32 *is* slow.  Ask Bill to explain why he can't deliver
>> performance which comes even close to that of GNU/Linux.
> 
> If he e-mails you an explanation, can you forward it to us? My main
> interest here, though, is to find out what Woe32 means.

It means ms windows; ms's founder is unlikely to write to Keith.

Some processes that run in the background make it slower than it
needs to be. Years ago I measured the effect of killing various
unneeded processes, and found that the msw "indexing service"
made C++ builds run half as fast as they would without it, on
a typical computer in my office. Malware-detection software
impairs speed significantly, too.

Hi Keith,

On 18/08/07, Keith Marshall wrote:
> On Friday 17 August 2007 19:37, Ulf Nyman wrote:
> > I have found that the make (GNU Make version 3.79.1, have try other
> > version) is very slow in the start of building a source.
>
> Yes.  Woe32 *is* slow.

Naturally, the speed comparison will never be the same as GNU/Linux,
since one is native, and one is built on top of the Windows
environment.

> > It can take up to 20 sec to start the buildings!
>
> I suspect that it's actually slow file system performance that's the
> culprit.

I had experienced this problem, and found a simple solution, although,
it will not probably help Ulf. The firewall was running anti-spyware
scans through each file created or accessed, slowing everything down.

Hugh

On 8/17/07, Keith Marshall <kei...@us...> wrote:
> On Friday 17 August 2007 19:37, Ulf Nyman wrote:
> > I have found that the make (GNU Make version 3.79.1, have try other
> > version) is very slow in the start of building a source.
>
> Yes.  Woe32 *is* slow.  Ask Bill to explain why he can't deliver
> performance which comes even close to that of GNU/Linux.

If he e-mails you an explanation, can you forward it to us? My main
interest here, though, is to find out what Woe32 means. I tried google
with

define:Woe32
definition Woe32
glossary Woe32
wikipedia Woe32

and also search for ``Woe32'' on wikipedia's website and I found nothing
relevant. What does it mean?

> > It can take up to 20 sec to start the buildings!
>
> I suspect that it's actually slow file system performance that's the
> culprit.  As a crude benchmark, several months ago I ran a timed
> sequence of 100 pdfroff cycles, (a shell script running a groff through
> GhostScript pipeline), to format and emit a 12 page PDF document;
> IIRC, this took the following times for the 100 cycles:
>
>   ~1.5 mins, on 650MHz AMD-Duron, with 80GB ATA-66 HD, SUSE-10.0
>   ~35 mins, on 1.7GHz Pentium-4, with similar HD, MSYS-Win2K
>   ~1 hr, on same Pentium-4 box, but with Cygwin instead of MSYS.

Using the GNU emacs and msys, in particular, I also notice a very slow
file operation sometimes. For instance, when I open a new file ---
e-mails, for example, which I usually write from a webmail and I use
firefox to call the GNU emacs --- and I write a paragraph, then I save
it (C-x C-s), it sometimes takes various seconds of reading my hard
drive until it really saves it. If I then write a new string and save it
right afterwards, it saves it very quickly.

Also, msys loads, but it takes quite a few seconds sometimes for the
shell prompt to appear, and usually my hard drive is being
read. Sometimes everything is working very well, and I do a simple
``ls'' and there it goes another few seconds of hard drive screaming;
but following the sequence with another ``ls'' is quick.

I don't know what it is, but I know it's annoying.

On Friday 17 August 2007 19:37, Ulf Nyman wrote:
> I have found that the make (GNU Make version 3.79.1, have try other
> version) is very slow in the start of building a source.

Yes.  Woe32 *is* slow.  Ask Bill to explain why he can't deliver 
performance which comes even close to that of GNU/Linux.

> It can take up to 20 sec to start the buildings!

I suspect that it's actually slow file system performance that's the 
culprit.  As a crude benchmark, several months ago I ran a timed 
sequence of 100 pdfroff cycles, (a shell script running a groff through 
GhostScript pipeline), to format and emit a 12 page PDF document;  
IIRC, this took the following times for the 100 cycles:

  ~1.5 mins, on 650MHz AMD-Duron, with 80GB ATA-66 HD, SUSE-10.0
  ~35 mins, on 1.7GHz Pentium-4, with similar HD, MSYS-Win2K
  ~1 hr, on same Pentium-4 box, but with Cygwin instead of MSYS.

> With thes result I think the problem is start of the make itself in
> MinGW/MSYS.

I think the problem is in the Woe32 file system itself; specifically in 
the time it takes initially, to read the Makefile, or script.

> Have some one else found simiar problems?

Yes, but I don't think there's much we can do about it; we just have to 
live with it.

> Some tip to solve this (spped up the make)

If you want the speed of GNU/Linux, then use GNU/Linux.  If you need to
develop for Woe32, then either live with the performance penalty, or do 
as I do, and use a cross-compiler hosted on GNU/Linux.

Regards,
Keith.

Hello!

I have found that the make (GNU Make version 3.79.1, have try other version)
is very slow in the start of building a source.

It can take up to 20 sec to start the buildings!
(normally on my computer 8sec, outer in the project have longer start time!)
We run all same VMWare image of Windows XP

Same code in a Linux enviorement (same GNU make version) start building
directly!

Have try to localize the time out, and found that must be the start of
make itself.
(Have made a sh script that print a time stamp and then start the make)
====
#!/bin/sh
# Scriptname:  run_make

echo 'Start Time:"'  `date` '"' ;
make all $1
====

In the Makefile (first row) have I add following
TIME1 = $(shell echo 'Time1="' `date` '"')

The all target call the start target and more like
all:  start lib ... etc
in the start target I have
start:
	@echo "Time == $(TIME1)" ;
	@echo 'Time2="' `date` '"' ;

When i run the run_make script I get following result in MinGW/MSYS
===
./run_make
Start Time:" Fri Aug 17 14:39:52 WEST 2007 "
Time == Time1= Fri Aug 17 14:39:59 WEST 2007
Time2=" Fri Aug 17 14:39:59 WEST 2007 "
===
In Linux
===
./run_make
Start Time:" Fri Aug 17 14:41:59 WEST 2007 "
Time == Time1= Fri Aug 17 14:41:59 WEST 2007
Time2=" Fri Aug 17 14:41:59 WEST 2007 "
===

With thes result I think the problem is start of the make itself in
MinGW/MSYS.

Have some one else found simiar problems?

Some tip to solve this (spped up the make)

Best regards

tew

I'm trying to build GetText 0.16.1

This is what I have done so far, using this page as guideline =
http://www.venge.net/mtn-wiki/BuildingOnWindows

MinGW - install, accept defaults but add g++ on the package selection page
MSYS - install, accept defaults
msysDTK - install into MSYS directory
unpack GetText to /usr/src/gettext-0.16.1 and patch it for localename

cd /usr/src/gettext-0.16.1
=2E/configure --prefix=3D/mingw
make install

gcc -shared  .libs/message.o .libs/po-error.o .libs/po-xerror.o =
=2Elibs/read-catal                                                         =
                    og-abstract.o .libs/po-lex.o .libs/po-gram-gen.o =
=2Elibs/po-charset.o .libs/read-p                                          =
                                   o.o .libs/read-properties.o =
=2Elibs/read-stringtable.o .libs/open-catalog.o .libs/                     =
                                                        dir-list.o =
=2Elibs/str-list.o .libs/read-catalog.o .libs/write-catalog.o .libs/wri    =
                                                                         =
te-properties.o .libs/write-stringtable.o .libs/write-po.o =
=2Elibs/msgl-ascii.o .l                                                    =
                         ibs/msgl-iconv.o .libs/msgl-equal.o =
=2Elibs/msgl-cat.o .libs/msgl-english.o .libs/                             =
                                                msgl-check.o =
=2Elibs/file-list.o .libs/msgl-charset.o .libs/po-time.o .libs/plural      =
                                                                       =
-exp.o .libs/plural-eval.o .libs/plural-table.o .libs/c++format.o =
=2Elibs/format-c                                                           =
                  .o .libs/format-sh.o .libs/format-python.o =
=2Elibs/format-lisp.o .libs/format-elis                                    =
                                         p.o .libs/format-librep.o =
=2Elibs/format-scheme.o .libs/format-java.o .libs/format                   =
                                                          -csharp.o =
=2Elibs/format-awk.o .libs/format-pascal.o .libs/format-ycp.o .libs/form   =
                                                                          =
at-tcl.o .libs/format-perl.o .libs/format-perl-brace.o .libs/format-php.o =
=2Elibs/                                                                   =
          format-gcc-internal.o .libs/format-qt.o .libs/format-boost.o =
=2Elibs/gettextsrc-ex                                                      =
                       ports.o  =
-L/usr/src/gettext-0.16.1/gettext-tools/intl/.libs ../gnulib-lib/.libs/    =
                                                                         =
libgettextlib.dll.a ../intl/.libs/libintl.dll.a  -Wl,--export-all-symbols =
-Wl,--                                                                     =
        disable-auto-import -o .libs/libgettextsrc-0-16-1.dll =
-Wl,--enable-auto-image-ba                                                 =
                            se -Xlinker --out-implib -Xlinker =
=2Elibs/libgettextsrc.dll.a
gcc.exe: .libs/c++format.o: No such file or directory
make=5B3=5D: *** =5Blibgettextsrc.la=5D Error 1
make=5B3=5D: Leaving directory =60/usr/src/gettext-0.16.1/gettext-tools/src'
make=5B2=5D: *** =5Binstall=5D Error 2
make=5B2=5D: Leaving directory =60/usr/src/gettext-0.16.1/gettext-tools/src'
make=5B1=5D: *** =5Binstall-recursive=5D Error 1
make=5B1=5D: Leaving directory =60/usr/src/gettext-0.16.1/gettext-tools'
make: *** =5Binstall-recursive=5D Error 1

gcc seems to be correct, the file doesn't exists.

Any help? Thanks

I'm using MinGW + MSys.
If I do printf( "\033[32mtext" ) in my program it just outputs garbage.
But if I pipe it into cat from msys:
myprog.exe | cat
then the actual color output is produced.
How do I make printf behave the same way in my program?
-- 
- Dmitry

I'm trying to install the PortAudio API ( www.portaudio.com www.portaudio.com
) with MSYS, but after I enter "make" I get the following error multiple
times w/ different "Pa" files:

:C:/msys/1.0/portaudio/src/hostapi/wmme/pa_win_wmme.c:2218: undefined
reference to `PaWin_DefaultChannelMask'

And then the output ends with this:

collect2: ld returned 1 exit status

I extracted the portaudio file from PA_snapshot_v19.tar (
http://www.portaudio.com/archives/pa_snapshot_v19.tar.gz here ) and ran all
the commands from within that file. Anyone know what's up? Thanks.
-- 
View this message in context: http://www.nabble.com/Trouble-using-.-configure%2C-make%2C-make-install-w-PortAudio-API-tf4261680.html#a12127657
Sent from the MinGW - MSYS mailing list archive at Nabble.com.

On 2007-08-03 15:11Z, Antonio García wrote:
> 
> Oh and -ggdb doesn't work,
> but -g does: I assume I just picked the wrong binary format (probably
> the Mingw32 GDB uses DWARF or something of the sort).

This depends on the specific version of gcc. My notes say:

# MinGW gcc-3.4.2 writes dwarf2 debug records if '-ggdb' is specified,
# but the version of gdb packaged with it expects stabs format.

and, IIRC, stabs was the default for MinGW gcc versions
before and after gcc-3.4.2 (unless you downloaded a special
dwarf2 version, or built one yourself).

You had said you're using "GNU gdb 5.2.1". That's pretty
old. There have been discussions of different 6.x versions
here in the past week or two, and I'd guess that this one
  http://downloads.sourceforge.net/mingw/gdb-6.6.tar.bz2
might be the most robust.

Hello Greg,

Why, thank you for the speedy response. I'm so silly! I forgot -mwindows was
for GUI apps.

I was just now testing the effect of the different flags with a dummy hello
world program. Indeed, it's as you say. Oh and -ggdb doesn't work, but -g
does: I assume I just picked the wrong binary format (probably the Mingw32
GDB uses DWARF or something of the sort).

Whew, I was worried. Sorry for bothering you guys.

Thanks a lot,
Antonio

On 2007-08-03 14:48Z, Antonio García wrote:
> 
> I'm getting a really weird problem with I/O under MSYS. I've got a C++
> program compiled with -mwindows, which among other things, asks for a
                        ^^^^^^^^^
> password.
> 
> After much mucking, I got a snippet of code that did what I wanted from
> the cURL project, but the getch() function doesn't quite work
                            ^^^^^^^

Are you trying to do console I/O in a GUI app?

Hello all,

I'm getting a really weird problem with I/O under MSYS. I've got a C++
program compiled with -mwindows, which among other things, asks for a
password.

After much mucking, I got a snippet of code that did what I wanted from the
cURL project, but the getch() function doesn't quite work: it just keeps
gobbling characters from God knows where, instead of asking me. I thought
that it might be the doing of MSYS' shell, so I tried running my program
under the ol' MS-DOS shell, but then there's no output at all! I tried
fflush()ing stdin and stdout before doing getch, but it doesn't do anything.

What might I be doing wrong? Oh, and by the way, if I use -ggdb when
compiling and then try running the program, it barfs on me.

The command I use for linking is:

g++ -o scenario-client src/FileDownloader.o src/client.o
src/ConsoleSecretsAgent.o src/SecretsAgent.o lib/getpass.o -lssl -lcrypto
-L/mingw/lib -lneon -lssl -lcrypto -lws2_32 -lws2_32 -lz -L/mingw/lib -lxml2
-lz -liconv -lws2_32 -mwindows

For compiling, I use stuff like:

g++ -Wall -I/mingw/include/neon -Isrc -Ilib -ggdb -DNDEBUG -c -o
src/SecretsAgent.o src/SecretsAgent.cpp

And then GDB says this:

$ gdb ./scenario-client.exe
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
An internal GDB error was detected.  This may make further
debugging unreliable.  Quit this debugging session? (y or n) n

Create a core file containing the current state of GDB? (y or n) n

(gdb) c:/cygmnt/prj/pkg/src/gdb/mingw32/gdb/dwarf2read.c:985:
gdb-internal-error: read_comp_unit_head: dwarf from non elf file

I'm a bit weirded out by all this. Might it be the fault of one of the
libraries? I compiled them all myself under mingw, so I don't think it's a
problem of binary compatibility.

Thanks,
Antonio