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

On 24/12/2007, Terrence Brannon wrote:

> How can I create a symlink to the "My Documents" directory in my MSYS home directory?

Dunno. But if symlink'ing doesn't work, you could simply mount it with
a entry in /etc/fstab.

-- 
Jan Bruun Andersen

Terrence Brannon wrote:

> How can I create a symlink to the "My Documents" directory in my MSYS home
> directory?

MSYS does not use or support symlinks.  ln -s makes copies of files.

MSYS' whole reason for existance is to support the build systems for
plain Win32 apps (like MinGW gcc), and these native apps don't know
anything about symlinks because symlinks don't exist on native Windows. 
Therefore having a 'ln -s' that made fake symlinks (like Cygwin's 'ln
-s' does) would not be useful as programs like MinGW gcc would not be
able to understand them.  Cygwin can get away with this because all
Cygwin tools are linked to the Cygwin runtime.

Brian

How can I create a symlink to the "My Documents" directory in my MSYS home 
directory?

Administrator@LIFEBOOK ~
$ ln -s /c/Documents\ and\ Settings/Administrator/My\ Documents/ ~/mydocs
ln: creating symbolic link `/home/Administrator/mydocs' to `/c/Documents and 
Settings/Administrator/My Documents': No such file or directory

Administrator@LIFEBOOK ~

How would you alter your Emacs init file to check if you are running win32 
emacs and if so to set the default shell program to msys?

Hi,

I am user of msys and mingw software since several years back. I have
always wondered, but never asked, why are msys developers trying to
mirror so many gnu packages
when they already are available either as already windows compilable or
as parts of other ports. For ex. what is need for distributing special
version of msys make utility
when original gnu make already has support for win32 compiling, and
there is also port in gnuwin32 project? Or for example bzip2 or
binutils, or flex, or ... etc? Isn't it 
just duplicating work? This is not ment as a critique, I am just curious
and never really understood why is there need for such duplicating work?

I am also curious, isn't it possible to make windows distro of gcc
binary compatible with M$ compiler, so that one can use their own
platform sdk with gcc, rather then 
needing to maintain mingw win32-api library. I understand that gcc has
different name-mangling scheme and that m$ uses some language extensions
not defined by ansi or gnu,
but as I understand gcc already can parse a lot of those extensions. Def
files used by gcc also differs from .def files used by m$ compiler. Are
there some really big 
technical obstacles to make gcc compatible with m$? It would be very
nice to skip writing IF-Defs and thinking of what are differences and
incompatiblities, and it would
be even more nicer to be able to compile code written for m$ compiler
straightforward ... Plz, understand that I am not "bashing" or anyhow
dissing mingw, I am used mingw for
years, and think it is a great piece of software. I would just like to
see it better and a bit easier to use. 

I would also like to help with those things I am talking about, but I am
affraid that I don't know how to contribute or even where to start
digging if I would like to 
help in development. Gcc code is a loooot of code, and it would be nice
to see some tutorial or "get started" page where someone helps one to
compile tarball and start experimenting
with the code.

-- 
http://www.fastmail.fm - The professional email service

Hey,

I've installed MSYS DTK (perl version 5.6.1)

I want to install the Digest::MD5 perl module, but I get these errors:

Testing alignment requirements for U32... In file included from 
u32align.c:10:
D:/msys/1.0/lib/perl5/5.6.1/msys/CORE/perl.h:649:27: netinet/in.h: No such 
file or directory
D:/msys/1.0/lib/perl5/5.6.1/msys/CORE/perl.h:653:26: arpa/inet.h: No such 
file or directory
D:/msys/1.0/lib/perl5/5.6.1/msys/CORE/perl.h:699:27: sys/times.h: No such 
file or directory
D:/msys/1.0/lib/perl5/5.6.1/msys/CORE/perl.h:713:25: sys/socket.h: No such 
file or directory
D:/msys/1.0/lib/perl5/5.6.1/msys/CORE/perl.h:740:21: netdb.h: No such file 
or directory
D:/msys/1.0/lib/perl5/5.6.1/msys/CORE/perl.h:807:24: sys/ioctl.h: No such 
file or directory
D:/msys/1.0/lib/perl5/5.6.1/msys/CORE/perl.h:1182:23: ieeefp.h: No such 
file or directory
D:/msys/1.0/lib/perl5/5.6.1/msys/CORE/perl.h:1757:21: win32.h: No such 
file or directory

is it normal that, for perl installed from MSYS, I have those errors ? It 
seems that those errors come from config.h, which sets some macro

thank you

Vincent Torri

On 2007-12-13 14:41Z, Zaphod Beeblebrox wrote:
[...]
>  For building the same app under Windows (XP with SP2), I installed two shell environments: MSYS 
> with MinGW and Cygwin. The compilation process occurs successfully under both shells with a pretty
> similar command line (with increased stacksize add-on linker option),

Did linking fail if you didn't increase the stack size?

If you have a very large dataset, can you test with a smaller one?

> but running the resulting exe
> succeeds only in the Cygwin shell, while in the MSYS shell, the execution crashes at some point in
> the middle. After placing intermediate outputs, it turned out that crashing occurs when a <vector>
> push_back() is called. 
>  Moreover, running the two executables in the DOS shell (which is the targeted modality to run the
> app) produces the same delusional result (that is: both executables crash under DOS at the same 
> execution point). There is no additional error message, the application just exits.

Wrap main()'s code inside a try-catch block if you haven't done so
already. Without that, it may call abort() due to an untrapped
exception.

Try running it under gdb.

My first guess would be that it's terminating due to an uncaught
bad_alloc exception. It you can rule that out, then my second
guess would be a defect in the program; try running it after
rebuilding with the libstdc++ debug macros (search this list's
archives for '_GLIBCXX_DEBUG' to find a complete list).

Hello all,

 I made several searches in the archives but I failed to find an appropriate answer to my problem.
 I apologize in advance if the issue has been already discussed and clarified on this list.

 My problem is the porting on Windows of some applications written in C++ which run fairly well
under linux.
 
 The current application I'm coping with has a standard compile line under linux:

 g++ -o3 -lm MyFile1.cpp MyFile2.cpp ... MyFileN.cpp -o app appMain.cpp

 For building the same app under Windows (XP with SP2), I installed two shell environments: MSYS 
with MinGW and Cygwin. The compilation process occurs successfully under both shells with a pretty
similar command line (with increased stacksize add-on linker option), but running the resulting exe
succeeds only in the Cygwin shell, while in the MSYS shell, the execution crashes at some point in
the middle. After placing intermediate outputs, it turned out that crashing occurs when a <vector>
push_back() is called. 
 Moreover, running the two executables in the DOS shell (which is the targeted modality to run the
app) produces the same delusional result (that is: both executables crash under DOS at the same 
execution point). There is no additional error message, the application just exits.
 On another hand, a sample code calling the push_back() method in a standalone application runs
well if compiled under Cygwin or MSYS, if called in the unix-like shell or the DOS command shell.
 
 I suppose the problem should be still related with runtime access to required libraries, but I'm
not familiar with Windows specific issues. I would like to have some suggestions about how to act:
if there is something I have to add in the compilation line, in the Windows PATH variable, or 
elsewhere; if it would be better to copy some file(s) in executable's directory, or anything else.

 Thank you for your time.

 Regards,
             Z.B.

On Saturday 08 December 2007 14:11, Johannes Schindelin wrote:
> > If you think that running MSYS in a native Woe32 console means
> > running cmd.exe or command.com, then perhaps you should question
> > your own understanding of the issues, before branding others as
> > incompetent.
>
> The native console on Windows XP is cmd.exe.

No, it *isn't*!  This discussion has come up before, not so many weeks=20
ago.  cmd.exe is a *shell*; the console is a container, in which to run=20
a shell; it provides the infrastructure to manage the interface between=20
the user and the shell.  cmd.exe is by no means the only shell which=20
can be run in a native Woe32 console; sh.exe, from MSYS, is just as=20
much at home there.

> > > Think resizing the window (not that hard, everybody else seems to
> > > do it just fine).
> >
> > Yes, this is about the *only* real limitation of the native
> > console. Console2 is able to do this, while still maintaining
> > proper interaction with the stdio streams; that's why I suggested
> > that their *technique* may be worth exploring.
>
> I tried Console2 twice. =A0The first time I did, it had massive
> problems rendering the text properly. =A0But my second try did not
> confirm that, and I did not have time to reproduce the exact setup of
> the first try to find out what was changed.
>
> > > Think copy/pasting (you have to enable it manually!
> >
> > One time *only*, then you can forget about it.
>
> One time per box/reinstall.

Sure.  I only use one Woe32 box at a time; (couldn't tolerate more), and=20
I've never done a reinstall, (and if I did, it wouldn't be Woe??).

> Oh, and per user who downloads MSys.

And each user will have their own preferences anyway.  I don't consider=20
five minutes in the 2-year life cycle of my Woe32 boxes to be too high=20
a price to pay, to configure the console to my liking.

>=A0And on some setups (don't pretend you have not see them) per reboot,
> because the admins reset the registry on boot.

I've *never* seen any such thing, and our admins impose some asininely=20
draconian restrictions on their users.

> > > you have to _right_ click to finish the selection!
> >
> > So what? =A0Sure, it's a little bit different, but you can quickly
> > get used to it. =A0I don't see this as a particular problem.
>
> So we disagree.

And must, apparently, agree to do so.

> > > You can forget about multi-line selections if the first line of
> > > what you want to select does not start in the first column).
> >
> > Yes. =A0This can be a bit fiddly, but achievable nonetheless.
>
> Yes.
>
> And you can move to a new house by bike. =A0It is just very
> inconvenient.

Hardly a particularly useful analogy, I think.

> > > Think scrolling back with a keyboard shortcut.
> >
> > This is a limitation; I've learned to live with it. =A0Console2 can
> > do it, just like in the KDE konsole on my Linux box, so no reason
> > an MSYS work alike couldn't be developed.
>
> I can live with it, too. =A0However, I like to live a _happy_ life.
>
> > If you are suggesting Earnie is incompetent, [...]
>
> I came nowhere near that. =A0Neither will I, ever.
>
> > We live on their OS platform [Windows], so we just have to do the
> > best we can with what they provide.
>
> No, I live on planet earth.

As do I.  I meant that we, as a project providing MSYS, live on Woe32;=20
if we weren't saddled with Woe32, we would have no need for MSYS.

> When I have to work on Windows, I try to=20
> solve the issues beforehand, rather than live with limitations.

I don't have the energy for writing lots of Woe32 specific code.  I need=20
gvim, and a shell to run pdfroff; MSYS sh.exe in the native console is=20
fine for my needs, and its limitations don't bother me at all.

> That is the reason we rewrote spawnvpe() in msysGit, since the native
> version of that function is too limiting.

The entire family of spawn and exec functions is utterly broken; that's=20
why we (MinGW) provide the execwrap library, which I originally wrote=20
as part of the Woe32 port of groff, (GNU troff), for the FSF.

> Actually, we have quite a=20
> lot of examples where we do not just take what they provide, since it
> is not good enough.

Sure.  We also have added quite a bit of extra functionality ourselves. =20
However, most of us can live with the console limitations; it isn't a=20
burning priority for us to provide a replacement, but if anyone wants=20
to develop and contribute one, we'll be happy to consider it.

Regards,
Keith.

Hi,

On Sat, 8 Dec 2007, Keith Marshall wrote:

> On Saturday 08 December 2007 11:35, Johannes Schindelin wrote:
> > To propose Console2, admitting that it does not run on older Windows 
> > (which are way preferable to me, since I have lots of licenses for 
> > them that work, thanks to Microsoft's insistence on selling Windows 
> > with every computer, and they run way faster in 
> > virtualisers/emulators) is what qualifies as "half-assed" with this 
> > coder.
> 
> If you'd taken the trouble to read my suggestion *properly*, you'd 
> realise that I *wasn't* suggesting adoption of Console2, for this reason 
> amongst others.  What I did suggest was adopting their method for 
> interaction with the stdio streams, but in a truly open GUI framework, 
> which *could* support those older Woe32 versions.

Okay, sorry, I did not take the trouble to read your suggestion properly.

> > > There are two officially supported methods of running the MSYS 
> > > shell:--
> > >
> > > 1) In a native Woe32 console. ?This is the only one of the two which 
> > > is truly robust; it has always been available, and is the default 
> > > choice for Cygwin, but not for MSYS. ?In a recent poll, on this 
> > > list, those who bothered to respond were unanimous that it should 
> > > also become the default for MSYS.
> >
> > I wasn't there; I would have opposed.
> >
> > Even if we have to use cmd/command.exe with msysGit, since for example 
> > ssh password input or paging with "less" does not work properly in 
> > rxvt, the shortcomings of cmd/command are so annoying that I curse out 
> > loud in the general direction of Redmond almost every time I have to 
> > use it.
> 
> If you think that running MSYS in a native Woe32 console means running 
> cmd.exe or command.com, then perhaps you should question your own 
> understanding of the issues, before branding others as incompetent.

The native console on Windows XP is cmd.exe.

> > Think resizing the window (not that hard, everybody else seems to do 
> > it just fine).
> 
> Yes, this is about the *only* real limitation of the native console. 
> Console2 is able to do this, while still maintaining proper interaction 
> with the stdio streams; that's why I suggested that their *technique* 
> may be worth exploring.

I tried Console2 twice.  The first time I did, it had massive problems 
rendering the text properly.  But my second try did not confirm that, and 
I did not have time to reproduce the exact setup of the first try to find 
out what was changed.

> > Think copy/pasting (you have to enable it manually!
> 
> One time *only*, then you can forget about it.

One time per box/reinstall.  Oh, and per user who downloads MSys.  And on 
some setups (don't pretend you have not see them) per reboot, because the 
admins reset the registry on boot.

> > you have to _right_ click to finish the selection!
> 
> So what?  Sure, it's a little bit different, but you can quickly get 
> used to it.  I don't see this as a particular problem.

So we disagree.

> > You can forget about multi-line selections if the first line of what 
> > you want to select does not start in the first column).
> 
> Yes.  This can be a bit fiddly, but achievable nonetheless.

Yes.

And you can move to a new house by bike.  It is just very inconvenient.

> > Think scrolling back with a keyboard shortcut.
> 
> This is a limitation; I've learned to live with it.  Console2 can do it, 
> just like in the KDE konsole on my Linux box, so no reason an MSYS work 
> alike couldn't be developed.

I can live with it, too.  However, I like to live a _happy_ life.

> If you are suggesting Earnie is incompetent, [...]

I came nowhere near that.  Neither will I, ever.

> We live on their OS platform [Windows], so we just have to do the best 
> we can with what they provide.

No, I live on planet earth.  When I have to work on Windows, I try to 
solve the issues beforehand, rather than live with limitations.

That is the reason we rewrote spawnvpe() in msysGit, since the native 
version of that function is too limiting.  Actually, we have quite a lot 
of examples where we do not just take what they provide, since it is not 
good enough.

> > BTW another solution to that console problem I will explore is using 
> > Xming. ?A guy on #git told me that startup is almost instantaneous. 
> > And it has all the advantages of X11, since it _is_ X11.
> 
> Thanks.  I'll take a look, next week.

Me, too ;-)

Ciao,
Dscho

On Saturday 08 December 2007 11:35, Johannes Schindelin wrote:
> To propose Console2, admitting that it does not run on older Windows
> (which are way preferable to me, since I have lots of licenses for
> them that work, thanks to Microsoft's insistence on selling Windows
> with every computer, and they run way faster in
> virtualisers/emulators) is what qualifies as "half-assed" with this
> coder.

If you'd taken the trouble to read my suggestion *properly*, you'd=20
realise that I *wasn't* suggesting adoption of Console2, for this=20
reason amongst others.  What I did suggest was adopting their method=20
for interaction with the stdio streams, but in a truly open GUI=20
framework, which *could* support those older Woe32 versions.

> > There are two officially supported methods of running the MSYS
> > shell:--
> >
> > 1) In a native Woe32 console. =A0This is the only one of the two
> > which is truly robust; it has always been available, and is the
> > default choice for Cygwin, but not for MSYS. =A0In a recent poll, on
> > this list, those who bothered to respond were unanimous that it
> > should also become the default for MSYS.
>
> I wasn't there; I would have opposed.
>
> Even if we have to use cmd/command.exe with msysGit, since for
> example ssh password input or paging with "less" does not work
> properly in rxvt, the shortcomings of cmd/command are so annoying
> that I curse out loud in the general direction of Redmond almost
> every time I have to use it.

