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

On Thursday 31 January 2008 07:48, JonY wrote:
> fschmidt wrote:
> > http://www.mingw.org/download.shtml says to download
> > MSYS-<version>.exe but when I go to
> > http://sourceforge.net/project/showfiles.php?group_id=3D2435 I see no
> > such file. =A0So where is it?
>
> here you go!
>
> http://prdownloads.sourceforge.net/mingw/MSYS-1.0.10.exe?download

And that link may be seen on the page referred to by the OP; it is in=20
the fairly obvious `MSYS Base System --> Current Release: MSYS-1.0.10'=20
package.  I guess the OP was too lazy to expand the package view, to be=20
able to see the MSYS-1.0.10.exe file listed there.

Regards,
Keith.

Thanks, but I have no idea what is meant by "toolchain" nor how I'm 
supposed to edit some "mount table", so I don't know what it is I'm 
supposed to do, or what the convenience would be.

Are you saying that the most recent MinGW doesn't work with Vista? Thet 
there's some other MinGW I'm supposed to install?

I realize my questions must sound hopelessly naive, but I have been able 
to use msys and mingw productively on Windows; it is the installation 
that is difficult, and the installation instructions aren't adequate (to 
take an immediate example, how would one know without asking that one 
must search the archives for "Vista" before doing an install, or change 
some mount table -- if you see what I mean).

Bruce Sherwood

Greg Chicares wrote:
> On 2008-01-31 19:01Z, Bruce Sherwood wrote:
> 
>>I've used msys and mingw for several years but wanted to do a clean 
>>install on a machine I upgraded from XP to Vista. I've been quite 
>>baffled by ambiguous or incomplete installation instructions with 
>>respect to installing both msys and mingw. Should I install msys, then 
>>mingw, or the other way around? I think I've seen both instructions.
> 
> 
> If you always keep them distinct, then it doesn't matter
> because neither depends on the other.
> 
> One optional last step for convenience after you've
> installed them both is to mount the MinGW toolchain's
> directory by editing the MSYS mount table.
> 
> BTW, make sure you get the right MinGW stuff for vista:
> search the archives for "vista" or "X_OK".
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys

All --

I am using msys to run the same series of
bash wrappers that invoke gawk / sed / grep
scripts as well as bash built-ins to do data
conversions on Linux and Windows machines.

They work VERY well on MSys for the most part.

The only exception is with Windows boxes built
over Pentium 4 CPUs with Hyper threading turned on.

On P4 + HT Machines, I often have errors where my
bash wrapper script receives control before the
preceding gawk or sed script is done !

I suffer from errors where an intermediate file is
either nonexistent or incomplete or in the case of
my shared log files, I receive 'permission denied'
errors.

I have also noticed 'shuffled' log entries.

For example:

    bash starts

       bash: echo "bash start" > logfile

       gawk starts

          print "gawk log entry" >> logfile

          fflush logfile

       gawk ends

       bash:  echo "bash end" >> logfile

    bash ends

I have seen at random, unrepeatable instances
where "gawk log entries" FOLLOW "bash end" entries.

I have come to suspect that I need to set Processor
Affinity for my MSys programs.

I am not authorized to disable hyper threading on the
Machines.

Does anyone have any hints ?

Thanks !

-- kjh

On 2008-01-31 19:01Z, Bruce Sherwood wrote:
> I've used msys and mingw for several years but wanted to do a clean 
> install on a machine I upgraded from XP to Vista. I've been quite 
> baffled by ambiguous or incomplete installation instructions with 
> respect to installing both msys and mingw. Should I install msys, then 
> mingw, or the other way around? I think I've seen both instructions.

If you always keep them distinct, then it doesn't matter
because neither depends on the other.

One optional last step for convenience after you've
installed them both is to mount the MinGW toolchain's
directory by editing the MSYS mount table.

BTW, make sure you get the right MinGW stuff for vista:
search the archives for "vista" or "X_OK".

I've used msys and mingw for several years but wanted to do a clean 
install on a machine I upgraded from XP to Vista. I've been quite 
baffled by ambiguous or incomplete installation instructions with 
respect to installing both msys and mingw. Should I install msys, then 
mingw, or the other way around? I think I've seen both instructions.

Bruce Sherwood

fschmidt wrote:
> http://www.mingw.org/download.shtml says to download MSYS-<version>.exe but
> when I go to http://sourceforge.net/project/showfiles.php?group_id=2435 I
> see no such file.  So where is it?
> 

here you go!

http://prdownloads.sourceforge.net/mingw/MSYS-1.0.10.exe?download

http://www.mingw.org/download.shtml says to download MSYS-<version>.exe but
when I go to http://sourceforge.net/project/showfiles.php?group_id=2435 I
see no such file.  So where is it?

-- 
View this message in context: http://www.nabble.com/Where-is-MSYS.exe--tp15199539p15199539.html
Sent from the MinGW - MSYS mailing list archive at Nabble.com.

Johannes Schindelin wrote:
> On Tue, 29 Jan 2008, Dietfrid Mali wrote:
> 
>> I cannot see where I have insulted anyone here. I have simply stated my 
>> point of view on the state of the hardware here.Apparently you were 
>> looking for an occasion for being insulted.I'd say the remark coming 
>> closest to a personal insult Johannes Schindelin who apparently is quite 
>> an arrogant prick.
> 
> Yes, I am an arrogant prick, alright.
> 
> Just like anybody who could say something like "your software is not good.  
> Your work that you invested quite some time into is crap.  Help me!" and 
> not see the dichotomy.
> 
> I take it you heard something of the golden rule, or the cathegorical 
> imperative?  You should have applied that, and people would have jumped to 
> your help.
> 
> In other words, it does not help to _piss off_ the people you ask for 
> help.

It's pretty sad to see a second incident in less than a week. I'm
no angel myself, but, oh my, the SNR is dropping.

It looks like the less skill and knowledge there is, the bigger
the tendency to lash out and complain loudly. It betrays a
distressing lack of understanding of the problems developers face
trying to port and maintain tools on a platform that claims POSIX
compatibility with much reluctance and is rather hostile to
Unix-style portable software development. I would have been
embarrassed or sheepish at failing to solve the problem rather
than be righteously indignant.

Now nobody will help Dietfrid. We owe Dietfrid nothing. Odd, if he
is doing fine on Linux, why didn't he generate ze configure
scrippy in dat place? Or switch to Cygwin? I recommend that
Dietfrid get help from these upstanding guys:

http://technet.microsoft.com/en-us/interopmigration/bb380242.aspx

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

Hi,

On Tue, 29 Jan 2008, Dietfrid Mali wrote:

> I cannot see where I have insulted anyone here. I have simply stated my 
> point of view on the state of the hardware here.Apparently you were 
> looking for an occasion for being insulted.I'd say the remark coming 
> closest to a personal insult Johannes Schindelin who apparently is quite 
> an arrogant prick.

Yes, I am an arrogant prick, alright.

Just like anybody who could say something like "your software is not good.  
Your work that you invested quite some time into is crap.  Help me!" and 
not see the dichotomy.

I take it you heard something of the golden rule, or the cathegorical 
imperative?  You should have applied that, and people would have jumped to 
your help.

In other words, it does not help to _piss off_ the people you ask for 
help.

Hth,
Dscho

I cannot see where I have insulted anyone here. I have simply stated my poi=
nt of view on the state of the hardware here.Apparently you were looking fo=
r an occasion for being insulted.I'd say the remark coming closest to a per=
sonal insult Johannes Schindelin who apparently is quite an arrogant prick.=
Looks like you guys just can't take being told that what you do isn't quite=
 up to par, and also are two absolutely graceless persons or you would have=
 understood the amount of frustration behind my posting. Fuck yourselves.> =
Date: Tue, 29 Jan 2008 21:24:09 +0000> From: Joh...@gm...> To=
: kei...@us...> CC: min...@li...=
> Subject: Re: [Mingw-msys] Major problems installing MSys> > Hi Keith,> > =
On Tue, 29 Jan 2008, Keith Marshall wrote:> > > On Tuesday 29 January 2008 =
15:13, Dietfrid Mali wrote:> > > I know that this project is maintained by =
volunteers but yet I have to > > > say that for me this looks like the bigg=
est messy pile of software I > > > have ever seen in my life.> > > > And I =
have to say that this must be the most insolent plea for help that > > I ha=
ve ever seen in *my* life!> > Must be like that when some people complain t=
o Mensa that their entry quiz > is too hard ;-)> > Ciao,> Dscho> > > ------=
-------------------------------------------------------------------> This S=
F.net email is sponsored by: Microsoft> Defy all challenges. Microsoft(R) V=
isual Studio 2008.> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/=
> _______________________________________________> Mingw-msys mailing list>=
 Min...@li...> https://lists.sourceforge.net/lists/list=
info/mingw-msys
_________________________________________________________________
Neu: Internet Explorer 7 optimiert f=FCr MSN!
http://optimize.de.msn.com/default.aspx?mkt=3Dde-de=

Hi Keith,

On Tue, 29 Jan 2008, Keith Marshall wrote:

> On Tuesday 29 January 2008 15:13, Dietfrid Mali wrote:
> > I know that this project is maintained by volunteers but yet I have to 
> > say that for me this looks like the biggest messy pile of software I 
> > have ever seen in my life.
> 
> And I have to say that this must be the most insolent plea for help that 
> I have ever seen in *my* life!

Must be like that when some people complain to Mensa that their entry quiz 
is too hard ;-)

Ciao,
Dscho

On Tuesday 29 January 2008 15:13, Dietfrid Mali wrote:
> I know that this project is maintained by volunteers but yet I have
> to say that for me this looks like the biggest messy pile of software
> I have ever seen in my life.

And I have to say that this must be the most insolent plea for help that 
I have ever seen in *my* life!

> I have no clue how to get this to work 
> so that I could run aclocal, autoheader, automake and configure on
> scripts that work flawlessly on Linux. Installation is a horror - you
> neither know what exactly you need, nor where to put it.

All I will say is that I have installed *all* of the stuff you are 
whingeing about, without encountering the slightest problem, simply by 
following the instructions at: 
http://www.mingw.org/MinGWiki/index.php/GettingStarted

and cheerfully accepting the defaults for everything; it all works fine 
for me.  Perhaps you should direct your vitriolic criticism somewhere 
closer to home.

> Unfortunately I have to use this stuff, so please help me to get this
> going.

Are you kidding?  Do you seriously expect the voluntary maintainers of 
any software, especially that which you have acquired at zero cost, to 
respond sympathetically, when you insult them so wilfully?  And, please 
DO NOT post multipart MIME messages; use plain text ONLY, and set word 
wrap at 72 columns or less.

Regards,
Keith.

I am having major problems with installing MSys.

I am trying to use a automake/autogen based project from Linux.

I have installed mingw, msys and the msys developer package.

When trying to run aclocal, I have run into numerous errors.

"Can't locate Automake/Config.pm"

"autom4ate: unknown language: Autoconf-without-aclocal-m4"

I resolved this by installed automake 1.10. A hurdle was that it is
absolutely unclear where this stuff has to go. It took me a while to
figure that I should probably extract it to /usr/share. Using
/usr/local/share did not work.


"Can't locate Autom4te/General.pm"

Resolved this by installing autoconf 2.61.=20

"String found where operator expected at /bin/autom4te line 280, near "erro=
r "GNU m4 1.4 or later: $m4"

Resolved: Now autoconf stuff has to go to /usr/local/share and not just /us=
r/share. How funny.

Btw, trying to installing it using the mingwPORT stuff failed due to numero=
us errors.

"Can't locate object method "path" via package "Request" (perhaps you forgo=
t to load "Request"?) at /usr/local/share/autoconf/Autom4te/C4che.pm line 6=
9, <GEN1> line 111"

WTF?

At this point I have given up.



I know that this project is maintained by volunteers but yet I have to say =
that for me this looks like the biggest messy pile of software I have ever =
seen in my life. I have no clue how to get this to work so that I could run=
 aclocal, autoheader, automake and configure on scripts that work flawlessl=
y on Linux. Installation is a horror - you neither know what exactly you ne=
ed, nor where to put it.

Unfortunately I have to use this stuff, so please help me to get this going=
.

_________________________________________________________________
Neu: Internet Explorer 7 optimiert f=FCr MSN!
http://optimize.de.msn.com/default.aspx?mkt=3Dde-de=

On Thursday 17 January 2008 22:53, Michael Kappert wrote:
> Hmm. I'm thinking if the escape sequences really make sense.

IMO, yes.

> If a user has to edit his scripts/source code by prefixing strings
> with escape chars, couldn't he just as well change the offending
> paths to Windows format?

No, because then you would break portability to other host types, in 
particular those expecting POSIX syntax.  Unless you are still using 
the neolithic technique of packaging a separate Makefile for every 
platform you wish to support, this isn't an acceptable option; MSYS is 
not in the business of offering sacrifices to the dinosaurs.

The portable way to set this up is with a macro such as

   MSYS_LITERAL = @MSYS_LITERAL@

in Makefile.in, and let the configure script provide an appropriate 
substitution when building on MSYS, or nothing otherwise; then, again 
in Makefile.in, where you want to protect an argument from the MSYS 
path transformation, you would preface it with $(MSYS_LITERAL).

> Also, I'd expect the 'AUTO' setting to try to Do The Right Thing,

I consider it to be the right thing, as I've proposed it,

> and ON and/or OFF to be manually fine-tuneable.

Nope.  OFF means just that. EVERYWHERE; how can that be fine tunable? 
Ditto for ON.  The fine tunable option is that which I've called AUTO; 
at present I can visualise no other way to achieve it, than that which 
I've proposed, but I'm open to suggestions.

Regards,
Keith.

Brian Antao wrote:
> Looks like the best solution is to use Cygwin... in which case wouldI have to uninstall MinGW/msys as there might be potential conflicts between the two systems residing together... what about the libraries that I have compiled with MinGW/msys .. would all of these need to be built again under Cygwin ?Thanks again,      -- BrianOn Thu, 17 Jan 2008 21:46:30 +0000 MSYS Discussion List wroteOn Thursday 17 January 2008 20:54, Johannes Schindelin wrote:> On Thu, 17 Jan 2008, Brian Antao wrote:> > The standard release of MinGW/msys does not contain the file> > sys/resource.h. I need this file for a compilation. Where in the> > distribution Can I find it ?You cannot, for it is intentionally omitted; it defines POSIX resources which are unsupported in the native Windows environment, in which MinGW is intended to work. You need to port the application.> There is a huge difference between MinGW and MSys. MSys has this> file, you ju
st 
>  need to download msysDVLPR. But beware: you have to> start the MSys shell, and your programs will be linked to> msys-1.0.dll.And therein lies the clue: the features defined in this header are not natively supported on Windows, and you need a POSIX emulation layer, (as provided by msys-1.0.dll), to run such programs.The solution here is *not* simply to download msysDVLPR; we sanction that only for those who wish to contribute to MSYS development itself. The solution, which we officially sanction, is one of the following:--1) If you want the program to run natively on Windows, then you need to port the missing features to use the native platform APIs; in so doing, you will likely develop your own replacement for the "missing" header, or at least some subset of it, defining those features which you find that you actually need to implement.2) If you don't want to port the application, and you don't mind the dependency on a POSIX emulation layer, then we recommend that y
ou 
>  use Cygwin, *not* msysDVLPR. In fact, MSYS itself is a limited feature fork of Cygwin version 1.3, (which is quite old).We will not provide support for use of msysDVLPR for any purpose beyond the development of MSYS itself, nor beyond the scope of the declared objective of MSYS, which is restricted to providing a host environment in which to run MinGW, and MinGW applications. If you choose to follow this unsanctioned development path, then you are on your own.Regards,Keith.-------------------------------------------------------------------------This SF.net email is sponsored by: MicrosoftDefy all challenges. Microsoft(R) Visual Studio 2008.http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________Mingw-msys mailing lis...@li...://lists.sourceforge.net/lists/listinfo/mingw-msys

The text portion (as opposed to HTML) of your mail seems
to be on a single line. As a consequence, I didn't read it.
I would also suspect that others didn't read it either,
for the same reason.
I hope it wasn't anything important.

The text portion also seems to contain some HTML. Not cool.


Come to think of it, I remember someone sending mail to either
this or the MinGW list so that most lines ended with an equals sign
('='), which my reader (Thunderbird) then regarded as a sign of
the lines being wrapped. That had the effect of having each
paragraph on their own line. Not very readable.

This is worse - the whole message is on a single line.
Granted, the reader wraps the line on screen edge (or when quoting,
apparently somewhere around column 2000) as many times as needed,
but that does not mentionably improve the readability.

Anyway, didn't mean to insult or offend.
I was just kinda hoping you would fix it.


-- 
Tuomo

... What are you doing?!? The message is over, GO AWAY!

Looks like the best solution is to use Cygwin... in which case wouldI have to uninstall MinGW/msys as there might be potential conflicts between the two systems residing together... what about the libraries that I have compiled with MinGW/msys .. would all of these need to be built again under Cygwin ?Thanks again,      -- BrianOn Thu, 17 Jan 2008 21:46:30 +0000 MSYS Discussion List wroteOn Thursday 17 January 2008 20:54, Johannes Schindelin wrote:> On Thu, 17 Jan 2008, Brian Antao wrote:> > The standard release of MinGW/msys does not contain the file> > sys/resource.h. I need this file for a compilation. Where in the> > distribution Can I find it ?You cannot, for it is intentionally omitted; it defines POSIX resources which are unsupported in the native Windows environment, in which MinGW is intended to work. You need to port the application.> There is a huge difference between MinGW and MSys. MSys has this> file, you just need to download msysDVLPR. But beware: you have to> start the MSys shell, and your programs will be linked to> msys-1.0.dll.And therein lies the clue: the features defined in this header are not natively supported on Windows, and you need a POSIX emulation layer, (as provided by msys-1.0.dll), to run such programs.The solution here is *not* simply to download msysDVLPR; we sanction that only for those who wish to contribute to MSYS development itself. The solution, which we officially sanction, is one of the following:--1) If you want the program to run natively on Windows, then you need to port the missing features to use the native platform APIs; in so doing, you will likely develop your own replacement for the "missing" header, or at least some subset of it, defining those features which you find that you actually need to implement.2) If you don't want to port the application, and you don't mind the dependency on a POSIX emulation layer, then we recommend that you use Cygwin, *not* msysDVLPR. In fact, MSYS itself is a limited feature fork of Cygwin version 1.3, (which is quite old).We will not provide support for use of msysDVLPR for any purpose beyond the development of MSYS itself, nor beyond the scope of the declared objective of MSYS, which is restricted to providing a host environment in which to run MinGW, and MinGW applications. If you choose to follow this unsanctioned development path, then you are on your own.Regards,Keith.-------------------------------------------------------------------------This SF.net email is sponsored by: MicrosoftDefy all challenges. Microsoft(R) Visual Studio 2008.http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________Mingw-msys mailing lis...@li...://lists.sourceforge.net/lists/listinfo/mingw-msys

Keith Marshall wrote:
> On Wednesday 16 January 2008 21:16, Michael Kappert wrote:
>> we have a workaround by manually editing the Makefile.
> 
> That's good; perhaps you could share the solution?

Yes, I'll post this on cli...@li...
(gmane.lisp.clisp.devel).

> So, the solution I'd like to propose involves *two* environment 
> variables: firstly...
> 
>    MSYS_PATH_TRANSFORM=[ON | OFF | AUTO]
> 
> where `MSYS_PATH_TRANSFORM=ON' would correspond to the present 
> behaviour, `MSYS_PATH_TRANSFORM=OFF' would disable it globally, and 
> `MSYS_PATH_TRANSFORM=AUTO' would activate the mode where a special 
> initial byte sequence would disable it for just the one argument, 
> (causing the initial signature byte sequence to be stripped away, with 
> the remainder of the argument left untouched by any transformation).
> 
> In the event that MSYS_PATH_TRANSFORM is not defined, then a default 
> behaviour would be adopted; IMO, that default should be equivalent to 
> `MSYS_PATH_TRANSFORM=AUTO'.
> 
> The second environment variable would identify the initial byte sequence 
> to be used to signify an argument which is to be exempt from the normal 
> path transformation behaviour, when `MSYS_PATH_TRANSFORM=AUTO' is in 
> effect; let's call it...
> 
>    MSYS_PATH_TRANSFORM_IGNORE=key
> 
> where `key' defines that initial signature byte sequence.
> 
> Again, if MSYS_PATH_TRANSFORM_IGNORE is not defined, a default `key' 
> value would be required; this could be the `?:' I suggested previously, 
> or any other suitable default agreed through further discussion on this 
> list.
> 
> A possible variation on the above: it may be possible to achieve similar 
> functionality with just one environment variable, by accepting a syntax 
> such as...
> 
>    MSYS_PATH_TRANSFORM="AUTO;IGNORE=key"
> 
> (I'm not sure, but parsing that may actually be less expensive, than 
> requiring a second environment variable look-up; intuitively, I suspect 
> that this would be the case).
> 
> Any further thoughts?

Hmm. I'm thinking if the escape sequences really make sense.
If a user has to edit his scripts/source code by prefixing strings with
escape chars, couldn't he just as well change the offending paths to
Windows format?
Also, I'd expect the 'AUTO' setting to try to Do The Right Thing,
and ON and/or OFF to be manually fine-tuneable.

Anyway, this doesn't really matter to me; for our purpose your suggestion
sounds perfect!

Regards
Michael

On Thursday 17 January 2008 20:54, Johannes Schindelin wrote:
> On Thu, 17 Jan 2008, Brian Antao wrote:
> > The standard release of MinGW/msys does not contain the file
> > sys/resource.h. I need this file for a compilation. Where in the
> > distribution Can I find it ?

You cannot, for it is intentionally omitted; it defines POSIX resources 
which are unsupported in the native Windows environment, in which MinGW 
is intended to work.  You need to port the application.

> There is a huge difference between MinGW and MSys.  MSys has this
> file, you just need to download msysDVLPR.  But beware: you have to
> start the MSys shell, and your programs will be linked to
> msys-1.0.dll.

And therein lies the clue: the features defined in this header are not 
natively supported on Windows, and you need a POSIX emulation layer, 
(as provided by msys-1.0.dll), to run such programs.

The solution here is *not* simply to download msysDVLPR; we sanction 
that only for those who wish to contribute to MSYS development itself.  
The solution, which we officially sanction, is one of the following:--

1) If you want the program to run natively on Windows, then you need to 
port the missing features to use the native platform APIs; in so doing, 
you will likely develop your own replacement for the "missing" header, 
or at least some subset of it, defining those features which you find 
that you actually need to implement.

2) If you don't want to port the application, and you don't mind the 
dependency on a POSIX emulation layer, then we recommend that you use 
Cygwin, *not* msysDVLPR.  In fact, MSYS itself is a limited feature 
fork of Cygwin version 1.3, (which is quite old).

We will not provide support for use of msysDVLPR for any purpose beyond 
the development of MSYS itself, nor beyond the scope of the declared 
objective of MSYS, which is restricted to providing a host environment 
in which to run MinGW, and MinGW applications.  If you choose to follow 
this unsanctioned development path, then you are on your own.

Regards,
Keith.

At 03:02 PM 1/17/08, you wrote:
>[reformatted--please break lines at 70 characters or so]
>
>On 2008-01-17 20:46Z, Brian Antao wrote:
> > Hello,The standard release of MinGW/msys does not contain the
> > filesys/resource.h. I need this file for a compilation. Where
> > in the distributionCan I find it ?Thanks very much in advance.
> >        -- Brian
>
>The posix header <sys/resource.h> ? MinGW isn't posix: it's gcc
>plus the msw api, and uses an msw C runtime library. The header
>wouldn't help without an implementation of the functions it
>prototypes. Your options include: (1) rewrite the program to
>use msw system calls; (2) try cygwin instead.


there are 3 resource.h files in the 3.6 POVray source (windows).
here: http://www.povray.org/download/
This is painting a blurry picture for me why I needed MinGW to build 
POV and why Msys was the wrong choice and didn't work (here on win98SE)

[reformatted--please break lines at 70 characters or so]

On 2008-01-17 20:46Z, Brian Antao wrote:
> Hello,The standard release of MinGW/msys does not contain the
> filesys/resource.h. I need this file for a compilation. Where
> in the distributionCan I find it ?Thanks very much in advance.
>        -- Brian

The posix header <sys/resource.h> ? MinGW isn't posix: it's gcc
plus the msw api, and uses an msw C runtime library. The header
wouldn't help without an implementation of the functions it
prototypes. Your options include: (1) rewrite the program to
use msw system calls; (2) try cygwin instead.

Hi,

On Thu, 17 Jan 2008, Brian  Antao wrote:

> The standard release of MinGW/msys does not contain the file 
> sys/resource.h. I need this file for a compilation. Where in the 
> distribution Can I find it ?

There is a huge difference between MinGW and MSys.  MSys has this file, 
you just need to download msysDVLPR.  But beware: you have to start the 
MSys shell, and your programs will be linked to msys-1.0.dll.

Hth,
Dscho

Hello,The standard release of MinGW/msys does not contain the filesys/resource.h. I need this file for a compilation. Where in the distributionCan I find it ?Thanks very much in advance.       -- Brian

On Wednesday 16 January 2008 21:16, Michael Kappert wrote:
> > However, look what happens, if you make a very small
> > alteration to that string:--
> >
> > =A0 =A0$ ./test "?:(../src) (foo::bar)"
> > =A0 =A0test: ?:(../src) (foo::bar)
> > =A0 =A0=3D=3D=3D=3D=3D=3D^^=3D=3D=3D^=3D=3D=3D=3D=3D=3D=3D=3D=3D^^=3D=
=3D=3D=3D
> >
> > Close to what you want, but not quite there.
>
> Ok! Following your example I found a way to modify the lisp expr
> such that it's still valid but does not get replaced. So at least
> we have a workaround by manually editing the Makefile.

That's good; perhaps you could share the solution?

> > Additionally, while I've suggested `?:' as the signature tag, the
> > user population should be given an opportunity to discuss that, and
> > to agree on any final preferred sequence.
>
> CLISP's vote goes to the environment variable solution (or implement
> both :^))

