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

g++ is just the C plus plus compiler from gnu. So just only go to the gnu homepage and look for the manual.


--- El vie, 31/7/09, ade...@si... <ade...@si...> escribió:

> De: ade...@si... <ade...@si...>
> Asunto: [Mingw-users] Running gtk+ sample code with mingw c++ on windows
> Para: min...@li...
> Fecha: viernes, 31 julio, 2009 9:45
> 
> Hi,
> 
> I installed gtk+ on my windows machine.i also have mingw
> compiler running. I
> want to simply compile and execute a sample c++ code that
> runs a gtk+ using
> the sample on
> http://library.gnome.org/devel/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD.
> 
> 1) When I compile with : " g++ helloworld.cpp -o helloworld
> " the compiler
> complaints of not finding the gtk.h header file
> 
> 2) I then tried the compilation with :
>  ' g++ helloworld.cpp -o helloworld -I
> "C:\gtk_win32\include\gtk-2.0" '  but
> the compiler still complaints of not finding some header
> files comtained in
> the gtk.h header file.
> 
> 
> What couldbe wrong with my steps above ?
> 
> 
> 3) can I get a pdf documentation detailing generics and
> specifics of mingw
> compiler ?
>      
> 
> 
> 
> 
> //
> http://www.hci-institute.com [ A leading ICT training
> institute]
> http://www.talkhaven.com [ Talk without bounds]
> http://www.3wgate.com [Computer Network Management
> Haven]
> 
> 
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal
> Reports 2008 30-Day 
> trial. Simplify your report design, integration and
> deployment - and focus on 
> what you do best, core application coding. Discover what's
> new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
> 
> 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) Thread hijacking
> 3) HTML/MIME encoded mail
> 4) Improper quoting
> 5) Improper trimming
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe
> at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> 


      

Hi,

I installed gtk+ on my windows machine.i also have mingw compiler running. I
want to simply compile and execute a sample c++ code that runs a gtk+ using
the sample on
http://library.gnome.org/devel/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD.

1) When I compile with : " g++ helloworld.cpp -o helloworld " the compiler
complaints of not finding the gtk.h header file

2) I then tried the compilation with :
 ' g++ helloworld.cpp -o helloworld -I "C:\gtk_win32\include\gtk-2.0" '  but
the compiler still complaints of not finding some header files comtained in
the gtk.h header file.


What couldbe wrong with my steps above ?


3) can I get a pdf documentation detailing generics and specifics of mingw
compiler ?
     




//
http://www.hci-institute.com [ A leading ICT training institute]
http://www.talkhaven.com [ Talk without bounds]
http://www.3wgate.com [Computer Network Management Haven]

> MinGW doesn't have those, you will need to port your applications.

OK, that's dissapointing. I'll comment it out for now.
-- 
View this message in context: http://www.nabble.com/sys-resource.h-not-found-tp24754547p24755686.html
Sent from the MinGW - User mailing list archive at Nabble.com.

On 7/31/2009 18:54, leledumbo wrote:
>
> I'm looking for a header containing getrusage, which according to official
> gcc docs is in sys/resource.h. However, I don't find it in any package
> offered in sourceforge.

Hi,
MinGW doesn't have those, you will need to port your applications.

I'm looking for a header containing getrusage, which according to official
gcc docs is in sys/resource.h. However, I don't find it in any package
offered in sourceforge.
-- 
View this message in context: http://www.nabble.com/sys-resource.h-not-found-tp24754547p24754547.html
Sent from the MinGW - User mailing list archive at Nabble.com.

I am trying to build a program using the proj.4 library on MinGW/WinXP.
The program runs fine in the MinGW shell. When run outside MinGW,
floating point values come back from a function as 1#.IND (undefined, NaN)
and the printfs I added to the function are not run.

This seems to depend on whether I run the program from the directory
it was compiled in. The program produces valid xy values -- but still
does not run the gn_sinu printfs -- if I run it from inside the
directory where it was compiled. It fails if I run it from a copy of
that directory, which makes no sense to me. It fails if the current
working directory is not the compilation directory. MinGW bash runs it
without problems in all these cases.

Brief overview of how proj works:
Each projection is a separate .c file that becomes a separate .o file
in the libproj.a library. Each .c file has macros FORWARD and INVERSE
that are expanded to functions. I am using the "goode" forward function
which in turn calls the "sinu" forward function, which returns a struct
of doubles which are coming back as undefined NaNs.

My full compile line:
g++ -g --static -DPROJ4 -g libdbf.c shapestuff.cc shpopen.o dbfopen.o
shpgeo.o libproj_dmt.a -o ../appoint_part1.cgi

All the other files should not matter. -DPROJ4 does not matter either
by this point; I needed it earlier for the shpgeo file. Everything was
compiled in MinGW on the same machine.


Example output from MinGW bash:

$ ../appoint_part1.cgi
In forward, sinu 414d10 moll 41f120 reg 6, lam0 0.0000, l,p are: -0.9974,
+-0.5407
DEBUG: gn_sinu P->m 0 lam
+13444353561806976000000000000000000000000000000000000.0000,-6696286104189131600
+0000000000000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000000.0000
DEBUG: gn_sinu post returning xy 0.0427,-0.5407
In forward after mods lam0 0.0000, x,y are: 0.0427, -0.5407 lp is 0.0497,
+-0.5407
In inverse, reg 6, x,y are: -1.0046, -0.5407
In inverse after mods lam0 0.0000, x,y are: 0.0426, -0.5407 lp is 0.0497,
+-0.5407


Example output from Windows cmd:

>appoint_part1.exe
In forward, sinu 3e2758 moll 3e2878 reg 6, lam0 0.0000, l,p are: -0.9974,
+-0.5407
In forward after mods lam0 0.0000, x,y are: -1.#IND, -1.#IND lp is 0.0497,
+-0.5407
(The program then hangs here because it goes into a loop comparing against
the NaN value and I am a bad programmer who forgot to check for that.)


Example output from the compilation directory:

>..\appoint_part1.cgi
In forward, sinu 414c50 moll 41f270 reg 6, lam0 0.0000, l,p are: -0.9974,
+-0.5407
In forward after mods lam0 0.0000, x,y are: 0.0427, -0.5407 lp is 0.0497,
+-0.5407
In inverse, reg 6, x,y are: -1.0046, -0.5407
In inverse after mods lam0 0.0000, x,y are: 0.0426, -0.5407 lp is 0.0497,
+-0.5407


All printfs here go to stderr, in case that matters as to why the
gn_sinu printfs are not appearing when run from cmd. The file extension
(exe or cgi) has no effect on the program's behaviour. 


What might cause the struct to come back full of NaNs? Why would the
working directory matter? Why would it matter whether I am in bash or
cmd? Why aren't the gn_sinu printfs showing up even when it appears
the function is run successfully? 

Thanks in advance for any help,

- David T. 

Tor,

> Good luck in convincing proprietary cross-tool companies to donate
> their documentation to this wiki...

well, I don't want to convince anyone - it's just an opportunity, that 
one might take.

nor am I assuming that people would use illegal copies of any kind of 
software. software licenses should be honored - be that closed or open 
source licenses.

OTOH, to respond to your specific topic, it might be beneficial for 
closed source / commercial tool users as well to share information 
online. the information itself does not have to be closed, even if the 
tool itself is not available for free (as in beer). I don't see any 
contradiction in that.

also note that the CC-by-sa license on the page means that the contents 
of the page can be used in commercial environments.

> Note: I am not saying that the wiki could not be useful, for the
> specific case of cross development using the GNU toolchain, by the
> Open Source community. I am just nitpicking on its (unintendedly?)
> vast scope... Maybe just some clarification and restriction of scope
> on the front page is in order...

how does the wide scope confuse you? can you be more specific about this 
confusion?


Akos

> that's even more of reason to collect such vast amount of documentation
> into a single place!

Good luck in convincing proprietary cross-tool companies to donate
their documentation to this wiki...

Or do you mean 3rd-party documentation for proprietary cross
development toolchains? Does such exist? Who would have created it?

Would a company that spends $$$ on licenses for some proprietary
toolchain and yearly support, and where people then write in-house
documentation to complement the vendor's documentation, be willing to
make such documentation public (and useful to their competitors!)?
Such in-house documentation presumably contains trade secrets, details
specific to the company's environment and the products that the
company builds using the toolchain in question.

Or do you mean information written by people using illegal copies of
proprietary cross-development toolchains, who perhaps have no written
documentation and for obvious reasons can't use the toolchain vendor's
official support channels, forums, etc?

Note: I am not saying that the wiki could not be useful, for the
specific case of cross development using the GNU toolchain, by the
Open Source community. I am just nitpicking on its (unintendedly?)
vast scope... Maybe just some clarification and restriction of scope
on the front page is in order...

--tml

Tor,

> I wonder if you are aware how large the scope of cross-compilation
> actually is? The case of cross-compiling from Linux (and other Unixes)
> to Windows using gcc is a very small part of it.
> 
> All the code that runs in machines one interacts with every day, from
> toasters to phone exchanges, is cross-compiled, very often using
> proprietary toolkits (although gcc and the GNU toolchain is becoming
> more popular, I am sure, as part of commercial toolkits targeted at
> proprietary embedded OSes), very often from Windows, not from Linux.

that's even more of reason to collect such vast amount of documentation 
into a single place!


Akos

> but it might still make sense to collect a range of cross-compilation
> info at a single location.

I wonder if you are aware how large the scope of cross-compilation
actually is? The case of cross-compiling from Linux (and other Unixes)
to Windows using gcc is a very small part of it.

All the code that runs in machines one interacts with every day, from
toasters to phone exchanges, is cross-compiled, very often using
proprietary toolkits (although gcc and the GNU toolchain is becoming
more popular, I am sure, as part of commercial toolkits targeted at
proprietary embedded OSes), very often from Windows, not from Linux.

--tml

On Wednesday 29 July 2009 07:56:16 Maróy Ákos wrote:
> As I've been playing along with cross-compilation issues for some
> time, and have found no single location for this kind of
> information, I decided to open a wiki to collect such information
> into one place.
>
> See the very initial form of this here: http://cross-compile.info/

I don't really have the time to participate in maintaining this, but 
I did have a quick peek.  One thing I did notice immediately is that 
you seem to have fallen into the common trap of confusing the build, 
host and target terminology, as it is commonly accepted:

  build    is the platform/architecture on which your cross tools
           run; (you have incorrectly described this as "host").

  host     is the platform/architecture on which the applications
           you build, using your cross tools, will run; (you have
           incorrectly described this as "target").

  target   is the platform/architecture for which the applications
           you build, using your cross tools, will generate code;
           (note that this implies that you are using your cross
            tools to build another compiler, or other form of code
            generator -- it is meaningless in any other context).

-- 

Regards,
Keith.

Hi everyone, 

I have installed MinGW and MSYS on my system. My goal is to create a DLL library and an import library so that my DLL can be used by tools other than the MinGW toolchain.