If you think that running MSYS in a native Woe32 console means running=20
cmd.exe or command.com, then perhaps you should question your own=20
understanding of the issues, before branding others as incompetent.

> Think resizing the window (not that hard, everybody else seems to do
> it just fine).

Yes, this is about the *only* real limitation of the native console.
Console2 is able to do this, while still maintaining proper interaction=20
with the stdio streams; that's why I suggested that their *technique*=20
may be worth exploring.

> Think copy/pasting (you have to enable it manually!

One time *only*, then you can forget about it.

> you have to _right_ click to finish the selection!

So what?  Sure, it's a little bit different, but you can quickly get=20
used to it.  I don't see this as a particular problem.

> You can forget=20
> about multi-line selections if the first line of what you want to
> select does not start in the first column).

Yes.  This can be a bit fiddly, but achievable nonetheless.

> Think scrolling back with a keyboard shortcut.

This is a limitation; I've learned to live with it.  Console2 can do it,=20
just like in the KDE konsole on my Linux box, so no reason an MSYS work=20
alike couldn't be developed.

> > 2) In an RXVT. =A0Currently the default, but has always been beset by
> > =A0 =A0problems. =A0Earnie, who originally chose to make it the default,
> > and who did not vote in the poll, devoted a lot of effort in trying
> > to fix it, before eventually conceding defeat.
>
> Yes, fighting with the Win32 API is more difficult than any
> adventure/first-person-shooter game I ever saw. =A0But never attribute
> to malice that which can be explained by incompetence. =A0After all,
> the same bunch still have the most virus- and bug-ridden OS out
> there, even after years of money heading their way.