On further reflection, I'm leaning towards a solution which is indeed a=20
combination of both.

A simple environment variable, which merely turns the path=20
transformation on of off just will not do.  I say this, based on a=20
discussion, on this very list, which was also related to a LISP=20
expression: in that case, an ELISP expression, to be passed to the=20
embedded interpreter in Emacs, during the build of that editor.  The=20
reason why the simple on/off environmental switch would not have=20
worked, on that occasion, was that the command line invoking the ELISP=20
interpreter contained not only the ELISP expression, which needed to be=20
exempt from path transformation, but also POSIX style paths, which did=20
require it.  Thus, that command required a solution which would allow=20
path transformation to be on for some arguments on the command line,=20
but off for others, all within the scope of a single command=20
invocation; that requirement simply cannot me satisfied, with a simple=20
on/off selection, applying globally to the entire command line.

So, the solution I'd like to propose involves *two* environment=20
variables: firstly...

   MSYS_PATH_TRANSFORM=3D[ON | OFF | AUTO]

where `MSYS_PATH_TRANSFORM=3DON' would correspond to the present=20
behaviour, `MSYS_PATH_TRANSFORM=3DOFF' would disable it globally, and=20
`MSYS_PATH_TRANSFORM=3DAUTO' would activate the mode where a special=20
initial byte sequence would disable it for just the one argument,=20
(causing the initial signature byte sequence to be stripped away, with=20
the remainder of the argument left untouched by any transformation).

In the event that MSYS_PATH_TRANSFORM is not defined, then a default=20
behaviour would be adopted; IMO, that default should be equivalent to=20
`MSYS_PATH_TRANSFORM=3DAUTO'.