I already read and then tried to build a simple DLL like the DLL example at MinGW website (http://oldwiki.mingw.org/index.php/sample%20DLL). The example_dll.dll was created. I also linked it successfully to a .exe program in MinGW environment. 

Everything ok except the import library: it was not created. 
I don't know why but the command: 
g++ -shared -o example_dll.dll example_dll.o -Wl,--out-implib,libexample_dll.a
did not create any import library for me. Please show me what to do to get the import libary.

Thanks in advance!

Itachi.



      Lướt web nhanh hơn. Internet Explorer 8 tối ưu hóa cho Yahoo!, tự động khởi động 2 trang bạn thích mỗi lần mở trình duyệt. Tải IE8 tại đây! http://downloads.yahoo.com/vn/internetexplorer/

Hi,

I have a C program for the windows console that handles data internally 
in UTF-8 format. As far as I know the only way to print Unicode 
characters correctly in a console is by using WriteConsoleW(). I made a 
printf() wrapper utf8_printf() that converts UTF-8 multi-byte to UTF-16 
wide characters and then uses WriteConsoleW() to output the Unicode 
characters. But I run into trouble when I use gettext. For instance if I do:

char *utf8_data ;   // some utf8 encoded string.
utf8_printf(_("print some utf8 data: %s\n"), utf8_data);

Gettext will convert the translation of "print some utf8 data: " to the 
windows system code page (in my case CP1252). So when I run 
utf8_printf() the utf8 encoded data is correctly printed, but the 
message has errors if it contains for instance Spanish accented 
characters. The Mingw port of Gettext (or Iconv) always translates to 
the windows system code page. It ignores the LC_CTYPE environment 
variable. Is there a way to make gettext translate to UTF-8? Or should I 
solve this problem differently?

best regards,

Erwin

On Wed, 2009-07-29 at 08:56 +0200, Maróy Ákos wrote:
> As I've been playing along with cross-compilation issues for some time,
> and have found no single location for this kind of information, I
> decided to open a wiki to collect such information into one place.
> 
> See the very initial form of this here: http://cross-compile.info/
[..]
> And of course, all feedback is welcome!

You can pick up a thing or two at http://cegcc.sourceforge.net .

	Danny
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Hi,

As I've been playing along with cross-compilation issues for some time,
and have found no single location for this kind of information, I
decided to open a wiki to collect such information into one place.

See the very initial form of this here: http://cross-compile.info/

Of course, the MinGW cross compiler building process is documented here:
http://www.mingw.org/wiki/LinuxCrossMinGW
but it might still make sense to collect a range of cross-compilation
info at a single location.


My hope is that this wiki will contain a range of information that is
related to cross-compilation. I'd really appreciate anyone interested
would consider contributing as well. Therefore I welcome all of you
interested to register at the wiki, and extend the pages as you see fit.
I'd be also glad to give interseted parties write access to the
subversion repository I created, so as the collect files in relation to
cross-compiling at a single location.

And of course, all feedback is welcome!


Akos

Hi

Pls can you show me a simple way of configuring mingw on windows to search
for header and library files in specific folders ?

I tried tweaking the specs file but had problem -in fact the compiler
crashed and I had to re-install to revive it.


Can anyone kindly tell me what I need to do in simple language ?


Pls assist me 


http://www.hci-institute.com [ A leading ICT training institute]
http://www.talkhaven.com [ Talk without bounds]
http://www.3wgate.com [Computer Network Management Haven]
-----Original Message-----
From: min...@li...
[mailto:min...@li...] 
Sent: Tuesday, 28 July, 2009 4:23 PM
To: min...@li...
Subject: POSSIBLE SPAM: MinGW-users Digest, Vol 38, Issue 39

Send MinGW-users mailing list submissions to
	min...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/mingw-users
or, via email, send a message with subject or body 'help' to
	min...@li...

You can reach the person managing the list at
	min...@li...

When replying, please edit your Subject line so it is more specific than
"Re: Contents of MinGW-users digest..."


Today's Topics:

   1. Re: Converting app that uses SJLJ exception to Dwarf-2 (Mark)
   2. Re: Problems with g++ 4.4.0 and libtool (Tim Teulings)
   3. Re: Converting app that uses SJLJ exception to Dwarf-2
      (Keith Marshall)
   4. Re: msys make 3.81 crashing with stack trace (de...@vo...)
   5. Re: Problems with g++ 4.4.0 and libtool (Charles Wilson)
   6. GCC 4.4.0 ICE if member function of template use	local array
      (Tonal)
   7. Re: GCC 4.4.0 ICE if member function of template use local
      array (Greg Chicares)
   8. Re: GCC 4.4.0 ICE if member function of template use local
      array (JonY)


----------------------------------------------------------------------

Message: 1
Date: Mon, 27 Jul 2009 19:27:17 +0200
From: Mark <mar...@gm...>
Subject: Re: [Mingw-users] Converting app that uses SJLJ exception to
	Dwarf-2
To: MinGW Users List <min...@li...>
Message-ID: <4A6...@gm...>
Content-Type: text/plain; charset=ISO-8859-1

Keith Marshall wrote:
> On Monday 27 July 2009 09:14:53 leledumbo wrote:
>   
>>> I've already given you one example of why that might be.  Did you 
>>> read it?
>>>       
>> Uh-huh, though I believe that's not the cause.
>>     
>
> Maybe not that, exactly, but likely something similar -- invalid 
> source code, which results in different undefined behaviour with 
> different compilers.
>   
One particular gotcha in setjmp is when the stack is too modified at resume;
for instance when resuming after a function is already complete; without
seeing the actual code that is upsetting you, I'd say it would be possible
that compiler optimization makes the difference between the cases

Best regards

Mark

http://www.halloit.com

Key ID 046B65CF




------------------------------

Message: 2
Date: 27 Jul 2009 19:51:13 +0200
From: "Tim Teulings" <ra...@ed...>
Subject: Re: [Mingw-users] Problems with g++ 4.4.0 and libtool
To: "MinGW Users List" <min...@li...>
Message-ID: <4A6...@ed...>
Content-Type: text/plain; charset=ISO-8859-1

Hello!

>> question: Should the
>>   separate automake and autoconf and the corresponding wrapper 
>> packages from the download
>>   page (which currently gives me a 500, so I cannot give the concrete 
>> package names :-/)
>>   be depacked into the mingw directory (which I did)? 

> Yes.

OK. Btw., the packages I installed were:
* autoconf-6-1-mingw32-bin.tar.lzma
* autoconf2.5-2.63-1-mingw32-bin.tar.lzma
* automake1.10-1.10.2-1-mingw32-bin.tar.lzma
* automake1.11-1.11-1-mingw32-bin.tar.lzma
* automake-4-1-mingw32-bin.tar.lzma

I started using only autoconf 2.5 and automake 1.11 and the wrappers but
than got errors that automake 1.10 was not found so I installed it also (but
I think I remeber later on to get hints in warnings that 1.11 was used).
Should I either install automake 1.10 or 1.11 next time? I assumed the
wrapper would handled parallel installs!?

>> Are there any things
>> I need to be aware
>>   of if I do so?
> 
> No. Except read /mingw/share/doc/MinGW/libtool-*.RELEASE_NOTES.

Good hint, since it looks like I installed the mingwPORT version (because I
remembered that this was version I used for 3.x.x). Seems like there is one
more reason for a fresh and clean reinstall and install the correct
packages.

> I'd export
>    gl_cv_cc_visibility=no
> (or the appropriate autoconf variable; check your configure script) 
> before configuring.  Alternatively, modify your code to only use the 
> visibility flags if HAVE_VISIBILITY && !(__CYGWIN__ || __MINGW32__)
> 
>>   Should the visibility feature be used under Windows at all?
> 
> IMO, no.

OK. Clear answer. I will try to modify either the configure.ac or my
defines.

>> * I get a linking error because of not finding the std library. 
>> Googling
[...]

> See the bottom of /mingw/share/doc/MinGW/libtool-*.RELEASE_NOTES.

OK. So I'll add "-static-libstdc++" to my configure.ac for windows & mingw
and will patch as described.

> But that's just too ugly for words.  suggestions (and especially,
> patches) welcome...