I don't get your point.  If you are suggesting Earnie is incompetent,=20
then you will not win many friends here; if you are suggesting=20
Microsnot are, then so what?  We live on their OS platform, so we just=20
have to do the best we can with what they provide.

> BTW another solution to that console problem I will explore is using
> Xming. =A0A guy on #git told me that startup is almost instantaneous.
>=A0And it has all the advantages of X11, since it _is_ X11.

Thanks.  I'll take a look, next week.

Regards,
Keith.

Hi,

On Fri, 7 Dec 2007, Keith Marshall wrote:

> On Fri, 2007-12-07 at 01:03 +0000, Johannes Schindelin wrote:
> 
> > On Thu, 6 Dec 2007, Keith Marshall wrote:
> > 
> > > On Wednesday 05 December 2007 02:04, Cesar Strauss wrote:
> > > > I can't see anything obviously wrong with your setup, other than 
> > > > rxvt doesn't work...
> > > 
> > > RXVT has been a `Right Royal Pain in the Posterior', for as long as 
> > > I can remember.
> > 
> > IMHO it would be better to fix Rxvt
> 
> It is easy to express such an opinion, but are you volunteering to put 
> in the necessary effort to achieve that?  If `yes', then I look forward 
> to testing the fruits of your labour; if `no', then why do expect others 
> to expend such effort, when those who have tried in the past have come 
> to the conclusion that such an ideal may be unachievable?

In fact, once I breathe some air after having succeeded in compiling 
Subversion+Perl-Module in msysGit, that is my next target.

Don't hold your breath for it.

> > than to point to half-assed "solutions".
> 
> No one has done any such thing.

To propose Console2, admitting that it does not run on older Windows 
(which are way preferable to me, since I have lots of licenses for them 
that work, thanks to Microsoft's insistence on selling Windows with every 
computer, and they run way faster in virtualisers/emulators) is what 
qualifies as "half-assed" with this coder.

> There are two officially supported methods of running the MSYS shell:--
> 
> 1) In a native Woe32 console.  This is the only one of the two which is
>    truly robust; it has always been available, and is the default choice
>    for Cygwin, but not for MSYS.  In a recent poll, on this list, those
>    who bothered to respond were unanimous that it should also become the
>    default for MSYS.

I wasn't there; I would have opposed.

Even if we have to use cmd/command.exe with msysGit, since for example ssh 
password input or paging with "less" does not work properly in rxvt, the 
shortcomings of cmd/command are so annoying that I curse out loud in the 
general direction of Redmond almost every time I have to use it.

Think resizing the window (not that hard, everybody else seems to do it 
just fine). Think copy/pasting (you have to enable it manually! you have 
to _right_ click to finish the selection! You can forget about multi-line 
selections if the first line of what you want to select does not start in 
the first column).  Think scrolling back with a keyboard shortcut.

> 2) In an RXVT.  Currently the default, but has always been beset by
>    problems.  Earnie, who originally chose to make it the default, and
>    who did not vote in the poll, devoted a lot of effort in trying to
>    fix it, before eventually conceding defeat.

Yes, fighting with the Win32 API is more difficult than any 
adventure/first-person-shooter game I ever saw.  But never attribute to 
malice that which can be explained by incompetence.  After all, the same 
bunch still have the most virus- and bug-ridden OS out there, even after 
years of money heading their way.

BTW another solution to that console problem I will explore is using 
Xming.  A guy on #git told me that startup is almost instantaneous.  And 
it has all the advantages of X11, since it _is_ X11.

Ciao,
Dscho

On Fri, 2007-12-07 at 01:03 +0000, Johannes Schindelin wrote:
[Replying to me privately -- please keep discussion on-list]

> On Thu, 6 Dec 2007, Keith Marshall wrote:
> 
> > On Wednesday 05 December 2007 02:04, Cesar Strauss wrote:
> > > I can't see anything obviously wrong with your setup, other than
> > > rxvt doesn't work...
> > 
> > RXVT has been a `Right Royal Pain in the Posterior', for as long as
> > I can remember.
> 
> IMHO it would be better to fix Rxvt

