Need help working around auto-import

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Need help working around auto-import

Carl-2-3
Hi, I am developing a GPL program for linux which id like to port to
windows. The linux version has a core binary, and plugins compiled
into .so's which link to many of the functions within the core binary.
Because of the magic of ld, everything works. Under windows I had a
problem that I couldn't work out a way to link the .dll's to the main
.exe without making a serious mess. My end solution was to compile
most of the core binary into a .dll. The core executable could then
access all of the functionality from the core dll, and the plugins
could also use the core dll. This almost works, everything compiles
and runs, but I have a run time crash which I'm having great
difficulty tracking down. I don't have the windows version of gdb to
help me, but after some printf debugging im 99% sure that the crash is
caused when I
call a member function of a class.

Im sorry to have to elaborate so much, but the program basically works
like this. There is a class called a client which manages all the core
responsibilities. When the plugins are loaded, they are given a
pointer to the client they are to interact with, and from that pointer
they are able to call any public member of client. The problem is that
this seems to cause a crash.

My only real hint so far is the warning message
Info: resolving vtable for GSMessageListby linking to
__imp___ZTV13GSMessageList (auto-import)
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/bin/ld:
warning: auto-importing has been activated without
--enable-auto-import specified on the command line.
This should work unless it involves constant data structures
referencing symbols from auto-imported DLLs.

As it happens, by passing a class pointer to a separate .dll I do rely
on "constant data structures referencing symbols from auto-imported
DLLs", as Im assuming a class is such a data structure the warning is
referring to.

Is this probably whats causing my crash? and can anyone suggest a work
around? I've been looking for documentation on auto-import, and whilst
there is some, its nothing hearty. ive also enabled
--enable-runtime-pseudo-reloc hoping it might help but with no luck.

Thanks in advance.

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) HTML/MIME encoded mail
3) Improper quoting
4) Improper trimming
Reply | Threaded
Open this post in threaded view
|

Re: Need help working around auto-import

Marc Vaillant


On Jan 27, 2009, at 10:38, Carl <[hidden email]> wrote:

> Hi, I am developing a GPL program for linux which id like to port to
> windows. The linux version has a core binary, and plugins compiled
> into .so's which link to many of the functions within the core binary.
> Because of the magic of ld, everything works. Under windows I had a
> problem that I couldn't work out a way to link the .dll's to the main
> .exe without making a serious mess.

What magic are u referring to?  What's different abt windows dlls that  
did not let u do what u were doing on linux?

Marc

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) HTML/MIME encoded mail
3) Improper quoting
4) Improper trimming
Reply | Threaded
Open this post in threaded view
|

Re: Need help working around auto-import

Carl-2-3
On Wed, Jan 28, 2009 at 10:12 AM, Marc Vaillant <[hidden email]> wrote:

>
>
> On Jan 27, 2009, at 10:38, Carl <[hidden email]> wrote:
>
>> Hi, I am developing a GPL program for linux which id like to port to
>> windows. The linux version has a core binary, and plugins compiled
>> into .so's which link to many of the functions within the core binary.
>> Because of the magic of ld, everything works. Under windows I had a
>> problem that I couldn't work out a way to link the .dll's to the main
>> .exe without making a serious mess.
>
> What magic are u referring to?  What's different abt windows dlls that
> did not let u do what u were doing on linux?
>
> Marc
>
A lot it seems. The most important difference is that a .dll must have
all references defined at run time, whilst a .so does not. when a .so
is loaded ld will resolve all dependencies of the .so at run time, a
.dll must know where to look for its dependencies at run time. This is
especially important when using c++, it would be an absolute pain to
export/import a class manually, with member functions and vtable etc.

Carl

> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>
> _______________________________________________
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.
>
> Most annoying abuses are:
> 1) Top posting
> 2) HTML/MIME encoded mail
> 3) Improper quoting
> 4) Improper trimming
>

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) HTML/MIME encoded mail
3) Improper quoting
4) Improper trimming
Reply | Threaded
Open this post in threaded view
|

Re: Need help working around auto-import

Marc Vaillant
On Wed, Jan 28, 2009 at 12:09:03PM +1100, Carl wrote:

> On Wed, Jan 28, 2009 at 10:12 AM, Marc Vaillant <[hidden email]> wrote:
> >
> >
> > On Jan 27, 2009, at 10:38, Carl <[hidden email]> wrote:
> >
> >> Hi, I am developing a GPL program for linux which id like to port to
> >> windows. The linux version has a core binary, and plugins compiled
> >> into .so's which link to many of the functions within the core binary.
> >> Because of the magic of ld, everything works. Under windows I had a
> >> problem that I couldn't work out a way to link the .dll's to the main
> >> .exe without making a serious mess.
> >
> > What magic are u referring to?  What's different abt windows dlls that
> > did not let u do what u were doing on linux?
> >
> > Marc
> >
> A lot it seems. The most important difference is that a .dll must have
> all references defined at run time, whilst a .so does not. when a .so
> is loaded ld will resolve all dependencies of the .so at run time, a
> .dll must know where to look for its dependencies at run time. This is
> especially important when using c++, it would be an absolute pain to
> export/import a class manually, with member functions and vtable etc.
I'm sorry I don't quite understand what you are trying to say here?
Attached is an example of a client program which depends on a dll
libInterface.dll, and this dll depends on another called libBackend.dll.
The client program and the dlls compile and are linked exactly the same
way for my OS X g++ + ld as with my mingw-g++ + ld.  Can you modify to
illustrate what you mean?

mingw:

$ i386-mingw32-g++ -o libBackend.dll Backend.cpp -shared
$ i386-mingw32-g++ -o libInterface.dll Interface.cpp -shared
$ i386-mingw32-g++ -o client.exe client.cpp -lInterface -L.
$ wine client.exe
called interface member func
called backend member func

osx:

$ g++ -o libBackend.dylib Backend.cpp -dynamiclib
$ g++ -o libInterface.dylib Interface.cpp -dynamiclib -lBackend -L.
$ g++ -o client client.cpp -lInterface -L.
$ ./client
called interface member func
called backend member func

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) HTML/MIME encoded mail
3) Improper quoting
4) Improper trimming

Backend.cpp (136 bytes) Download Attachment
Backend.h (59 bytes) Download Attachment
Interface.cpp (195 bytes) Download Attachment
Interface.h (59 bytes) Download Attachment
client.cpp (75 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Need help working around auto-import

Marc Vaillant
On Tue, Jan 27, 2009 at 10:36:05PM -0500, Marc Vaillant wrote:

> On Wed, Jan 28, 2009 at 12:09:03PM +1100, Carl wrote:
> > On Wed, Jan 28, 2009 at 10:12 AM, Marc Vaillant <[hidden email]> wrote:
> > >
> > >
> > > On Jan 27, 2009, at 10:38, Carl <[hidden email]> wrote:
> > >
> > >> Hi, I am developing a GPL program for linux which id like to port to
> > >> windows. The linux version has a core binary, and plugins compiled
> > >> into .so's which link to many of the functions within the core binary.
> > >> Because of the magic of ld, everything works. Under windows I had a
> > >> problem that I couldn't work out a way to link the .dll's to the main
> > >> .exe without making a serious mess.
> > >
> > > What magic are u referring to?  What's different abt windows dlls that
> > > did not let u do what u were doing on linux?
> > >
> > > Marc
> > >
> > A lot it seems. The most important difference is that a .dll must have
> > all references defined at run time, whilst a .so does not. when a .so
> > is loaded ld will resolve all dependencies of the .so at run time, a
> > .dll must know where to look for its dependencies at run time. This is
> > especially important when using c++, it would be an absolute pain to
> > export/import a class manually, with member functions and vtable etc.
>
> I'm sorry I don't quite understand what you are trying to say here?
> Attached is an example of a client program which depends on a dll
> libInterface.dll, and this dll depends on another called libBackend.dll.
> The client program and the dlls compile and are linked exactly the same
> way for my OS X g++ + ld as with my mingw-g++ + ld.  Can you modify to
> illustrate what you mean?
>
> mingw:
>
> $ i386-mingw32-g++ -o libBackend.dll Backend.cpp -shared
> $ i386-mingw32-g++ -o libInterface.dll Interface.cpp -shared

correction here, pasted the wrong command.  Should be
$ i386-mingw32-g++ -o libInterface.dll Interface.cpp -shared -lBackend -L.

> $ i386-mingw32-g++ -o client.exe client.cpp -lInterface -L.
> $ wine client.exe
> called interface member func
> called backend member func
>
> osx:
>
> $ g++ -o libBackend.dylib Backend.cpp -dynamiclib
> $ g++ -o libInterface.dylib Interface.cpp -dynamiclib -lBackend -L.
> $ g++ -o client client.cpp -lInterface -L.
> $ ./client
> called interface member func
> called backend member func

> #include "Backend.h"
> #include <iostream>
>
> void Backend::memberFunc()
> {
>   std::cout<<"called backend member func"<<std::endl;
> }
>

> class Backend
> {
> public:
> void memberFunc();
> };
>

> #include "Interface.h"
> #include "Backend.h"
> #include <iostream>
>
> void Interface::memberFunc()
> {
>   std::cout<<"called interface member func"<<std::endl;
>   Backend b;
>   b.memberFunc();
> }

> class Interface
> {
> public:
> void memberFunc();
> };

> #include "Interface.h"
>
> main()
> {
>   Interface c;
>   c.memberFunc();
> }

> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>
> _______________________________________________
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.
>
> Most annoying abuses are:
> 1) Top posting
> 2) HTML/MIME encoded mail
> 3) Improper quoting
> 4) Improper trimming

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) HTML/MIME encoded mail
3) Improper quoting
4) Improper trimming
Reply | Threaded
Open this post in threaded view
|