I generally have no fear in hacking in foreign code but libtool is to big
dragon on a big hill deep in unknown land for me to fight against ;-)

Many thanks for the fast and helpful answer!

--
Gru?...
       Tim




------------------------------

Message: 3
Date: Mon, 27 Jul 2009 22:09:33 +0100
From: Keith Marshall <kei...@us...>
Subject: Re: [Mingw-users] Converting app that uses SJLJ exception to
	Dwarf-2
To: min...@li...
Message-ID: <200...@us...>
Content-Type: text/plain;  charset="iso-8859-1"

On Monday 27 July 2009 18:27:17 Mark wrote:
> One particular gotcha in setjmp is when the stack is too modified
> at resume; for instance when resuming after a function is already
> complete; without seeing the actual code that is upsetting you,
> I'd say it would be possible that compiler optimization makes the
> difference between the cases

It isn't even certain that setjmp is involved at all.  The OP seems 
to have jumped to a conclusion that the switch from SJLJ exception 
handling to the Dwarf-2 model is somehow responsible, but that 
clearly isn't the case, because there is no exception handler in 
play; (the code is C, and the EH model is exclusive to C++).

Since we haven't been shown any code, or even any diagnostics, we 
really can't offer anything but sheer speculation anyway.

-- 

Regards,
Keith.



------------------------------

Message: 4
Date: Mon, 27 Jul 2009 16:17:36 -0700
From: de...@vo...
Subject: Re: [Mingw-users] msys make 3.81 crashing with stack trace
To: min...@li...
Message-ID: <200...@sh...>
Content-Type: text/plain; charset="utf-8"; format=flowed

Sorry if this starts a new thread, I had to start a new account since the 
work email system was blocking the messages, hrm. 

> Dean Giberson wrote:
> > I'm having an issue getting msys make working 100% on a buildbot server.
> > What seems to happen, is that we get this crash in make when we get a
> > large parallel build started on our build machine; we have 3 platforms,
> > each with 3 targets currently setup. These builds all get started at the
> > same time and every so often a make error occurs. The it will normally
> > happen on more than one platform/configuration if it happens at all. 
> 
> Unfortunately, the stack trace gave me no useful information, because
> the distributed executable was stripped of debug symbols. 
> 

Yes I can see how that would not be helpful. 

> I created a new executable that preserves all the debug symbols. Could
> you try to repeat the crash, and send the resulting stack trace? 
> 

Thanks 

> To download it, go to the MinGW Download page and find this file: 
> 
> MSYS Base System
> -> Debug Builds
> -> cpmake-3.81-MSYS-1.0.11-2
> -> cpmake-3.81-MSYS-1.0.11-2-bin.tar.gz 
> 
> Then, unpack the file at the root of your MSYS installation. 
> 
> Perhaps it is worth trying the case-insensitive build as well: 
> 
> MSYS Base System
> -> Current Release_ MSYS-1.0.11
> -> make-3.81-MSYS-1.0.11-2.tar.bz2 
> 

I've downloaded this archive (with MD5sum 2653721e9ead58318beb85880a989e62) 
and captured two crashes, neither seem to have anymore details. Have I 
missed an option maybe? 

