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

On Tue, 30 Oct 2007 21:34:20 +0000, Thomas D'Silva wrote:

>
> I apologize for posting the previous code without compiling. I modified t=
he code
> to use a static private data member and still have the same problem. The
> following code compiles with gcc version 4.1.1 in mingw.
>


> I thought since the dll shares the same stack and heap as the calling pro=
cess,
> after modifying a static data member of an object passed by reference to =
the dll
> function, the object's static data should remain modified in the calling
> process. I would appreciate any help with this issue.
>
> Thanks,
> Thomas
>
>

It will work if you link to TestObject.cpp compiled as a DLL.

_________________________________________________________________
Climb to the top of the charts!=A0 Play Star Shuffle:=A0 the word scramble =
challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_oc=
t=

On Tue, 2007-10-30 at 21:34 +0000, Thomas D\'Silva wrote:
> I apologize for posting the previous code without compiling. I modified the code
>  to use a static private data member and still have the same problem.

<snip>

> I thought since the dll shares the same stack and heap as the calling process,
> after modifying a static data member of an object passed by reference to the dll
> function, the object's static data should remain modified in the calling
> process. I would appreciate any help with this issue.

I am not a c++ person, so I this may well be a wild goose chase, but I
think this (not very) helpful link might be of interest.
http://www.thescripts.com/forum/thread63240.html

Regards,
James.

Thomas D\'Silva wrote:

> I thought since the dll shares the same stack and heap as the calling process,
> after modifying a static data member of an object passed by reference to the dll
> function, the object's static data should remain modified in the calling
> process. I would appreciate any help with this issue.

That's not how static members work.  They aren't on the stack nor the
heap, they're in the .bss section.  You've arguably violated the ODR
rule here because there is one instance of TestObject::b in the DLL and
one instance in the .exe -- the fact that the library is loaded
dynamically at runtime and not linked means that there is no way for the
compiler to have any clue what you're trying to do.  Remember that
static members are not tied to any particular instance of any object,
there is only one static member shared by all instances of the class, so
just because you are setting b through some particular instance t of
TestObject doesn't mean anything.

Brian

On Oct 30, 2007, at 2:34 PM, Thomas D'Silva wrote:
>
> I thought since the dll shares the same stack and heap as the  
> calling process,
> after modifying a static data member of an object passed by  
> reference to the dll
> function, the object's static data should remain modified in the  
> calling
> process. I would appreciate any help with this issue.
>

i think the problem is that you basically have the same class defined  
in two different places.  once in the exe and once in the dll.  what i  
think is happening is that the static is present in both.  so while b  
might be 1 in the dll, the exe has a different address for b, whereas  
with the non-static member, the address is being passed in.

i would guess this to be the intentional operation as opposed to an  
actual bug in the compiler and suggest working around the behavior in  
your code.


Brandon Sneed
OQO, Inc.
br...@oq...

I apologize for posting the previous code without compiling. I modified the code
 to use a static private data member and still have the same problem. The
following code compiles with gcc version 4.1.1 in mingw.

//TestObject.h
#include <iostream>
using namespace std;

class TestObject {
  private:
    int a;
    static int b;
  public:
    TestObject();
    void setA(int);
    void setB(int);
    int print();
};

//TestObject.cpp
#include "TestObject.h"

int TestObject::b=0;

TestObject::TestObject()
{
setA(0);
setB(0);
}

void TestObject::setA(int A)
{
a=A;
}

void TestObject::setB(int B)
{
b=B;
cout<<"Within TestObject"<<endl;
print();
}

int TestObject::print()
{
  cout<<"a "<<a<<endl;
  cout<<"b "<<b<<endl;  
}

//dll.h
#include "TestObject.h"

#ifdef BUILD_DLL
/* DLL export */
#define EXPORT __declspec(dllexport)
#else
/* EXE import */
#define EXPORT __declspec(dllimport)
#endif

EXPORT void hello(TestObject&)

//dll.cpp
#include <stdio.h>
#include "dll.h"

extern "C" EXPORT void doSomething(TestObject& t) {
	t.setA(1);
	t.setB(1);
}


//main.cpp
#include <windows.h>
#include <stdio.h>	
#include "TestObject.h"