Re: Need help working around auto-import

Carl-2-3
On Wed, Jan 28, 2009 at 2:51 PM, Marc Vaillant <[hidden email]> wrote:

> On Tue, Jan 27, 2009 at 10:36:05PM -0500, Marc Vaillant wrote:
>> On Wed, Jan 28, 2009 at 12:09:03PM +1100, Carl wrote:
>> > On Wed, Jan 28, 2009 at 10:12 AM, Marc Vaillant <[hidden email]> wrote:
>> > >
>> > >
>> > > On Jan 27, 2009, at 10:38, Carl <[hidden email]> wrote:
>> > >
>> > >> Hi, I am developing a GPL program for linux which id like to port to
>> > >> windows. The linux version has a core binary, and plugins compiled
>> > >> into .so's which link to many of the functions within the core binary.
>> > >> Because of the magic of ld, everything works. Under windows I had a
>> > >> problem that I couldn't work out a way to link the .dll's to the main
>> > >> .exe without making a serious mess.
>> > >
>> > > What magic are u referring to?  What's different abt windows dlls that
>> > > did not let u do what u were doing on linux?
>> > >
>> > > Marc
>> > >
>> > A lot it seems. The most important difference is that a .dll must have
>> > all references defined at run time, whilst a .so does not. when a .so
>> > is loaded ld will resolve all dependencies of the .so at run time, a
>> > .dll must know where to look for its dependencies at run time. This is
>> > especially important when using c++, it would be an absolute pain to
>> > export/import a class manually, with member functions and vtable etc.
>>
>> I'm sorry I don't quite understand what you are trying to say here?
>> Attached is an example of a client program which depends on a dll
>> libInterface.dll, and this dll depends on another called libBackend.dll.
>> The client program and the dlls compile and are linked exactly the same
>> way for my OS X g++ + ld as with my mingw-g++ + ld.  Can you modify to
>> illustrate what you mean?
>>
Here is a modified version which does something similar to what mine
does. I could not reproduce the crash, or for that matter work out how
to invoke the auto-import warning.

The difference between windows and unix can be seen here, as with
mingw we were required to tell the compiler where to find the
libraries at compile time. Under linux ld will resolve any
dependencies at run time.

Ive also included a make file to make life a bit easier.

> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>
> _______________________________________________
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.
>
> Most annoying abuses are:
> 1) Top posting
> 2) HTML/MIME encoded mail
> 3) Improper quoting
> 4) Improper trimming
>

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) HTML/MIME encoded mail
3) Improper quoting
4) Improper trimming

testdll.zip (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Need help working around auto-import

Tor Lillqvist
In reply to this post by Marc Vaillant
>> > What magic are u referring to?  What's different abt windows dlls that
>> > did not let u do what u were doing on linux?

>> A lot it seems. The most important difference is that a .dll must have
>> all references defined at run time, whilst a .so does not.

> I'm sorry I don't quite understand what you are trying to say here?

Try to compile this into a shared library on Linux (or MacOSX), and on Windows:

== cut here==
extern void fun_in_main ();

void
fun_in_shared_library (void)
{
  fun_in_main ();
}
== cut here==

and then this into a main program that links to the shared library
built from the above file:

== cut here==
extern void fun_in_shared_library (void);

void
fun_in_main (void)
{
}

int
main (int argc, char **argv)
{
  fun_in_shared_library ();

  return 0;
}
== cut here==

You notice any difference between Windows and Linux? (I don't know how
MacOSX behaves here).

> Attached is an example of a client program which depends on a dll
> libInterface.dll, and this dll depends on another called libBackend.dll.
> The client program and the dlls compile and are linked exactly the same
> way for my OS X g++ + ld as with my mingw-g++ + ld.

Oh please, if you are going to post examples, make them in plain C and
minimal. Using C++ might well bring in lots of complications of its
own. Although in this case it apparently doesn't, but in general C++
is a bad language to demonstrate simple features of the operating
system, object file or executable file format.

--tml

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) HTML/MIME encoded mail
3) Improper quoting
4) Improper trimming
Reply | Threaded
Open this post in threaded view
|