The archive contained one file bin/make.exe which is larger, 490,838 bytes 
and md5sum 840b60b40878d9ebbbf4482e5835e83c. 

> Regards,
> Cesar

here are the two dumps 

 --- make.exe.stackdump 1 --- 

MSYS-1.0.11 Build:2009-07-11 17:46
Exception: STATUS_ACCESS_VIOLATION at eip=0040FFA6
eax=00000004 ebx=71110DE4 ecx=7109BB5C edx=0022EB98 esi=FFFFFFFF 
edi=00000000
ebp=0022EBD4 esp=0022EBAC 
program=C:\SlantSix\phaedo\buildbot\bs-vm1\demo\xpframework\External\common\

msys\1.0.11\bin\make.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022EBD4  0040FFA6  (00000005, 0A038058, 000000C8, 0040A21B)
0022EBF4  7108468A  (00000005, 0A038058, 000000C8, 0040A19B)
0022ECB4  0040A25B  (0A037EB8, 0022ECCC, 0040A513, 0040A6D8)
0022ED24  0040A8B2  (0022EDAC, 0022EDB0, 00000000, 7108C3A3)
0022EDB4  004052DC  (00000000, 0A01DEC0, FFFFFFFF, 0A037E60)
0022EDE4  00405C46  (0A01DEC0, 00000000, 0A037A90, 004165D6)
0022EE24  00405026  (0A01D0C8, 00000000, 0000003A, 0041FCE2)
0022EEB4  00405579  (0A037B40, 0022EECC, 0000000F, 0040AB01)
0022EF24  0040AC93  (0A037B40, 0022EF44, 0040A4D7, 0040A6D8)
0022EF94  0040A8B2  (0022F01C, 0022F020, 00000000, 00000060)
0022F024  004052DC  (00000000, 0A01E5D0, FFFFFFFF, 7102D024)
0022F054  00405C46  (0A01E5D0, 00000000, 0A037678, 004165D6)
0022F094  00405026  (0A01E5A0, 00000000, 0000003A, 00419E18)
0022F124  00405579  (00000000, 0A01CF50, 0000002C, 00000000)
0022F214  00417F17  (0022F264, 00000001, 0022F284, 00417143)
0022F284  00417170  (0A01D110, 00000001, 00000007, 00000000)
End of stack trace (more stack frames may be present) 

 --- make.exe.stackdump 2 --- 

MSYS-1.0.11 Build:2009-07-11 17:46
Exception: STATUS_ACCESS_VIOLATION at eip=0040FFA6
eax=00000004 ebx=7111027C ecx=7109BB5C edx=0022EA08 esi=FFFFFFFF 
edi=00000000
ebp=0022EA44 esp=0022EA1C 
program=C:\SlantSix\phaedo\buildbot\bs-vm1\demo\xpframework\External\common\

msys\1.0.11\bin\make.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022EA44  0040FFA6  (00000006, 0A033410, 000000C8, 0040A21B)
0022EA64  7108468A  (00000006, 0A033410, 000000C8, 0040A19B)
0022EB24  0040A25B  (0A01E268, 0022EB3C, 0040A513, 0040A6D8)
0022EB94  0040A8B2  (0022EC1C, 0022EC20, 00000000, 7108C3A3)
0022EC24  004052DC  (00000000, 0A01DF10, FFFFFFFF, 0A01E210)
0022EC54  00405C46  (0A01DF10, 00000000, 0A01E110, 004165D6)
0022EC94  00405026  (0A01D128, 00000000, 0000003A, 0041FCE2)
0022ED24  00405579  (0A01E610, 0022ED3C, 0000000F, 0040AB01)
0022ED94  0040AC93  (0A01E610, 0022EDB4, 0040A4D7, 0040A6D8)
0022EE04  0040A8B2  (0022EE8C, 0022EE90, 00000000, 00000009)
0022EE94  004052DC  (00000000, 0A01E5D7, FFFFFFFF, 7105B2E4)
0022EEC4  00405C46  (0A01E5D7, 00000000, 0A01E5C8, 00420F5F)
0022EF34  00420A63  (0022F0E8, 0A01DE40, 0A01E5D7, 00000002)
0022EF94  00421876  (0022F0E8, 0A01E5C8, 00000002, 00000000)
0022F084  00417DA5  (0022F0D4, 00000001, 0022F0F4, 00417143)
0022F0F4  00417170  (0A01D838, 00000001, 00000007, 00421AA2)
End of stack trace (more stack frames may be present) 

 ---- 

Thanks,
Dean Giberson



------------------------------

Message: 5
Date: Tue, 28 Jul 2009 00:29:29 -0400
From: Charles Wilson <cwi...@us...>
Subject: Re: [Mingw-users] Problems with g++ 4.4.0 and libtool
To: min...@li...
Message-ID: <4A6...@us...>
Content-Type: text/plain; charset=ISO-8859-1

Tim Teulings wrote:
> OK. Btw., the packages I installed were:
> * autoconf-6-1-mingw32-bin.tar.lzma
> * autoconf2.5-2.63-1-mingw32-bin.tar.lzma
> * automake1.10-1.10.2-1-mingw32-bin.tar.lzma
> * automake1.11-1.11-1-mingw32-bin.tar.lzma
> * automake-4-1-mingw32-bin.tar.lzma
> 
> I started using only autoconf 2.5 and automake 1.11 and the wrappers but
> than got errors that automake 1.10 was not found so I installed it also
> (but I think I remeber later on to get hints in warnings that 1.11 was
> used). Should I either install automake 1.10 or 1.11 next time? I
> assumed the wrapper would handled parallel installs!?