The second environment variable would identify the initial byte sequence=20
to be used to signify an argument which is to be exempt from the normal=20
path transformation behaviour, when `MSYS_PATH_TRANSFORM=3DAUTO' is in=20
effect; let's call it...

   MSYS_PATH_TRANSFORM_IGNORE=3Dkey

where `key' defines that initial signature byte sequence.

Again, if MSYS_PATH_TRANSFORM_IGNORE is not defined, a default `key'=20
value would be required; this could be the `?:' I suggested previously,=20
or any other suitable default agreed through further discussion on this=20
list.

A possible variation on the above: it may be possible to achieve similar=20
functionality with just one environment variable, by accepting a syntax=20
such as...

   MSYS_PATH_TRANSFORM=3D"AUTO;IGNORE=3Dkey"

(I'm not sure, but parsing that may actually be less expensive, than=20
requiring a second environment variable look-up; intuitively, I suspect=20
that this would be the case).

Any further thoughts?

Keith.

Brian Antao wrote:
> Hello,
> 
> What utilities do I need to download to be able to process and read man pages
> under Windows... ie is there an equivalent of the man command available in 
> the MinGW/msys distribution ?

A number of us just use the man command, though it requires building.

Source is in man-1.6-mingw-beta-1-src.tar.gz on the MinGW site.