Re: Need help working around auto-import

Carl-2-3
I found the problem. Basically assumed that FreeLibrary returned 0 on
success, but returns non-zero. sorry everyone.

> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>
> _______________________________________________
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.
>
> Most annoying abuses are:
> 1) Top posting
> 2) HTML/MIME encoded mail
> 3) Improper quoting
> 4) Improper trimming
>

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) HTML/MIME encoded mail
3) Improper quoting
4) Improper trimming
Reply | Threaded
Open this post in threaded view
|

Re: Need help working around auto-import

Marc Vaillant
In reply to this post by Tor Lillqvist
On Wed, Jan 28, 2009 at 08:44:32AM +0200, Tor Lillqvist wrote:

> >> > What magic are u referring to?  What's different abt windows dlls that
> >> > did not let u do what u were doing on linux?
>
> >> A lot it seems. The most important difference is that a .dll must have
> >> all references defined at run time, whilst a .so does not.
>
> > I'm sorry I don't quite understand what you are trying to say here?
>
> Try to compile this into a shared library on Linux (or MacOSX), and on Windows:
>
> == cut here==
> extern void fun_in_main ();
>
> void
> fun_in_shared_library (void)
> {
>   fun_in_main ();
> }
> == cut here==
>
> and then this into a main program that links to the shared library
> built from the above file:
>
> == cut here==
> extern void fun_in_shared_library (void);
>
> void
> fun_in_main (void)
> {
> }
>
> int
> main (int argc, char **argv)
> {
>   fun_in_shared_library ();
>
>   return 0;
> }
> == cut here==
>
> You notice any difference between Windows and Linux? (I don't know how
> MacOSX behaves here).

Ok, thanks.  Windows and OS X actually behave the same here.  Can't
build the shared lib.  Works in Linux.  

Circular dependencies are a "bad smell", but here's the solution for
windows.  

shared.c
-----

#include <windows.h>
#include <stdio.h>

typedef void(*main_fun)(void);

void fun_in_shared_library (void)
{
  HINSTANCE lib;
  main_fun main_fun_ptr;

  lib = GetModuleHandle("main.exe");
  if(lib != NULL)
  {
        main_fun_ptr = (main_fun) GetProcAddress(lib, "fun_in_main");

        if(main_fun_ptr != NULL)
          main_fun_ptr();
  }
}
------

main.c
------

#include <stdio.h>

extern void fun_in_shared_library (void);

void fun_in_main (void)
{
  printf("fun_in_main called\n");

}

int main (int argc, char **argv)
{
  fun_in_shared_library ();

  return 0;
}
-----


$ i386-mingw32-gcc -o libShared.dll shared.c -shared
$ i386-mingw32-gcc -o main.exe main.c -lShared -L.  -Wl,--export-all-symbols

$ wine main.exe
fun_in_main called

>
> > Attached is an example of a client program which depends on a dll
> > libInterface.dll, and this dll depends on another called libBackend.dll.
> > The client program and the dlls compile and are linked exactly the same
> > way for my OS X g++ + ld as with my mingw-g++ + ld.
>
> Oh please, if you are going to post examples, make them in plain C and
> minimal. Using C++ might well bring in lots of complications of its
> own.

Exactly.  There are plenty of C++ linking issues that aren't issues in
C.  As I didn't know what the poster was referring to--and he said that
he was using C++--I didn't know whether or not he was just up against a
C++ specific issue.  In fact the solution I gave above would really only
manageable in C++ if you adhere to the C linkage factory method +
virtual function only protocol for exported classes.

Marc

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) HTML/MIME encoded mail
3) Improper quoting
4) Improper trimming
Reply | Threaded
Open this post in threaded view
|

Re: Need help working around auto-import

Tuomo Latto
In reply to this post by Carl-2-3
Carl wrote:
> I found the problem. Basically assumed that FreeLibrary returned 0 on
> success, but returns non-zero. sorry everyone.
[...]
>> Most annoying abuses are:
>> 1) Top posting
>> 2) HTML/MIME encoded mail
>> 3) Improper quoting
>> 4) Improper trimming

Read these?

Not related, but I'd add
5) Thread hi-jacking


--
Tuomo

... 'A man who speaks Finnish can't be evil'   -- Homer Simpson


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) HTML/MIME encoded mail
3) Improper quoting
4) Improper trimming