int main () {
	
	/*Typedef the hello function*/
	typedef void (*pfunc)(TestObject&);
	
	/*Windows handle*/
	HMODULE hdll;
	
	/*A pointer to a function*/
	//pfunc hello;
	pfunc doSomething;	
	/*LoadLibrary*/
	hdll = LoadLibrary("test.dll");
	
	/*GetProcAddress*/
	doSomething = (pfunc)GetProcAddress(hdll, "doSomething");
	if (doSomething) {
	
	/*Call the function*/
	TestObject t;
	cout<<"Initial\n"<<endl;
	t.print();
	doSomething(t);
	cout<<"After doSomething\n"<<endl;
	t.print();

}

THE OUTPUT OF main:
Initial

a 0
b 0
Within TestObject //Here it has modified the static member b
a 1
b 1
After doSomething // Here the static member is zero again

a 1
b 0

I thought since the dll shares the same stack and heap as the calling process,
after modifying a static data member of an object passed by reference to the dll
function, the object's static data should remain modified in the calling
process. I would appreciate any help with this issue.

Thanks,
Thomas

On Tue, 2007-10-30 at 15:02 +0100, Michael Gerdau wrote:
> > I browsed around the MinGW cvs repository and it seems that the
> > w32api headers and other data are part of Cygwin now and not
> > MinGW.  Is that accurate?

No.  They are a component of *both*, and yes...

> Cygwin and MinGW do share w32api either from the very start or at
> least for a very long time.
> 
> > If so, I should probably direct my changes there.
> 
> I suppose it would work either way. 

No, you should not.  The primary responsibility for maintaining w32api
rests with the MinGW project, not with Cygwin.  As Greg has already
stated, you should post your patches on our tracker.

Do note that your information sources must be truly public; (MSDN is
acceptable).  Patches will not be accepted, if you copy data from any
Microsoft SDK, or rely on experiments which cannot be reproduced with an
Open Source compiler, such as MinGW itself.

Regards,
Keith.

On Tue, 30 Oct 2007 18:37:15 +0000, Thomas D'Silva wrote:
>
> Hi,
>
> I am trying to use a function in a dll that was built with gcc/mingw to m=
odify
> static data of an object that is passed to the function by reference. Aft=
er the
> function in the dll is executed the changes to the static data are not
> reflected, however changes to the private/public data members of the obje=
ct are
> reflected. Is there a way have changes to the static data of an object
> reflected? For example:
>
> //TestObject.h
> Class TestObject {
> private:
> int a;
> public:
> TestObject();
> void setA(int);
> void setB(int);
> int getA();
> int getB();
> }
>

Note that your class does not have a member called b;

> void TestObject::setB(int B)
> {
> static int b;
> b=3DB;
> }

setB stores the value of B in b, which is a static local variable
in setB, and not a static member of B;
>
>
> int TestObject::getB()
> {
> return b; // therefore this will not compile
> }


_________________________________________________________________
Windows Live Hotmail and Microsoft Office Outlook =96 together at last. =A0=
Get it now.
http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=3DCL10062=
6971033=

Hi,

I am trying to use a function in a dll that was built with gcc/mingw to modify
static data of an object that is passed to the function by reference. After the
function in the dll is executed the changes to the static data are not
reflected, however changes to the private/public data members of the object are
reflected. Is there a way have changes to the static data of an object
reflected? For example:

//TestObject.h
Class TestObject {
  private:
    int a;
  public:
    TestObject();
    void setA(int);
    void setB(int);
    int getA();
    int getB();
}

//TestObject.cpp
TestObject::TestObject()
{
setA(0);
setB(0);
}

void TestObject::setA(int A)
{
a=A;
}

void TestObject::setB(int B)
{
static int b;
b=B;
}

int TestObject::getA()
{
  return a;
}


int TestObject::getB()
{
  return b;
}
// dll.h
#ifdef BUILD_DLL
/* DLL export */
#define EXPORT __declspec(dllexport)
#else
/* EXE import */
#define EXPORT __declspec(dllimport)
#endif
#include TestObject.h

EXPORT void doSomething(TestObject& t);

// dll.cpp
void doSomething (TestObject& t) 
{
t.setA(1);
t.setB(1);
}

// main.cpp
int main(int argc, char* argv[])
{
void (* pFunc)(TestObject&);
	
/*LoadLibrary*/
HANDLE  hdll = LoadLibrary("test.dll");
	
/*GetProcAddress*/
pFunc= GetProcAddress(hdll, "doSomething");

TestObject temp;
doSomething(temp);
//after dll function call temp.a is 1, but temp.b is still 0

return 0;
}

On 2007-10-30 13:48Z, Kevin Conaway wrote:
> 
> I browsed around the MinGW cvs repository and it seems that the w32api
> headers and other data are part of Cygwin now and not MinGW.  Is that
> accurate?
> 
> If so, I should probably direct my changes there.

sources.redhat.com kindly provides the cvs facility for
both w32api and mingw-runtime, but that doesn't mean those
packages aren't part of MinGW. It remains appropriate to
use the MinGW patch tracker.

> I browsed around the MinGW cvs repository and it seems that the w32api
> headers and other data are part of Cygwin now and not MinGW.  Is that
> accurate?

Cygwin and MinGW do share w32api either from the very start or at least
for a very long time.

> If so, I should probably direct my changes there.

I suppose it would work either way. However I have no experience with
providing patches for cygwin.

Best,
Michael
=2D-=20
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mg...@ti...
 GPG-keys available on request or at public keyserver

Thanks for getting back to me Michael.

I browsed around the MinGW cvs repository and it seems that the w32api
headers and other data are part of Cygwin now and not MinGW.  Is that
accurate?

If so, I should probably direct my changes there.

Thanks,

Kevin

On 10/30/07, Michael Gerdau <mg...@ti...> wrote:
>
> > Are the CryptProtectData / CryptUnprotectData DPAPI methods not
> > supported by MinGW?  They seem to be missing from wincrypt.h
>
> That is correct. And they are not the only missing definitions.
>
> > Any explanation or workaround would be helpful.
>
> Presumably there has been noone using MinGW being in need of these
> functions yet or at least noone being willing to check the M$DN site
> and add the appropriate functions to MinGW.
>
> You may want to go to
> http://msdn2.microsoft.com/en-us/library/aa380252.aspx
> and copy whatever is missing and needed by you into your local wincrypt.h
> (and whatever other header files might be involved or even missing; e.g.
> there is no cspdk.h at all).
>
> You then could create a patch to be applied to the w32api package (either
> cvs or at least the latest released version 3.10).
>
> If you need help in creating such a patch I'd be happy to help.
>
> Best,
> Michael
> --
> Vote against SPAM - see http://www.politik-digital.de/spam/
> Michael Gerdau       email: mg...@ti...
> GPG-keys available on request or at public keyserver
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>
>
>

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

>  Would it also be appropriate to `lose' this
> msysCORE-1.0.11-2007.01.19-1.tar.bz2 tarball?
>

No (I was confused); see below.

> Maybe it would be useful, if somebody could indicate on the MinGWiki,
> just which packages need to be downloaded, and how/where to unpack them,
> to get a working MSYS-1.0.11 Base System up and running.  Mine has just
> sort of evolved over time, and I'm not sure now, how I've arrived at my
> present set up.
>

Well, obviously mine is (or used to be) an ever evolving piece of work.

msysCORE (first and foremost)
MSYS(upgraded msys-1.0.dll, mount.exe and ps.exe).
bzip2 (msysCORE)
bash (msysCORE)
coreutils
diff (msysCORE)
find (msysCORE)
gawk (msysCORE)
grep (msysCORE)
less (msysCORE)
m4   (msysCORE)
make
makeinfo (msysCORE)
sed  (msysCORE)
rxvt (msysCORE)
tar
texinfo

I may have forgotten something.  Please correct or ask if you think I did.

Earnie

> Are the CryptProtectData / CryptUnprotectData DPAPI methods not
> supported by MinGW?  They seem to be missing from wincrypt.h

That is correct. And they are not the only missing definitions.

> Any explanation or workaround would be helpful.

Presumably there has been noone using MinGW being in need of these
functions yet or at least noone being willing to check the M$DN site
and add the appropriate functions to MinGW.

You may want to go to
http://msdn2.microsoft.com/en-us/library/aa380252.aspx
and copy whatever is missing and needed by you into your local wincrypt.h
(and whatever other header files might be involved or even missing; e.g.
there is no cspdk.h at all).

You then could create a patch to be applied to the w32api package (either
cvs or at least the latest released version 3.10).

If you need help in creating such a patch I'd be happy to help.

Best,
Michael
=2D-=20
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mg...@ti...
 GPG-keys available on request or at public keyserver

Folks: thank you all for replying. Mystery's solved. John and Tim solved both
my ridiculous problems. I'm wcouting up a storm in here.

-static didn't work, but adding a STLport-specific define tag with an
installation that included the static libs prevents the need to include the
DLL.

cd /c/STLport/build/lib
make -f gcc.mak depend
make -f gcc.mak install-release-static
make -f gcc.mak install-dbg-static
make -f gcc.mak install-stldbg-static

...

g++ test.cpp -o test -Wall -mthreads -I C:\STLport\stlport -L C:\STLport\lib
-lstlport.5.1 -D _STLP_USE_STATIC_LIB


John Brown wrote:
> 
> OK. I didn't realize that the lack of knowledge was as bad as that. You
> can get a
> summary of gcc command line options like this:
> gcc -v --help> gcchelp.txt 2>&1 
> 

Yeah, I was confused to begin with, and since you folks were copying my
usage of -ID and -LD, I thought it was the right thing to do after all.
Outside of basic testing for curiosity's sake, until yesterday I had never
used GCC directly at all, always just relying on the IDE's include/library
sections. I didn't know the first thing about any of GCC's flags except -o
and -Wall.

I guess I assumed that I would get a directory-doesn't-exist error (my DVD
drive doesn't have a STLport directory), and I didn't realize I was using
the D drive because based on some usage I'd seen I thought that -LD was for
linking to library directories and -L was for linking to the libraries
themselves. And, I kind of expected for there to be a space between the
command and the start of the drive letter, the way people usually put a
space between -o and the exe filename. I've generally always used MinGW, but
I've used it just like I would any other IDE-combo-compiler, not from the
command line.


Tim Teulings wrote:
> 
> Havn't tested it but "using std" should be enough? 
> 

using namespace std? Sure, doesn't matter. I just prefer to tabulate exactly
what features I'm using.


Tim Teulings wrote:
> 
> Please don't use "\n" for line formatting in output streams - especially
> not
> under Windows/DOS. Please use std::endl instead. Good chance that this
> does
> correctly handle new line character sequences and internal buffering.
> 

Thanks -- you're completely correct. It normally never matters because I'm
just outputting ASCII. I've since learned that it's a classic problem,
outputting strings with wide characters on a traditional console, even with
wcout.

I'm done. Thank you all for helping me overcome my problems, which were, in
order:

-Using an incorrect version of the software because I clicked on the first
Google search result instead of the third and went to the old, no longer
updated official site.
-Having next to no knowledge of GCC syntax and using the incorrect drive
letter, making all my tests invalid.
-Not having known the practical difference between std::endl and '\n' for
Unicode.

I ended up spending countless trying a ton of different build configurations
and reading old and generally misleading info on the net. Pretty severe
penance for my deficiencies in GCC flags and std::endl knowledge, I think.
-- 
View this message in context: http://www.nabble.com/Building-STLport-on-MinGW-tf4699301.html#a13483163
Sent from the MinGW - User mailing list archive at Nabble.com.

Are the CryptProtectData / CryptUnprotectData DPAPI methods not
supported by MinGW?  They seem to be missing from wincrypt.h

Any explanation or workaround would be helpful.

Thanks,

On Oct 29, 2007, at 5:50 PM, Keith Marshall wrote:

> On Mon, 2007-10-29 at 17:20 -0700, Brandon Sneed wrote:
>> i read on the gdb lists recently that mingw support is greatly
>> improving.  i managed to build the nightly from source with no
>> modifications and it seems to be working fine.  one thing to note is
>> that the "attach" command now works properly as opposed to the  
>> problem
>> with gdb 6.6 on the mingw downloads pages.
>>
>> i've made it available here if anyone is interested in giving it a
>> whirl.  its just the gdb exec rather than a proper package.
>>
>> http://www.redf.net/gdb.6.7.50_20071023.zip
>
> Interesting; thanks for posting this information.  I'll try to find  
> time
> to have a look tomorrow.
>

I should also mention that i've only tested it against the 4.2.1-dw2  
build of GCC.  I have yet to try the sjlj build, but it's on my to-do  
list.  I know GDB 6.6 on the mingw project pages seemed to have  
trouble with the sjlj GCC.  If anyone does happen to try that out,  
please let me know.


>> ps.  sorry for hijacking that other thread, it wasn't intentional.
>
> And thanks for reposting.  Apology accepted.  I know you've been  
> around
> long enough to know better; I guess you were having an absent-minded,
> (a.k.a. senior) moment.
>

i don't know what the heck i was thinking. :S


Brandon Sneed
OQO, Inc.
br...@oq...

On Mon, 2007-10-29 at 17:20 -0700, Brandon Sneed wrote:
> i read on the gdb lists recently that mingw support is greatly  
> improving.  i managed to build the nightly from source with no  
> modifications and it seems to be working fine.  one thing to note is  
> that the "attach" command now works properly as opposed to the problem  
> with gdb 6.6 on the mingw downloads pages.
> 
> i've made it available here if anyone is interested in giving it a  
> whirl.  its just the gdb exec rather than a proper package.
> 
> http://www.redf.net/gdb.6.7.50_20071023.zip

Interesting; thanks for posting this information.  I'll try to find time
to have a look tomorrow.

> ps.  sorry for hijacking that other thread, it wasn't intentional.

And thanks for reposting.  Apology accepted.  I know you've been around
long enough to know better; I guess you were having an absent-minded,
(a.k.a. senior) moment.

Regards,
Keith.

i read on the gdb lists recently that mingw support is greatly  
improving.  i managed to build the nightly from source with no  
modifications and it seems to be working fine.  one thing to note is  
that the "attach" command now works properly as opposed to the problem  
with gdb 6.6 on the mingw downloads pages.

i've made it available here if anyone is interested in giving it a  
whirl.  its just the gdb exec rather than a proper package.

http://www.redf.net/gdb.6.7.50_20071023.zip


ps.  sorry for hijacking that other thread, it wasn't intentional.


Brandon Sneed
OQO, Inc.
br...@oq...

>
> What on earth has this to do with "MinGW on Vista", which is the  
> thread
> to which you replied?  And note that this thread itself was improperly
> posted, having hijacked an original "gcc build problem" thread.

i'm such an idiot, terribly sorry about that.  it won't happen again.

On Mon, 2007-10-29 at 16:47 -0700, Brandon Sneed wrote:
> i read on the gdb lists recently that mingw support is greatly  
> improving.  i managed to build the nightly from source with no  
> modifications and it seems to be working fine.  one thing to note is  
> that the "attach" command now works properly as opposed to the problem  
> with gdb 6.6 on the mingw downloads pages.
> 
> i've made it available here if anyone is interested in giving it a  
> whirl.  its just the gdb exec rather than a proper package.
> 
> http://www.redf.net/gdb.6.7.50_20071023.zip

What on earth has this to do with "MinGW on Vista", which is the thread
to which you replied?  And note that this thread itself was improperly
posted, having hijacked an original "gcc build problem" thread.

When will you guys get it?  Your message is now buried in the bowels of
a completely unrelated thread, which is itself so buried, and therefore,
is effectively invisible.

Don't your mail clients have address books?  Why can't you use them?

When you introduce a new topic, please start a new thread; it is in
*your* own best interest.  Reader's using a threaded mail client, who
have killed the thread you hijacked, may never even see your message.

Regards,
Keith.

i read on the gdb lists recently that mingw support is greatly  
improving.  i managed to build the nightly from source with no  
modifications and it seems to be working fine.  one thing to note is  
that the "attach" command now works properly as opposed to the problem  
with gdb 6.6 on the mingw downloads pages.

i've made it available here if anyone is interested in giving it a  
whirl.  its just the gdb exec rather than a proper package.

http://www.redf.net/gdb.6.7.50_20071023.zip



Brandon Sneed
OQO, Inc.
br...@oq...

On Mon, 2007-10-29 at 07:39 -0400, Earnie Boyd wrote:
> Quoting Aaron Gray <an...@be...>:
> 
> >>>>> Am having problems knowing how to install MSYS 1.0.11.
> >>>>
> >>>> I ran MSYS-1.0.11-2004.04.03.exe
> >>>
> >>> Where can I download it from ? It does not seem to be on Sourceforge.
> >>
> >> It's located on the web site under snapshot IIRC. I use FTP myself

I can't see it in the `Snapshot' section; neither can I find any
reference to it in any package, either visible or hidden, within the SF
FRS for the project.  Reading Earnie's comment below, I guess that means
that it has been withdrawn from the download pages, as it has been
superseded.

> >> ftp://ftp.heanet.ie/mirrors/download.sourceforge.net/pub/sourceforge/m/mi/mingw
> >>
> >> You will also probably need the patched files in
> >> MSYS-1.0.11-20070729.tar.bz2
> >
> > Nice. Thanks.
> 
> Maybe nice; probably not.  The most current ``Snapshot'' can be found 
> at 
> http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82724 
> and release MSYS but in individual tar files.

Continuing the reorganisation, and rationalisation of the package
layout, I've moved some of the `Snapshot' entries to a new `Technology
Preview' release, within the `MSYS: Base System' package.  I haven't
finished the move yet, so for the short term, you may need to look in
both places.

> You should ignore msysCORE-1.0.11-2007.01.19-1.tar.bz2 but all the
> other binary files should be used.  The package pointed to on the
> mirror is old and improvements have been made.

I take this to mean that the MSYS-1.0.11-2004.04.03.exe file referred to
is no longer required, so there is no point in me resurrecting it, on
the download pages.  Would it also be appropriate to `lose' this
msysCORE-1.0.11-2007.01.19-1.tar.bz2 tarball?

Maybe it would be useful, if somebody could indicate on the MinGWiki,
just which packages need to be downloaded, and how/where to unpack them,
to get a working MSYS-1.0.11 Base System up and running.  Mine has just
sort of evolved over time, and I'm not sure now, how I've arrived at my
present set up.

Regards,
Keith.

Quoting Greg Chicares <gch...@sb...>:

> On 2007-10-28 21:03Z, Michael Gerdau wrote:
>>
>>>   Checking back, I always used (and stated I used) the Borland
>>> free compiler to determine constants values.  Is that
>>> still acceptable?
>>
>> I don't know this compiler. Whether or not using it as a source depends
>> on the licence which would have to be checked.
>
> On their download page
>  http://cc.codegear.com/free/cppbuilder
> you have to "register" to download anything. If it's the same thing
> I downloaded a few years ago, then I've read its license and it's
> not free as in freedom. And most of its headers bear ms copyrights:
>
> /cygdrive/c/Borland/BCC55/Include[0]$grep -il 'copyright.*microsoft' * |wc -l
> 683
> /cygdrive/c/Borland/BCC55/Include[0]$grep -iL 'copyright.*microsoft' * |wc -l
> 351

Which indicates that Borland obtained (read: purchased) the right to 
redistribute MS libraries.

Earnie

Quoting Aaron Gray <an...@be...>:

>>>>> Am having problems knowing how to install MSYS 1.0.11.
>>>>
>>>> I ran MSYS-1.0.11-2004.04.03.exe
>>>
>>> Where can I download it from ? It does not seem to be on Sourceforge.
>>
>> It's located on the web site under snapshot IIRC. I use FTP myself
>>
>> ftp://ftp.heanet.ie/mirrors/download.sourceforge.net/pub/sourceforge/m/mi/mingw
>>
>> You will also probably need the patched files in
>> MSYS-1.0.11-20070729.tar.bz2
>
> Nice. Thanks.
>

Maybe nice; probably not.  The most current ``Snapshot'' can be found 
at 
http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82724 
and release MSYS but in individual tar files.  You should ignore 
msysCORE-1.0.11-2007.01.19-1.tar.bz2 but all the other binary files 
should be used.  The package pointed to on the mirror is old and 
improvements have been made.

Earnie

>>>> Am having problems knowing how to install MSYS 1.0.11.
>>>
>>> I ran MSYS-1.0.11-2004.04.03.exe
>>
>> Where can I download it from ? It does not seem to be on Sourceforge.
>
> It's located on the web site under snapshot IIRC. I use FTP myself
>
> ftp://ftp.heanet.ie/mirrors/download.sourceforge.net/pub/sourceforge/m/mi/mingw
>
> You will also probably need the patched files in 
> MSYS-1.0.11-20070729.tar.bz2

Nice. Thanks.

Aaron