It is easy to express such an opinion, but are you volunteering to put
in the necessary effort to achieve that?  If `yes', then I look forward
to testing the fruits of your labour; if `no', then why do expect others
to expend such effort, when those who have tried in the past have come
to the conclusion that such an ideal may be unachievable?

> than to point to half-assed "solutions".

No one has done any such thing.  There are two officially supported
methods of running the MSYS shell:--

1) In a native Woe32 console.  This is the only one of the two which is
   truly robust; it has always been available, and is the default choice
   for Cygwin, but not for MSYS.  In a recent poll, on this list, those
   who bothered to respond were unanimous that it should also become the
   default for MSYS.

2) In an RXVT.  Currently the default, but has always been beset by
   problems.  Earnie, who originally chose to make it the default, and
   who did not vote in the poll, devoted a lot of effort in trying to
   fix it, before eventually conceding defeat.

In addition to these, it has been suggested that the Console-2 project
may be worthy of consideration.  Users are welcome to explore that
option for themselves, but I don't think it should be bundled as a
standard option for MSYS, for the reasons I've already stated.

Regards,
Keith.

Hi,

On Thu, 6 Dec 2007, Keith Marshall wrote:

> On Wednesday 05 December 2007 02:04, Cesar Strauss wrote:
> > I can't see anything obviously wrong with your setup, other than rxvt
> > doesn't work...
> 
> RXVT has been a `Right Royal Pain in the Posterior', for as long as I 
> can remember.

IMHO it would be better to fix Rxvt than to point to half-assed 
"solutions".

Ciao,
Dscho

On Wednesday 05 December 2007 02:04, Cesar Strauss wrote:
> I can't see anything obviously wrong with your setup, other than rxvt
> doesn't work...

RXVT has been a `Right Royal Pain in the Posterior', for as long as I 
can remember.