First you'll need to install groff and it's dependencies. groff is available in
the mingwPORT section, groff-1.19.2-mingwPORT-1.tar.bz2.

-- 
John P. Clizbe                      You can't spell fiasco without SCO.
"what's the key to success?"        / "two words: good decisions."
"what's the key to good decisions?" /  "one word: experience."
"how do i get experience?"          / "two words: bad decisions."

"Just how do the residents of Haiku, Hawai'i hold conversations?"

Keith Marshall wrote:
> On Fri, 2008-01-11 at 18:11 +0100, Michael Kappert wrote:

Thanks for taking the time, and sorry for the late reply!

> My preferred solution would be to drop the automagic conversion
>> completely as it doesn't seem to work at all.
> 
> Oh, but it does! 

Ok - I was probably a little too quick off the mark.

> Earnie was the MSYS maintainer, and he proposed some possible features
> that might help to alleviate the problem:--
> 
> 1) Create an environment variable, which could be set to particular
> values, to control the behaviour of the transformation; that would allow
> you to disable the transformation, as you suggest.
> 
> 2) Prefix some specific signature to the argument string itself, which
> MSYS would remove, recognising it as an instruction to leave the string
> otherwise unmodified.
> 
> Of these two, I personally prefer the second, 

... and we prefer the first, I think.
CLISP runs on large number of system. Our main concern here is to
keep the complexity of ./configure down to a minimum. With option 1),
we would probably just add a hint for building with mingw to the README
(even though I hear there are people who don't read READMEs - boo.)

With the second option, we're forced to further spcecial-case configure for
mingw. The prefix would need to go into a string containing
a pure lisp expression, without a good reason obvious to the average
lisp or mingw user.

> However, look what happens, if you make a very small
> alteration to that string:--
> 
>    $ ./test "?:(../src) (foo::bar)"
>    test: ?:(../src) (foo::bar)
>    ======^^===^=========^^====
> 
> Close to what you want, but not quite there.

Ok! Following your example I found a way to modify the lisp expr
such that it's still valid but does not get replaced. So at least
we have a workaround by manually editing the Makefile.

> Additionally, while I've suggested `?:' as the signature tag, the user
> population should be given an opportunity to discuss that, and to agree
> on any final preferred sequence.

CLISP's vote goes to the environment variable solution (or implement both :^))
  - but unfortunately I can't offer any help. Nevertheless I hope it will still
be possible to build clisp OOTB on mingw in the future...

Regards
Michael