Yes, it does.  However, if you are autoreconf-ing (or, for whatever
reason, make decides that the Makefiles should be regenerated) then the
version that will be used is: the version that WAS used previously to
generated the existing Makefile.in.

So, if your Makefile.in says "This file was generated by autoameke-1.10"
then when you (or autoreconf, or make) invokes automake (wrapper), it
will try to invoke automake-1.10.  If you've only installed am-1.11 -- boom.

--
Chuck




------------------------------

Message: 6
Date: Tue, 28 Jul 2009 15:10:32 +0700
From: Tonal <to...@pr...>
Subject: [Mingw-users] GCC 4.4.0 ICE if member function of template
	use	local array
To: min...@li...
Message-ID: <h4mbpq$e1t$1...@ge...>
Content-Type: text/plain; charset=UTF-8; format=flowed

OS Windows Vista Home Basic Ru + sp2
g++ (GCC) 4.4.0
GNU ld (GNU Binutils) 2.19

Code:
template <class T>
struct test_t {
   int i;
   test_t() : i(10) {}
   char f() const {
     char buf[this->i]; //internal compiler error: Segmentation fault
     return buf[0];
   }
};

int main() {
   test_t<int> test;
   test.f();
}

Console command:
 > >g++ -c "ice_local_array.cpp"
Output:
ice_local_array.cpp: In member function 'char test_t<T>::f() const [with 
T = int]':
ice_local_array.cpp:13:   instantiated from here
ice_local_array.cpp:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Bug report 2821688
http://sourceforge.net/tracker/?func=detail&atid=102435&aid=2821688&group_id
=2435
-- 
Alexandr N. Zamaraev




------------------------------

Message: 7
Date: Tue, 28 Jul 2009 12:10:37 +0000
From: Greg Chicares <gch...@sb...>
Subject: Re: [Mingw-users] GCC 4.4.0 ICE if member function of
	template use local array
To: MinGW Users List <min...@li...>
Message-ID: <4A6...@sb...>
Content-Type: text/plain; charset=ISO-8859-1

