From: <ade...@si...> - 2009-07-28 17:37:13
|
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 ******************************************* |