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

Luke Dunstan wrote, quoting Christopher Nelson:
>> Was anyone aware that MSYS is completely broken on Windows XP
>> 64bit edition?
>
> Yes we are aware, but I can't tell you much more.
>
> 
http://sourceforge.net/tracker/index.php?func=detail&aid=1200767&group_id=2435&atid=352435



There is also this:
http://sourceforge.net/tracker/index.php?func=detail&aid=1351029&group_id=2435&atid=302435

I'm not sure if it is relevant in this case, and I don't have a
64-bit system to investigate on.  The appropriately patched msys.bat
is in the CVS:
http://cvs.sourceforge.net/viewcvs.py/mingw/msys/dvlpr/bin/msys.bat?rev=1.14&view=log

You could try dowloading this, to replace your existing version,
(if you haven't already done so).  No promises, but it might help.

Regards,
Keith.

Yes we are aware, but I can't tell you much more.

http://sourceforge.net/tracker/index.php?func=detail&aid=1200767&group_id=2435&atid=352435


Luke

----- Original Message ----- 
From: "Christopher Nelson" <pa...@BB...>
To: <min...@li...>
Sent: Tuesday, February 28, 2006 12:40 AM
Subject: [Mingw-users] MSYS completely broken on XP64.


Was anyone aware that MSYS is completely broken on Windows XP 64bit
edition?  I'm using Intel 64-bit Extensions processor.  I get the
following error for all MSYS executables (but not mingw apps.)

C:\>rxvt
c:\msys\1.0\bin\rxvt.exe: *** fork: can't reserve memory for stack
0x480000 - 0x680000, Win32 error 0
      0 [main] rxvt 2548 sync_with_child: child 3912(0x278) died before
initialization with status code 0x1
    641 [main] rxvt 2548 sync_with_child: *** child state waiting for
longjmp
rxvt: can't fork
rxvt: aborting

------

If there is awareness of the problem, can anyone point me to a work
around?  I've tried compatability mode, and it just changes the error
message:

C:\>rxvt
AllocationBase 0x0, BaseAddress 0x715B0000, RegionSize 0x10000, State
0x10000
c:\msys\1.0\bin\rxvt.exe: *** Couldn't reserve space for cygwin's heap,
Win32 error 0

-------

Thanks in advance!

-={C}=-

Christian Wietholt writes:
 > Is it somehow possible to enable multi-textureing under mingw?

The problem is that the OpenGL headers on mingw (which in fact are
from the Mesa project) only define OpenGL 1.1 stuff, as that is what's
accessible in the base OpenGL API on Windows without using the
extension mechanism. (This is because of Microsoft boneheadness, they
want people to forget OpenGL and use Direct3D.) Read mingw's GL/gl.h,
it says:

/* Under Windows, we do not define OpenGL 1.2 & 1.3 functionality, since
   it is treated as extensions (defined in glext.h) */

 > Is it possible to use libmesa under mingw to get it working? 

You mean software rendering? That would be pretty pointless, as the
graphics card manufacturer -provided OpenGL drivers on Windows are *at
least* as featureful as the ones on Linux. Windows is after all a much
more widespread gaming platform. Multi-texturing is an old extension,
isn't it, that surely any graphics card worth using supports?

It's just that you need to access all the interesting stuff through
the OpenGL extension mechanism. This is described in lots of places on
the net. One easy way that I have used a bit myself is GLEW (the
OpenGL Extension Wrangler Library). See http://glew.sourceforge.net/

--tml

Dear All, 

I recently started using mingw to port my qt4 programs from Linux
to Windows. My collegues here at the hospital mainly use Windows, 
and I would be happy if the could use my apps. I was already 
successful with one of my programs. It uses OpenGL, which is an 
important requirement for my software. 

I am currently struggeling with a more elaborate program, which makes
use of multi-texturing in OpenGL. Unfortunately, gcc under mingw tells
me that the multi-texturing variables & function are undefined. Here is a 
snapshot of the compiler output. 

...
   glimageview.cpp: In member function `virtual void GLImageView::paintGL()':
   glimageview.cpp:138: error: `GL_TEXTURE0' undeclared (first use this function)
   glimageview.cpp:138: error: (Each undeclared identifier is reported only once for each function it appears in.)
   glimageview.cpp:138: error: `glActiveTexture' undeclared (first use this function)
   glimageview.cpp:142: error: `glMultiTexCoord2f' undeclared (first use this function)
...

Is it somehow possible to enable multi-textureing under mingw? It works
fine when compiled in Linux. Is it possible to use libmesa under mingw to
get it working? 

I would greatly appreciate any comments or suggestion. 

Chris

Solution(never tried):http://edll.sourceforge.net

What I like(in my app(c)):
main_app.c:
__dllexport CFunction(int arg)
{
//implementation here
};

Def file:
LIBRARY MyApp.exe
EXPORTS
CFunction

compile this with gcc using the -Wl,--def-file=3Dyour_def_file
-Wl,--out-implib=3DlibApp.a flags

this will create a library: libApp.a which will allow you to link your dll
back to your main application.

The reason dll's can't do this normally is because in the PE/COFF file
format, a dll is an exe, except the flags tell Windows it is a dll file and
it must contain an export table.

Hope it helps!

On 2/27/06, Michael Gerdau <mg...@te...> wrote:
>
> > Would there be any way around this behavior, like a g++/ld parameter
> > option, environment variable setting, etc?  (I'm guessing there is not,
> > especially if this is a Windows-OS restriction, but I'm leaving no ston=
e
> > unturned.)  As an aside:  when creating the same library(ies)/DLLs (tha=
t
> > require the resolve-all-symbols-at-link-time problem) as static
> libraries
> > (.a files), there are no link-time symbol-resolution problems.  So at
> least
> > there's some "lazy linking" capability at least on some level.
>
> I'm not quite sure I understand what you are after. However maybe
> the following info does help you anyway:
>
> When linking against a DLL the "usual" way is to use an importlib
> (Note: gcc/mingw/ld supports directly linking against the DLL without
> the need for an importlib; MS VC++ up to version 6 could not do that;
> I don't know about MS VC++ version 7).
>
> An importlib basically is a special lib that "claims" the corresponding
> DLL does export (at least) the entries the importlib "knows" about.
>
> Wether or not the DLL actually _does_ export those entries is not
> checked during linktime. So in a way you do have some sort of lazy
> linking as the actual resolving of references is done at runtime on
> Windows as well.
>
> Since you could create an importlib without actually having the DLL
> you could (technically) achieve a similar thing as on Linux.
>
> Or so.
>
> HTH, best,
> Michael
> --
> Vote against SPAM - see http://www.politik-digital.de/spam/
> Michael Gerdau       email: mg...@te...
> GPG-keys available on request or at public keyserver
>
>
>

Quoting Matt England <men...@me...>:

> At 2/27/2006 10:34 AM, Keith MARSHALL wrote:
>> Matt England wrote:
>> > I suspect there exist significant docs for dll creation under MinGW,
>> > but I have yet to find them.
>>
>> As both Earnie and Michael have suggested, your first port of call
>> should *always* be http://www.mingw.org/MinGWiki/index.php
>
> That's great to know.  If this is true, do we think this is worth 
> noting in big, unavoidable text at the top of:
>
> http://www.mingw.org/docs.shtml
>
> ?
>
> Maybe note that docs.shtml is effectively replaced and/or a better 
> source of info then docs.html?
>
> Or at least do something to merge/manage this content as such?  Maybe 
> take docs.html, merge it into the wiki, and then eliminate docs.html?
>

Web site sources are available in CVS under htdocs.  Submit patches to 
the SF patch tracker.


Earnie Boyd

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

> That's great to know.  If this is true, do we think this is worth noting =
in=20
> big, unavoidable text at the top of:
>=20
> http://www.mingw.org/docs.shtml
>=20
> ?

Well, yes.

But then it's not that the Wiki isn't mentioned in the same menu
as the documentation page (read: it _can_ be found ;)

One of the "problems" with the website and updating info there is
that you need karma to change that while the Wiki can be changed
without.

So far none of those having karma decided to do that.

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

At 2/27/2006 10:34 AM, Keith MARSHALL wrote:
>Matt England wrote:
> > I suspect there exist significant docs for dll creation under MinGW,
> > but I have yet to find them.
>
>As both Earnie and Michael have suggested, your first port of call
>should *always* be http://www.mingw.org/MinGWiki/index.php

That's great to know.  If this is true, do we think this is worth noting in 
big, unavoidable text at the top of:

http://www.mingw.org/docs.shtml

?

Maybe note that docs.shtml is effectively replaced and/or a better source 
of info then docs.html?

Or at least do something to merge/manage this content as such?  Maybe take 
docs.html, merge it into the wiki, and then eliminate docs.html?

-Matt 

Was anyone aware that MSYS is completely broken on Windows XP 64bit
edition?  I'm using Intel 64-bit Extensions processor.  I get the
following error for all MSYS executables (but not mingw apps.)

C:\>rxvt
c:\msys\1.0\bin\rxvt.exe: *** fork: can't reserve memory for stack
0x480000 - 0x680000, Win32 error 0
      0 [main] rxvt 2548 sync_with_child: child 3912(0x278) died before
initialization with status code 0x1
    641 [main] rxvt 2548 sync_with_child: *** child state waiting for
longjmp
rxvt: can't fork
rxvt: aborting

------

If there is awareness of the problem, can anyone point me to a work
around?  I've tried compatability mode, and it just changes the error
message:

C:\>rxvt
AllocationBase 0x0, BaseAddress 0x715B0000, RegionSize 0x10000, State
0x10000
c:\msys\1.0\bin\rxvt.exe: *** Couldn't reserve space for cygwin's heap,
Win32 error 0

-------

Thanks in advance!

-=3D{C}=3D-

Matt England wrote:
> I suspect there exist significant docs for dll creation under MinGW,
> but I have yet to find them.

As both Earnie and Michael have suggested, your first port of call
should *always* be http://www.mingw.org/MinGWiki/index.php

> eg, <http://www.mingw.org/docs.shtml#etc> has a reference to:
>
>     How to make DLLs using GCC
>     <
http://www.nanotech.wisc.edu/~khan/software/gnu-win32/dllhelpers.html>
>
> ...but said link no longer exists, and I can't find the content
> anywhere else, let alone a google cache.

The disappearance of the reference should hint that the info there
is likely to be obsolete; (and yes, we need to review our web pages
to eliminate such defunct links -- ideally, I don't think we should
post links to such potentially volatile resources; if we consider
them valuable, then we should seek permission to host the content
ourselves).

That said, I found that referenced content here:
http://web.archive.org/web/20050308115834/http://www.nanotech.wisc.edu/~khan/software/gnu-win32/dllhelpers.html

HTH.
Keith.

On 2006-2-27 15:50 UTC, Matt England wrote:
> From <http://lists.gnu.org/archive/html/libtool/2002-09/msg00145.html>:
> 
> What does:
> 
>    gcc -shared -o hello.dll hello.o -Wl,--out-implib,libhello.dll.a
> 
> take from the Makefile do?

  gcc -shared

Create a shared library...

 -o hello.dll

...named 'hello.dll'...

 hello.o

...from object file 'hello.o'

 -Wl,--out-implib,libhello.dll.a

and an import library named 'libhello.dll.a'.

> Specifically, why is the --out-implib linker
> directive needed?  I tested it, and when removing it, everything still
> works.

If you link directly to the dll, then it's not needed. See:

http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html

> I suspect there exist significant docs for dll creation under MinGW, but
> I have yet to find them.
> 
> eg, <http://www.mingw.org/docs.shtml#etc> has a reference to:
> 
>     How to make DLLs using GCC
>     <http://www.nanotech.wisc.edu/~khan/software/gnu-win32/dllhelpers.html>
> 
> ...but said link no longer exists, and I can't find the content anywhere
> else, let alone a google cache.

Perhaps this mirror will help:

http://programming.ccp14.ac.uk/ftp-mirror/programming/mumit-khan/pub/khan/gnu-win32/mingw32/misc/

> What does:
>=20
>     gcc -shared -o hello.dll hello.o -Wl,--out-implib,libhello.dll.a
>=20
> take from the Makefile do?

It creates an importlib with a somewhat unusual name.

> Specifically, why is the --out-implib linker directive needed?

Needed and needed.

It comes handy if you wish to create an importlib as well.

> I tested it, and when removing it, everything still works.=20

That is because gcc (more precisely ld) does not need an importlib.
Check out the binutils info files and/or the archives of this list
for a complete list of files checked to resolve references.

I'm not sure but I think there's also an entry in the Wiki.

You most likely will need an importlib if the DLL shall be linked
against with e.g. MS VC++.

> I suspect there exist significant docs for dll creation under MinGW, but =
I=20
> have yet to find them.

Searching the archives of this list as well as the mingwiki should
provide you lots of info.

> Might someone help guide me through the mysteries of windows/mingw/gcc/g+=
+=20
> shared/dynamic library creation and management?

http://www.mingw.org/MinGWiki/

Click on FAQ and scroll down. There are a couple of articles on DLLs.

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

Quoting Matt England <men...@me...>:


> Might someone help guide me through the mysteries of 
> windows/mingw/gcc/g++ shared/dynamic library creation and management?
>

Have you checked http://www.mingw.org/MinGWiki/index.php for help?


Earnie Boyd

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

> Would there be any way around this behavior, like a g++/ld parameter=20
> option, environment variable setting, etc?  (I'm guessing there is not,=20
> especially if this is a Windows-OS restriction, but I'm leaving no stone=
=20
> unturned.)  As an aside:  when creating the same library(ies)/DLLs (that=
=20
> require the resolve-all-symbols-at-link-time problem) as static libraries=
=20
> (.a files), there are no link-time symbol-resolution problems.  So at lea=
st=20
> there's some "lazy linking" capability at least on some level.

I'm not quite sure I understand what you are after. However maybe
the following info does help you anyway:

When linking against a DLL the "usual" way is to use an importlib
(Note: gcc/mingw/ld supports directly linking against the DLL without
the need for an importlib; MS VC++ up to version 6 could not do that;
I don't know about MS VC++ version 7).

An importlib basically is a special lib that "claims" the corresponding
DLL does export (at least) the entries the importlib "knows" about.

Wether or not the DLL actually _does_ export those entries is not
checked during linktime. So in a way you do have some sort of lazy
linking as the actual resolving of references is done at runtime on
Windows as well.

Since you could create an importlib without actually having the DLL
you could (technically) achieve a similar thing as on Linux.

Or so.

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

 From <http://lists.gnu.org/archive/html/libtool/2002-09/msg00145.html>:

What does:

    gcc -shared -o hello.dll hello.o -Wl,--out-implib,libhello.dll.a

take from the Makefile do?  Specifically, why is the --out-implib linker 
directive needed?  I tested it, and when removing it, everything still works.

I suspect there exist significant docs for dll creation under MinGW, but I 
have yet to find them.

eg, <http://www.mingw.org/docs.shtml#etc> has a reference to:

     How to make DLLs using GCC
     <http://www.nanotech.wisc.edu/~khan/software/gnu-win32/dllhelpers.html>

...but said link no longer exists, and I can't find the content anywhere 
else, let alone a google cache.

Might someone help guide me through the mysteries of windows/mingw/gcc/g++ 
shared/dynamic library creation and management?

-Matt

At 2/27/2006 12:21 AM, Brian Dessent wrote:
>This restriction (that all symbols must be resolved at link time) is a
>just a fundamental aspect of how windows works.  The concept of lazy
>linking where undefined symbols can be resolved at runtime by the
>dynamic linker does not exist on windows.

Ok, great info.  Are there any sources (preferably "authoritative" ones, 
like from Microsoft) that I can point to for more info and future, 
authoritative reference on this?

Would there be any way around this behavior, like a g++/ld parameter 
option, environment variable setting, etc?  (I'm guessing there is not, 
especially if this is a Windows-OS restriction, but I'm leaving no stone 
unturned.)  As an aside:  when creating the same library(ies)/DLLs (that 
require the resolve-all-symbols-at-link-time problem) as static libraries 
(.a files), there are no link-time symbol-resolution problems.  So at least 
there's some "lazy linking" capability at least on some level.

>FWIW windows is not the only platform with this restriction -- I believe
>AIX and/or darwin have similar issues.  The libtool list would be able
>to give more information.

Ok.  By "libtool list" I assume you mean their users email list.  In any 
case: would libtool help solve my above problems?

Another side (although I may take this up in more detail with the libtool 
folks, but I thought it worth asking here):

I'm trying to learn more about why libtool is useful at all if it doesn't 
solve the above problems.  While skimming 
<http://www.gnu.org/software/libtool/manual.html#Introduction>, I 
realize:  I don't need to write *any* platform-specific code for my 
libraries, shared or not.  Maybe this is because I'm not attempting to link 
them "manually" in the code after an application's startup, I'm just 
letting the linker do this for me?  Is that what that stuff is all 
about?  (Yes, I'm quite ignorant here.)

-Matt 

Michael Gerdau wrote:

> > Why do shared/dynamic library (DLL) builds in mingw/msys with g++ attempt
> > to resolve all references, even for other libraries?
> 
> I don't know _why_ mingw does that but this is thge behavior of all
> Win32 Compiler I've come across so far. So I'd suspect it is something
> inherent to their object/binary format. But others most certainly
> are better suited to comment.

This restriction (that all symbols must be resolved at link time) is a
just a fundamental aspect of how windows works.  The concept of lazy
linking where undefined symbols can be resolved at runtime by the
dynamic linker does not exist on windows.

FWIW windows is not the only platform with this restriction -- I believe
AIX and/or darwin have similar issues.  The libtool list would be able
to give more information.

Brian

> Why do shared/dynamic library (DLL) builds in mingw/msys with g++ attempt=
=20
> to resolve all references, even for other libraries?

I don't know _why_ mingw does that but this is thge behavior of all
Win32 Compiler I've come across so far. So I'd suspect it is something
inherent to their object/binary format. But others most certainly
are better suited to comment.

> Linux systems, on the other hand, don't try to resolve all references whe=
n=20
> building shared-object (.so) files (which I understand have some sort of=
=20
> resemblance to Windows DLLs), but rather the references are resolved at t=
he=20
> time the application that uses said libraries is built.

Yes, I've noticed that too.

I'm still not sure I do like that though I agree there are pros
as well (beside the cons).

> How can I avoid this the library-build-time reference errors and instead=
=20
> push the link-time-reference resolution to the time of an application=20
> build?  This would also dramatically reduce the size of the .dlls when=20
> reference static libraries (presumably).

You can't avoid that when referencing static libraries. It doesn't
work that way on Linux either. It either dynamic or static but not
dynamically static or so.

Therefor:
static libraries are linked in statically. That's the whole point
of using static libraries. If you wish to resolve the references
dynamically use a shared object (or DLL).

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

At 2/26/2006 04:41 PM, Jonathan Wilson wrote:
>Matt England wrote:
>>Why do shared/dynamic library (DLL) builds in mingw/msys with g++ attempt 
>>to resolve all references, even for other libraries?
>>Linux systems, on the other hand, don't try to resolve all references 
>>when building shared-object (.so) files (which I understand have some 
>>sort of resemblance to Windows DLLs), but rather the references are 
>>resolved at the time the application that uses said libraries is built.
>>Eg, when trying to build (within mingw) a library that uses the bzip2 
>>module, I get reference errors like this:
>>g++ -shared [...a slew of .o files...] libutil.dll
>>BZipBufferCompressor.o:BZipBufferCompressor.cpp:(.text+0xb39): undefined 
>>reference to `BZ2_bzCompressEnd@4'
>>[...]
>>How can I avoid this the library-build-time reference errors and instead 
>>push the link-time-reference resolution to the time of an application 
>>build?  This would also dramatically reduce the size of the .dlls when 
>>reference static libraries (presumably).
>>Maybe Windows defines DLLs to be freestanding apps, and hence is 
>>distinctly different then Linux .so files?  If so, where can I read more 
>>about this?
>The only way to do what you want would be to make the libraries in 
>question  dll files themselves.

Well, uh, yes.  Isn't that the entire point?  Is not

    dynamic library = dll file = "libraries in question" = libraries I'm making

?

And if so, I guess the question is: how do I make DLL files?  Apparently 
I'm not doing this correctly?

-Matt 

Matt England wrote:
> Why do shared/dynamic library (DLL) builds in mingw/msys with g++ 
> attempt to resolve all references, even for other libraries?
> 
> Linux systems, on the other hand, don't try to resolve all references 
> when building shared-object (.so) files (which I understand have some 
> sort of resemblance to Windows DLLs), but rather the references are 
> resolved at the time the application that uses said libraries is built.
> 
> Eg, when trying to build (within mingw) a library that uses the bzip2 
> module, I get reference errors like this:
> 
> g++ -shared [...a slew of .o files...] libutil.dll
> BZipBufferCompressor.o:BZipBufferCompressor.cpp:(.text+0xb39): undefined 
> reference to `BZ2_bzCompressEnd@4'
> [...]
> 
> How can I avoid this the library-build-time reference errors and instead 
> push the link-time-reference resolution to the time of an application 
> build?  This would also dramatically reduce the size of the .dlls when 
> reference static libraries (presumably).
> 
> Maybe Windows defines DLLs to be freestanding apps, and hence is 
> distinctly different then Linux .so files?  If so, where can I read more 
> about this?
The only way to do what you want would be to make the libraries in question 
  dll files themselves.

Why do shared/dynamic library (DLL) builds in mingw/msys with g++ attempt 
to resolve all references, even for other libraries?

Linux systems, on the other hand, don't try to resolve all references when 
building shared-object (.so) files (which I understand have some sort of 
resemblance to Windows DLLs), but rather the references are resolved at the 
time the application that uses said libraries is built.

Eg, when trying to build (within mingw) a library that uses the bzip2 
module, I get reference errors like this:

g++ -shared [...a slew of .o files...] libutil.dll
BZipBufferCompressor.o:BZipBufferCompressor.cpp:(.text+0xb39): undefined 
reference to `BZ2_bzCompressEnd@4'
[...]

How can I avoid this the library-build-time reference errors and instead 
push the link-time-reference resolution to the time of an application 
build?  This would also dramatically reduce the size of the .dlls when 
reference static libraries (presumably).

Maybe Windows defines DLLs to be freestanding apps, and hence is distinctly 
different then Linux .so files?  If so, where can I read more about this?

-Matt

>I think the bug you are running into is actually a problem with
>std:string instantiations (in this case the runtime_error string) across dll
>boundaries  See PR24196 in GCC's bugzilla for details and a patch.

Well, it would be a slightly different problem since libstdc++ is a
DLL in this case, and there's only one copy of _S_empty_rep_storage.
The cause he may be the result of libstdc++ code inlined into the
executable refering to the variable through a DLL import.  A simple
workaround might be to just put a __attribute__((dllimport)) on the
_S_empty_rep_storage declaration.

						Ross Ridge

Christof Petig wrote:
> Earnie Boyd wrote:
>>> That is a completely separate topic.  The library has the "runtime
>>> exception", which means that it imposes zero licensing restrictions.
>>> See also
>>> <http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html>.  You
>>> are perfectly fine to use g++ to make a proprietarty C++ application
>>> using the full STL/C++ library and are under zero obligations to license
>>> it in any particular way, regardless of shared/static libstdc++ linking.
>>>
>>
>> But if you distribute your package that uses the dynamic stdc++ dll then
>> you would also need to distribute the stdc++ dll and all of its source
>> regardless.
>
>That's really no problem for me. I would love to provide the source if
>it had worked. I would even help debugging/coding etc. but I do not want
>to shoulder a MinGW/g++ 4.0.x on my own. So far I ship the bigger
>binaries. :-(
>

Thanks very much for the testcase.
I think the bug you are running into is actually a problem with
std:string instantiations (in this case the runtime_error string) across dll
boundaries  See PR24196 in GCC's bugzilla for details and a patch.

FWIW your example works  if I replace your try-throw clause with

     try { throw 1;
       } catch (int i)
      { std::cout << i << std::endl;
      }

So, I'll try rebuilding 3.4.5 libstdc++.dll incorporting the PR24196 patch   and
go from there.

Your way of building libstdc++.dll should work,  but I prefer doing this:

dlltool --output.def libstdc++.def --export-all libstdc++.a
gcc -shared -o libstdc++.dll -Wl,--out-implib,libstdc++.dll.a libstdc++.def
libstdc++.a
mv -f libstdc++.dll  /mingw/bin

Danny

>    Christof
>

THANKS YOU VERY MUCH

Sincerely

Hector

--- Keith MARSHALL <kei...@to...> wrote:

> Brian Dessent wrote, quoting Hector Mora:
> >> In Linux I can  type
> >> 
> >>    man printf
> >> 
> >> to get information about  printf  function.
> >>
> >> How can I do it in Windows with Mingw?
> >
> > Since you are using Microsoft's C library you
> should consult their
> > documentation on MSDN and/or the platform SDK...
> 
> For functions provided by msvcrt, this is the
> appropriate source.
> 
> For any program you've installed, and for which you
> actually have the
> man page sources, then see the entry under the
> `Documentation' heading
> at http://www.mingw.org/MinGWiki/index.php/FAQ
> 
> For functions *not* provided by msvcrt, but which we
> provide in our
> mingwex library, then I think it is encumbent on us,
> the developers of
> MinGW, to provide appropriate documentation, perhaps
> in the form of
> man pages.  Unfortunately, to date we have not
> performed well in
> this respect.  Until we get our act together:
> http://man.linuxquestions.org
> 
> (But do remember, when you consult a Linux man page,
> the function may
>  not be supported by MinGW, or may exhibit different
> behaviour).
> 
> Regards,
> Keith.
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by xPML, a
> groundbreaking scripting language
> that extends applications into web and mobile media.
> Attend the live webcast
> and join the prime developer group breaking into
> this new coding territory!
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
> 
> You may change your MinGW Account Options or
> unsubscribe at:
>
https://lists.sourceforge.net/lists/listinfo/mingw-users
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3595521
By: y0ng

Hi, i really need help with autoconf(probably) problems.
currently im using gcc 3.4.5, automake and some other tools downloaded from
mingw website.
But im always have problem when running bootstrap and autogen from some fresh-cvs
source code.
example:
When i try to run autogen.sh from sdl, but msys give me:

configure.in:52: error: possibly undefined macro: AM_INIT_AUTOMAKE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.in:71: error: possibly undefined macro: AM_CONDITIONAL
configure.in:3066: error: possibly undefined macro: _AM_DEPENDENCIES

Here is the file from sdl autogen.sh:
#!/bin/sh
#
echo "Generating build information using autoconf"
echo "This may take a while ..."

# Regenerate configuration files
cp acinclude.m4 aclocal.m4
autoconf
(cd test; sh autogen.sh)

# Run configure for this platform
echo "Now you are ready to run ./configure"

I have same problem when try to bootstrap/autogen other source code too, like
VLC, libcaca, libmpeg2dec and ect ect.

Im really dont know how to do with it because im a newbies :p
Please i really need help, because i cant compile my favorite program anymore...

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=7134