The last time the issue was raised, the consensus on this list, and/or 
on MinGW-Users, was that it should no longer be the default console for 
MSYS; I think we need to make it happen, so MSYS-1.0.11 will deliver in 
accord with this consensus.

FWIW, I've recently been playing with Console2, as recently recommended 
by Brian Dessent.  I was disappointed by this, when I first looked at 
it about a year ago, but it now appears to be progressing nicely.  I 
was tempted to suggest bundling it as a preconfigured MSYS console, but 
am hesitant to do so, because:--

1) It is, (apparently), suitable for use only on WoeNT derived OS
   hosts, thus excluding those who still use Woe9x.

2) Although ostensibly GPL, it isn't a truly open project, since its
   lead developer insists on supporting only Microsnot's Visual Studio
   as the build environment.

3) Perhaps as a consequence of (2), it has dependencies on two DLLs
   which are not distributed as OS components, but are available in
   the VS redistributable kit from Microsnot's download site.  (The
   developer actually includes these two DLLs in his source package,
   obviously as binaries only, which may constitute a GPL violation).

Would anyone be interested in adapting Console2's techniques into a 
truly Open Source application, for distribution with some future 
version of MSYS?  (I'd consider it myself, but I have other priorities 
at the moment, and I don't want to spread my efforts too thinly).

Regards,
Keith.

Vincent Torri wrote:
> I've installed msys 1.0.11 and autoconf 2.61 and automake 1.10 from the 
> technology preview (msys dvlpr 1.0.0 alpha 1), and when I launch aclocal, 

The msysDVLPR-1.0.0-alpha-1 release is intended mainly for MSYS 
developers. Unless you want to build MSYS itself, you probably want to 
fetch the tools in the "MSYS Supplementary Tools" package.

Hope this helps,

Cesar

All
     We recently switched from a very old set of UnixUtils to MSYS to get
Unix/Linux style command line tools like bash, make, awk, install, etc.
We use these tools as part of our software/firmware development and
release process. The process is controlled by a set of Makefiles which
call a mixture of native Windows binaries, shell scripts and MSYS
utilities. We use this process as Makefiles provide a very powerful
means of automating build processes. It also allows us to build on
native Linux with the same scripts.

     Here however is where the problems started. After installing MSYS we
noticed some very odd file permission problems after building on Windows
under MSYS and native Linux.

     All builds are performed on a Windows 2003 hosted file system. This
is accessed via MSYS by whatever direct mechanism it uses and from Linux
using NFS. The Windows 2003 server is running Unix Utils for Windows to
provide the NFS and also NIS user/group mappings. Therefore under Linux
you get to see the Windows username and primary group from an "ls -al".
The report from "id" also reflects the correct Windows defined username
and groups created within Active Directories.

     The build I am performing is partly run under Windows to get MS
VC.NET to build the Windows DLL libraries and partly under Linux to
build the Linux shared object libraries. All builds are through
Makefiles using MSYS make with a "make" shell of "bash", again from
MSYS. For Windows side builds the make process is started from a CMD
window rather than an MSYS "bash" shell.

     Individually the build work fine and files are created with
reasonable permissions. However when we come to perform the install it
all goes wrong. The install is generally run on Linux first. This uses
"install" to create directories (-d -m 0755) and also install files (-m
0644). If we do this and view the results from Linux you see the Windows
file permissions as defined by the install mode. If I then run the
Windows side install, which deposits additional files under the tree
already built under Windows, the files and directories created all come
out with permissions 0700.

     If however I run the MSYS Windows side install first and then the
Linux install, all files get the correct permissions. Sadly I cannot do
it this way around in the final build.

     To summarise, if I individually create files or directories under
MSYS Windows or Linux the permissions look OK. Under Windows MSYS the
permissions seem to be an exact inherited copy from the parent
directory. Under Linux however the permissions are now an exact
inherited copy of the Windows permissions but have the appropriate
primary group and other group. If I create a directory first in Linux
and then a file/directory under MSYS within the Linux created directory
the file permissions are trashed to 0700. It would seem therefore that
MSYS is not able to copy through the permissions from the Linux created
parent.

     On a slightly related but possibly bogus thread, the result of "id"
within MSYS is completely different to the Linux view. How or where does
MSYS get its user ID and group ID information from? Could this be the
source of my problems?

     Hope this all makes some sense.

        Cheers

           David.

-- 
David Bilsby

Senior Engineer
TEK Microsystems Ltd.
Unit A, Malvern View, Willow End Park,
Blackmore Park Road, Malvern, Worcs. WR13 6NN.
Email: db...@te...
Tel: +44 1684 311113
WWW: www.tekmicro.com

Allan Dee wrote:
> Cesar Strauss <cestrauss@...> writes:
> 
>> Allan Dee wrote:
>>> Cesar Strauss <cestrauss@...> writes:
>>>
>>>> Could you try replacing your msys.bat file with the following one:
>>> That's the one I've been using.
>>>
>> Could you try this:
>>
>> 1) Copy you MSYS shortcut to "MSYS Console" and add the --norxvt option
>> to the command-line.
>> 2) Run this shortcut, you should see an Windows Console appear, running
>> the MSYS shell.
> 
> Here we go, note that I've renamed my ~/.bash_profile while trying to
> make this work.
> 