On 2009-07-28 08:10Z, Tonal wrote:
> 
> template <class T>
> struct test_t {
>    int i;
>    test_t() : i(10) {}
>    char f() const {
>      char buf[this->i]; //internal compiler error: Segmentation fault

AFAIK, the standard language doesn't allow that: 'i' isn't constant,
and a contant-expression can't use 'this' or any pointer. Or is this
permitted by some gnu extension? Regardless, any ICE is an imperfection.



------------------------------

Message: 8
Date: Tue, 28 Jul 2009 23:22:17 +0800
From: JonY <10...@gm...>
Subject: Re: [Mingw-users] GCC 4.4.0 ICE if member function of
	template use local array
To: MinGW Users List <min...@li...>
Message-ID: <4A6...@gm...>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 7/28/2009 20:10, Greg Chicares wrote:
> On 2009-07-28 08:10Z, Tonal wrote:
>>
>> template<class T>
>> struct test_t {
>>     int i;
>>     test_t() : i(10) {}
>>     char f() const {
>>       char buf[this->i]; //internal compiler error: Segmentation fault
>
> AFAIK, the standard language doesn't allow that: 'i' isn't constant,
> and a contant-expression can't use 'this' or any pointer. Or is this
> permitted by some gnu extension? Regardless, any ICE is an imperfection.
>

Hi,

Non constant expressions for array size are allowed by C99, see:
<http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html>
<http://en.wikipedia.org/wiki/Variable-length_array>



------------------------------

----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus
on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

------------------------------

_______________________________________________
MinGW-users mailing list
Min...@li...

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


End of MinGW-users Digest, Vol 38, Issue 39
*******************************************

On 7/28/2009 20:10, Greg Chicares wrote:
> On 2009-07-28 08:10Z, Tonal wrote:
>>
>> template<class T>
>> struct test_t {
>>     int i;
>>     test_t() : i(10) {}
>>     char f() const {
>>       char buf[this->i]; //internal compiler error: Segmentation fault
>
> AFAIK, the standard language doesn't allow that: 'i' isn't constant,
> and a contant-expression can't use 'this' or any pointer. Or is this
> permitted by some gnu extension? Regardless, any ICE is an imperfection.
>

Hi,

Non constant expressions for array size are allowed by C99, see:
<http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html>
<http://en.wikipedia.org/wiki/Variable-length_array>

On 2009-07-28 08:10Z, Tonal wrote:
> 
> template <class T>
> struct test_t {
>    int i;
>    test_t() : i(10) {}
>    char f() const {
>      char buf[this->i]; //internal compiler error: Segmentation fault

AFAIK, the standard language doesn't allow that: 'i' isn't constant,
and a contant-expression can't use 'this' or any pointer. Or is this
permitted by some gnu extension? Regardless, any ICE is an imperfection.

OS Windows Vista Home Basic Ru + sp2
g++ (GCC) 4.4.0
GNU ld (GNU Binutils) 2.19

Code:
template <class T>
struct test_t {
   int i;
   test_t() : i(10) {}
   char f() const {
     char buf[this->i]; //internal compiler error: Segmentation fault
     return buf[0];
   }
};

int main() {
   test_t<int> test;
   test.f();
}

Console command:
 > >g++ -c "ice_local_array.cpp"
Output:
ice_local_array.cpp: In member function 'char test_t<T>::f() const [with 
T = int]':
ice_local_array.cpp:13:   instantiated from here
ice_local_array.cpp:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Bug report 2821688
http://sourceforge.net/tracker/?func=detail&atid=102435&aid=2821688&group_id=2435
-- 
Alexandr N. Zamaraev

Tim Teulings wrote:
> OK. Btw., the packages I installed were:
> * autoconf-6-1-mingw32-bin.tar.lzma
> * autoconf2.5-2.63-1-mingw32-bin.tar.lzma
> * automake1.10-1.10.2-1-mingw32-bin.tar.lzma
> * automake1.11-1.11-1-mingw32-bin.tar.lzma
> * automake-4-1-mingw32-bin.tar.lzma
> 
> I started using only autoconf 2.5 and automake 1.11 and the wrappers but
> than got errors that automake 1.10 was not found so I installed it also
> (but I think I remeber later on to get hints in warnings that 1.11 was
> used). Should I either install automake 1.10 or 1.11 next time? I
> assumed the wrapper would handled parallel installs!?

Yes, it does.  However, if you are autoreconf-ing (or, for whatever
reason, make decides that the Makefiles should be regenerated) then the
version that will be used is: the version that WAS used previously to
generated the existing Makefile.in.

So, if your Makefile.in says "This file was generated by autoameke-1.10"
then when you (or autoreconf, or make) invokes automake (wrapper), it
will try to invoke automake-1.10.  If you've only installed am-1.11 -- boom.

--
Chuck

Sorry if this starts a new thread, I had to start a new account since the 
work email system was blocking the messages, hrm. 

> Dean Giberson wrote:
> > I'm having an issue getting msys make working 100% on a buildbot server.
> > What seems to happen, is that we get this crash in make when we get a
> > large parallel build started on our build machine; we have 3 platforms,
> > each with 3 targets currently setup. These builds all get started at the
> > same time and every so often a make error occurs. The it will normally
> > happen on more than one platform/configuration if it happens at all. 
> 
> Unfortunately, the stack trace gave me no useful information, because
> the distributed executable was stripped of debug symbols. 
> 

Yes I can see how that would not be helpful. 

> I created a new executable that preserves all the debug symbols. Could
> you try to repeat the crash, and send the resulting stack trace? 
> 

Thanks 

> To download it, go to the MinGW Download page and find this file: 
> 
> MSYS Base System
> -> Debug Builds
> -> cpmake-3.81-MSYS-1.0.11-2
> -> cpmake-3.81-MSYS-1.0.11-2-bin.tar.gz 
> 
> Then, unpack the file at the root of your MSYS installation. 
> 
> Perhaps it is worth trying the case-insensitive build as well: 
> 
> MSYS Base System
> -> Current Release_ MSYS-1.0.11
> -> make-3.81-MSYS-1.0.11-2.tar.bz2 
> 

I've downloaded this archive (with MD5sum 2653721e9ead58318beb85880a989e62) 
and captured two crashes, neither seem to have anymore details. Have I 
missed an option maybe? 

The archive contained one file bin/make.exe which is larger, 490,838 bytes 
and md5sum 840b60b40878d9ebbbf4482e5835e83c. 

> Regards,
> Cesar

here are the two dumps 

 --- make.exe.stackdump 1 --- 

MSYS-1.0.11 Build:2009-07-11 17:46
Exception: STATUS_ACCESS_VIOLATION at eip=0040FFA6
eax=00000004 ebx=71110DE4 ecx=7109BB5C edx=0022EB98 esi=FFFFFFFF 
edi=00000000
ebp=0022EBD4 esp=0022EBAC 
program=C:\SlantSix\phaedo\buildbot\bs-vm1\demo\xpframework\External\common\ 
msys\1.0.11\bin\make.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022EBD4  0040FFA6  (00000005, 0A038058, 000000C8, 0040A21B)
0022EBF4  7108468A  (00000005, 0A038058, 000000C8, 0040A19B)
0022ECB4  0040A25B  (0A037EB8, 0022ECCC, 0040A513, 0040A6D8)
0022ED24  0040A8B2  (0022EDAC, 0022EDB0, 00000000, 7108C3A3)
0022EDB4  004052DC  (00000000, 0A01DEC0, FFFFFFFF, 0A037E60)
0022EDE4  00405C46  (0A01DEC0, 00000000, 0A037A90, 004165D6)
0022EE24  00405026  (0A01D0C8, 00000000, 0000003A, 0041FCE2)
0022EEB4  00405579  (0A037B40, 0022EECC, 0000000F, 0040AB01)
0022EF24  0040AC93  (0A037B40, 0022EF44, 0040A4D7, 0040A6D8)
0022EF94  0040A8B2  (0022F01C, 0022F020, 00000000, 00000060)
0022F024  004052DC  (00000000, 0A01E5D0, FFFFFFFF, 7102D024)
0022F054  00405C46  (0A01E5D0, 00000000, 0A037678, 004165D6)
0022F094  00405026  (0A01E5A0, 00000000, 0000003A, 00419E18)
0022F124  00405579  (00000000, 0A01CF50, 0000002C, 00000000)
0022F214  00417F17  (0022F264, 00000001, 0022F284, 00417143)
0022F284  00417170  (0A01D110, 00000001, 00000007, 00000000)
End of stack trace (more stack frames may be present) 

 --- make.exe.stackdump 2 --- 

MSYS-1.0.11 Build:2009-07-11 17:46
Exception: STATUS_ACCESS_VIOLATION at eip=0040FFA6
eax=00000004 ebx=7111027C ecx=7109BB5C edx=0022EA08 esi=FFFFFFFF 
edi=00000000
ebp=0022EA44 esp=0022EA1C 
program=C:\SlantSix\phaedo\buildbot\bs-vm1\demo\xpframework\External\common\ 
msys\1.0.11\bin\make.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022EA44  0040FFA6  (00000006, 0A033410, 000000C8, 0040A21B)
0022EA64  7108468A  (00000006, 0A033410, 000000C8, 0040A19B)
0022EB24  0040A25B  (0A01E268, 0022EB3C, 0040A513, 0040A6D8)
0022EB94  0040A8B2  (0022EC1C, 0022EC20, 00000000, 7108C3A3)
0022EC24  004052DC  (00000000, 0A01DF10, FFFFFFFF, 0A01E210)
0022EC54  00405C46  (0A01DF10, 00000000, 0A01E110, 004165D6)
0022EC94  00405026  (0A01D128, 00000000, 0000003A, 0041FCE2)
0022ED24  00405579  (0A01E610, 0022ED3C, 0000000F, 0040AB01)
0022ED94  0040AC93  (0A01E610, 0022EDB4, 0040A4D7, 0040A6D8)
0022EE04  0040A8B2  (0022EE8C, 0022EE90, 00000000, 00000009)
0022EE94  004052DC  (00000000, 0A01E5D7, FFFFFFFF, 7105B2E4)
0022EEC4  00405C46  (0A01E5D7, 00000000, 0A01E5C8, 00420F5F)
0022EF34  00420A63  (0022F0E8, 0A01DE40, 0A01E5D7, 00000002)
0022EF94  00421876  (0022F0E8, 0A01E5C8, 00000002, 00000000)
0022F084  00417DA5  (0022F0D4, 00000001, 0022F0F4, 00417143)
0022F0F4  00417170  (0A01D838, 00000001, 00000007, 00421AA2)
End of stack trace (more stack frames may be present) 

 ---- 

Thanks,
Dean Giberson

On Monday 27 July 2009 18:27:17 Mark wrote:
> One particular gotcha in setjmp is when the stack is too modified
> at resume; for instance when resuming after a function is already
> complete; without seeing the actual code that is upsetting you,
> I'd say it would be possible that compiler optimization makes the
> difference between the cases

It isn't even certain that setjmp is involved at all.  The OP seems 
to have jumped to a conclusion that the switch from SJLJ exception 
handling to the Dwarf-2 model is somehow responsible, but that 
clearly isn't the case, because there is no exception handler in 
play; (the code is C, and the EH model is exclusive to C++).

Since we haven't been shown any code, or even any diagnostics, we 
really can't offer anything but sheer speculation anyway.

-- 

Regards,
Keith.

Hello!

>> question: Should the
>>   separate automake and autoconf and the corresponding wrapper packages
>> from the download
>>   page (which currently gives me a 500, so I cannot give the concrete
>> package names :-/)
>>   be depacked into the mingw directory (which I did)? 

> Yes.

OK. Btw., the packages I installed were:
* autoconf-6-1-mingw32-bin.tar.lzma
* autoconf2.5-2.63-1-mingw32-bin.tar.lzma
* automake1.10-1.10.2-1-mingw32-bin.tar.lzma
* automake1.11-1.11-1-mingw32-bin.tar.lzma
* automake-4-1-mingw32-bin.tar.lzma

I started using only autoconf 2.5 and automake 1.11 and the wrappers but
than got errors that automake 1.10 was not found so I installed it also
(but I think I remeber later on to get hints in warnings that 1.11 was
used). Should I either install automake 1.10 or 1.11 next time? I
assumed the wrapper would handled parallel installs!?

>> Are there any things
>> I need to be aware
>>   of if I do so?
> 
> No. Except read /mingw/share/doc/MinGW/libtool-*.RELEASE_NOTES.

Good hint, since it looks like I installed the mingwPORT version
(because I remembered that this was version I used for 3.x.x). Seems
like there is one more reason for a fresh and clean reinstall and
install the correct packages.

> I'd export
>    gl_cv_cc_visibility=no
> (or the appropriate autoconf variable; check your configure script)
> before configuring.  Alternatively, modify your code to only use the
> visibility flags if HAVE_VISIBILITY && !(__CYGWIN__ || __MINGW32__)
> 
>>   Should the visibility feature be used under Windows at all?
> 
> IMO, no.

OK. Clear answer. I will try to modify either the configure.ac or my
defines.

>> * I get a linking error because of not finding the std library. Googling
[...]

> See the bottom of /mingw/share/doc/MinGW/libtool-*.RELEASE_NOTES.

OK. So I'll add "-static-libstdc++" to my configure.ac for windows &
mingw and will patch as described.

> But that's just too ugly for words.  suggestions (and especially,
> patches) welcome...

I generally have no fear in hacking in foreign code but libtool is to
big dragon on a big hill deep in unknown land for me to fight against ;-)

Many thanks for the fast and helpful answer!

-- 
Gruß...
       Tim

Keith Marshall wrote:
> On Monday 27 July 2009 09:14:53 leledumbo wrote:
>   
>>> I've already given you one example of why that might be.  Did
>>> you read it?
>>>       
>> Uh-huh, though I believe that's not the cause.
>>     
>
> Maybe not that, exactly, but likely something similar -- invalid 
> source code, which results in different undefined behaviour with 
> different compilers.
>   
One particular gotcha in setjmp is when the stack is too modified at
resume; for instance when resuming after a function is already complete;
without seeing the actual code that is upsetting you, I'd say it would
be possible that compiler optimization makes the difference between the
cases

Best regards

Mark

http://www.halloit.com

Key ID 046B65CF

On Monday 27 July 2009 09:14:53 leledumbo wrote:
> > I've already given you one example of why that might be.  Did
> > you read it?
>
> Uh-huh, though I believe that's not the cause.

Maybe not that, exactly, but likely something similar -- invalid 
source code, which results in different undefined behaviour with 
different compilers.

-- 

Regards,
Keith.