Thanks, this was helpful.

I can't see anything obviously wrong with your setup, other than rxvt 
doesn't work...

I uploaded a debug version of the MSYS runtime DLL, could you try it, 
temporarily?

1) Download
http://downloads.sourceforge.net/mingw/MSYS-1.0.11-20071204-debug.tar.bz2
2) Make a backup copy of your msys-1.0.dll file.
3) Unpack the files over your MSYS installation.
4) Run: strace rxvt > strace.txt
5) Send me the strace.txt file.

Regards,
Cesar

On 2007-12-02 14:11Z, Vincent Torri wrote:
> 
> On Sun, 2 Dec 2007, Greg Chicares wrote:
>>
>> $od -t a /etc/fstab
>> 0000000   c   :   /   M   i   n   G   W  sp   /   m   i   n   g   w  nl
>> 0000020
>>
>> Does yours contain a 'cr' character?
> 
> indeed, it's like that. With mingw2 :
> 
> $ od -t a /etc/fstab
> 0000000  nl   d   :   /   m   s   y   s   /   1   .   0   /   m   i   n
> 0000020   g   w   2  ht   /   m   i   n   g   w  nl  nl
> 0000034
> 
> is it a problem ?

Apparently not. I know I once created an invalid 'fstab'
that was ignored because of some line-ending problem:
either I had a CRLF ending, or none at all. But I can't
reproduce the problem today, so maybe MSYS has been made
more robust in this respect.

To Keith:

I renamed d:\msys\1.0\mingw to d:\msys\1.0\mingw2, did the changes in 
fstab and profile files and it works. I don't know why there is a problem 
with mingw subdir. It always worked before.

One thing: my firewall stopped scanning files in that directoy. That's the 
only specific thing that occurs in d:\msys\1.0\mingw, afaict.

On Sun, 2 Dec 2007, Greg Chicares wrote:

> On 2007-12-02 13:24Z, Vincent Torri wrote:
>>
>> $ ls /mingw
>> ls: /mingw: No such file or directory
> [...]
>> My fstab file contains:
>>
>> d:/msys/1.0/mingw       /mingw
>>
>> I have verified that d:/msys/1.0/mingw exists and contains the usual
>> directories and files
>
> $od -t a /etc/fstab
> 0000000   c   :   /   M   i   n   G   W  sp   /   m   i   n   g   w  nl
> 0000020
>
> Does yours contain a 'cr' character?

indeed, it's like that. With mingw2 :

$ od -t a /etc/fstab
0000000  nl   d   :   /   m   s   y   s   /   1   .   0   /   m   i   n
0000020   g   w   2  ht   /   m   i   n   g   w  nl  nl
0000034

is it a problem ?

Vincent Torri

On 2007-12-02 13:24Z, Vincent Torri wrote:
> 
> $ ls /mingw
> ls: /mingw: No such file or directory
[...]
> My fstab file contains:
> 
> d:/msys/1.0/mingw       /mingw
> 
> I have verified that d:/msys/1.0/mingw exists and contains the usual 
> directories and files

$od -t a /etc/fstab
0000000   c   :   /   M   i   n   G   W  sp   /   m   i   n   g   w  nl
0000020

Does yours contain a 'cr' character?

Vincent Torri wrote:

> My fstab file contains:
> 
> d:/msys/1.0/mingw       /mingw
> 
> I have verified that d:/msys/1.0/mingw exists and contains the usual
> directories and files

You shouldn't need any fstab file at all, because d:/msys/1.0 translates
to / so d:/msys/1.0/mingw naturally translates to /mingw without having
to specify any specific mapping.  You only need a fstab file if you
install MinGW somewhere other than the MSYS root.

Now, that doesn't explain why this doesn't work, because I can't see any
reason why it should cause failure, but try just deleting/removing
fstab, or comment out that entry.

Brian

Hey,

I've re-installed my msys/mingw system yesterday. It was working.

Today, I launch the MSYS terminal and try to compile a library. gcc is not 
found.

I installed msys in d:\msys\1.0 and mingw in d:\msys\1.0\mingw

I tried that:

$ gcc
sh: gcc: command not found

$ ls /mingw
ls: /mingw: No such file or directory

$ ls /usr/mingw/
ls: /usr/mingw/: No such file or directory

My fstab file contains:

d:/msys/1.0/mingw       /mingw

I have verified that d:/msys/1.0/mingw exists and contains the usual 
directories and files

it seems that msys can not find /usr/mingw and/or /mingw anymore

does someone know why ?

thank you

Vincent

On 2007-12-02 00:02Z, Thom DeCarlo wrote:
>
> I've been away from MinGW/Msys for a while, but have a reason to use it
> again. Unfortunately, the requirement is to run the applications without
> the whole bash shell stuff. The customer wants to use just a few
> commands (tar, gzip, sleep, rsh, and a few others) from a Windoze
> command terminal. For example, the tar program will be executed from
> within a *.bat file. 

I expect they'll run into problems...

> Is this possible? I've tried copying tar.exe and msys-1.dll to an
> otherwise empty folder and ran "tar --help" and got nothing. I also
> cd'ed to c:\msys\1.0\bin and tried the same thing with the same result.
> Hopefully, it is just that I need to add something to my Windoze $path.

...and surprises with absolute paths, too, because MSYS mounts
its own filesystem. Why not use native ports instead?

http://www.google.com/search?q=gnu+tar+gzip+native+windows+ported

I assume you've explained to the customer that it would be
less masochistic to switch to a real shell.

On Sunday 02 December 2007 00:02, Thom DeCarlo wrote:
> I've been away from MinGW/Msys for a while, but have a reason to use
> it again. Unfortunately, the requirement is to run the applications
> without the whole bash shell stuff. The customer wants to use just a
> few commands (tar, gzip, sleep, rsh, and a few others) from a Windoze
> command terminal.

Well, I guess there's no accounting for poor taste :-)

> For example, the tar program will be executed from 
> within a *.bat file. 

Hmm.  Isn't this precisely how msys.bat starts up the shell, in the 
first place?

> Is this possible? I've tried copying tar.exe and msys-1.dll to an
> otherwise empty folder and ran "tar --help" and got nothing. I also
> cd'ed to c:\msys\1.0\bin and tried the same thing with the same
> result. Hopefully, it is just that I need to add something to my
> Windoze $path.

Yes.  It is possible.  I think, however, that you do need to set up an 
appropriate directory hierarchy.  IIRC, the MSYS executables must go in 
a `some/path/bin' directory, together with msys-1.dll, and you must 
also have the `some/path/etc' directory present, even if empty.  It's 
probably also a good idea to add that `some/path/bin' directory to the 
Windblows PATH.

Sorry, I can't be more explicit at present; I use only GNU/Linux at 
home, and I will not be back in my office until Friday.

HTH,
Keith.