[PATCH] setup: gcc-4.x compatibility
This patch fixes several issues compiling setup.exe with gcc-4.x while
retaining compatibility with gcc-3.4, as tested with gcc-mingw-3.4.4-999
and my mingw-gcc-4.5.1 sample build. Once we switch to a proper
mingw-gcc cross-compiler, the only change that will need to be made is
to CC/CXX in doconfigure.
OK to apply?
Yaakov
2010-08-10 Yaakov Selkowitz yselkow...@users.sourceforge.net
Fix compatibility with GCC 4.x.
* Makefile.am (setup_LDFLAGS): Pass -static to compiler instead of
linker so that libgcc is statically linked as well.
(autoload.o): Disable optimization.
* localdir.cc (browse_cb): Fix jump to case label crosses
initialization error.
* mklink2.cc (sfli): Fix non-local variable uses anonymous type
warning.
* ntdll.h: Fix redeclared without dllimport attribute: previous
dllimport ignored warnings.
* package_message.h (display): Fix 'exit' was not declared in this
scope error.
Index: Makefile.am
===
RCS file: /cvs/cygwin-apps/setup/Makefile.am,v
retrieving revision 2.81
diff -u -r2.81 Makefile.am
--- Makefile.am 8 Apr 2010 15:50:38 - 2.81
+++ Makefile.am 23 Jul 2010 17:01:14 -
@@ -114,7 +114,7 @@
libinilex.a \
libgetopt++/libgetopt++.la -lgcrypt -lgpg-error \
-lshlwapi -lcomctl32 -lole32 -lwsock32 -lnetapi32 -luuid -llzma -lbz2 -lz
-setup_LDFLAGS = -mwindows -Wl,-static -static-libtool-libs
+setup_LDFLAGS = -mwindows -Wc,-static -static-libtool-libs
setup_SOURCES = \
AntiVirus.cc \
AntiVirus.h \
@@ -283,6 +283,9 @@
libmd5-rfc/md5.c \
libmd5-rfc/md5.h
+# autoload code does not optimize well
+autoload.o: CFLAGS += -O0
+
VER := $(shell sed -ne 's/^\$$Revi[s]ion: *\([^ ]*\) *$$.*/\1/p' \
$(srcdir)/ChangeLog)
Index: localdir.cc
===
RCS file: /cvs/cygwin-apps/setup/localdir.cc,v
retrieving revision 2.36
diff -u -r2.36 localdir.cc
--- localdir.cc 2 Feb 2010 17:28:10 - 2.36
+++ localdir.cc 23 Jul 2010 17:01:14 -
@@ -152,12 +152,14 @@
SendMessage (h, BFFM_SETSELECTION, TRUE, (LPARAM) local_dir.c_str());
break;
case BFFM_SELCHANGED:
- // Make a note of each new dir we successfully select, so that
- // we know where to create the new directory if an invalid name
- // is entered in the text box.
- LPITEMIDLIST pidl = reinterpret_castLPITEMIDLIST(lp);
- SHGetPathFromIDList (pidl, dirname);
- break;
+ {
+// Make a note of each new dir we successfully select, so that
+// we know where to create the new directory if an invalid name
+// is entered in the text box.
+LPITEMIDLIST pidl = reinterpret_castLPITEMIDLIST(lp);
+SHGetPathFromIDList (pidl, dirname);
+break;
+ }
case BFFM_VALIDATEFAILED:
// See if user wants to create a dir in the last successfully-selected.
CHAR tempname[MAX_PATH];
Index: mklink2.cc
===
RCS file: /cvs/cygwin-apps/setup/mklink2.cc,v
retrieving revision 2.11
diff -u -r2.11 mklink2.cc
--- mklink2.cc 18 Dec 2009 11:59:54 - 2.11
+++ mklink2.cc 23 Jul 2010 17:01:14 -
@@ -111,7 +111,7 @@
: mkcygsymlink_9x (from, to);
}
-struct {
+static struct {
FILE_LINK_INFORMATION fli;
WCHAR namebuf[32768];
} sfli;
Index: ntdll.h
===
RCS file: /cvs/cygwin-apps/setup/ntdll.h,v
retrieving revision 2.2
diff -u -r2.2 ntdll.h
--- ntdll.h 13 May 2009 11:28:34 - 2.2
+++ ntdll.h 23 Jul 2010 17:01:14 -
@@ -14,6 +14,8 @@
#ifndef SETUP_NTDLL_H
#define SETUP_NTDLL_H
+#define NTOSAPI
+
#include ddk/ntapi.h
#include ddk/ntifs.h
Index: package_message.h
===
RCS file: /cvs/cygwin-apps/setup/package_message.h,v
retrieving revision 1.2
diff -u -r1.2 package_message.h
--- package_message.h 22 Dec 2009 16:19:51 - 1.2
+++ package_message.h 23 Jul 2010 17:01:14 -
@@ -15,6 +15,7 @@
#include UserSettings.h
#include state.h
+#include stdlib.h
#include windows.h
class packagemessage
Re: [PATCH] setup: gcc-4.x compatibility
On Tue, Aug 10, 2010 at 02:46:11PM -0500, Yaakov (Cygwin/X) wrote: This patch fixes several issues compiling setup.exe with gcc-4.x while retaining compatibility with gcc-3.4, as tested with gcc-mingw-3.4.4-999 and my mingw-gcc-4.5.1 sample build. Once we switch to a proper mingw-gcc cross-compiler, the only change that will need to be made is to CC/CXX in doconfigure. OK to apply? Yes. Thanks. cgf
real native win32 binaries with gcc 4.x
Hello, is there meanwhile a solution for compiling real native win32 binaries with gcc 4.3.x? I mean something like the -mno-cygwin linker switch within the gcc 3.x compiler collection/tools Or how does a makefile looks like, if I want to compile real native win32 executables with gcc = 4.3.x? Does anybody has a small example makefile/prog, which demonstrates the use of the switches with gcc 4.x? Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: real native win32 binaries with gcc 4.x
On 08/09/2009 04:47 PM, Thomas Steinbach wrote: Hello, is there meanwhile a solution for compiling real native win32 binaries with gcc 4.3.x? I mean something like the -mno-cygwin linker switch within the gcc 3.x compiler collection/tools Or how does a makefile looks like, if I want to compile real native win32 executables with gcc = 4.3.x? Does anybody has a small example makefile/prog, which demonstrates the use of the switches with gcc 4.x? The cross-compiler is not available as yet. It's still in the works. In the meantime, you can use 'gcc-3' and '-mno-cygwin'. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
1.5.25-7: sh.exe crashes while building gcc.gnu.org svn for gcc 4.x
Hello cygwin, I still getting pretty bad thing from sh.exe, it frequently crashes on my system while building different versions of gcc 4.x. But now, after i have been tring to build *4.3* version, sh.exe begin crashes more frequently than ever before, so i thinks that is problem of building gcc itself.. :( Here is my steps to build gcc 4.3: configure --enable-languages=c,c++,objc ... make -- Best regards, Andry mailto:[EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc 4.x for Cygwin?
Dave Korn wrote: Option 2. I don't see there's any other sensible choice. Ultimately I guess I'd like to figure out a way to make unwinding and exceptions interwork with the native SEH to address the potential downside. (1) There was supposed to be a Google Summer of Code project addressing SEH in gcc. It was listed as an accepted project here: http://gcc.gnu.org/wiki/SummerOfCode But nothing seems to have actually happened, to judge by http://code.google.com/soc/2007/gcc/about.html (2) Curious: does using a -dw2 compiler work when linking against code that was compiled using an sjlj compiler? e.g. in a static library or in a shared library? Like cygwin1.dll? Or, because cygwin1.dll exposes a very C-ish (not C++-ish) interface, then what about other C++ libraries, such as xerces or ncurses++? If the answers to the questions above are bad, then is the (official, non-experimental) release of a gcc-4.x-dw2 compiler something that should wait until cygwin-1.7, with all of the backward-incompatibility he** implied by bad answers? -- Chuck P.S. sorry for the delay in responding. I've been effectively offline for several weeks (work+family).
Re: gcc 4.x for Cygwin?
Charles Wilson wrote: (2) Curious: does using a -dw2 compiler work when linking against code that was compiled using an sjlj compiler? e.g. in a static library or in a shared library? I suppose this all depends on the nature of the code. If you can get yourself into a situation where the Dwarf unwinder encounters a frame in the sjlj library when processing a throw, then it's got no choice but to terminate with an abort. Like cygwin1.dll? Or, because cygwin1.dll exposes a very C-ish (not C++-ish) interface, then what about other C++ libraries, such as xerces or ncurses++? I don't think this matters so much for Cygwin as it's built entirely with -fno-exceptions -fno-rtti and so it's EH-agnostic. But for existing C++ libraries I think the EH flavor may be a moot point because of another issue: if we go with shared libstdc++ (and to me everything indicates that we will need this for both performance and correctness) then those libraries will have to be rebuilt anyway even if EH doesn't change. Consider what happens if you have an existing C++ library built as a DLL with current g++ 3.4. Since the only option right now is static libstdc++, that means any libstdc++ code that the library needs is statically included in the DLL. Now consider that we get a g++ 4.3 that has a shared libstdc++, and you use that to create an .exe that links to that existing C++ library. Now you have (old library + its statically linked libstdc++ 3.4) linked to (new app + shared libstdc++ 4.x) which results in two different simultaneous versions of libstdc++ being present at runtime which sounds like a recipe for true horror if e.g. the main module and the library need to pass around std::string datastructures or whatnot. Once we pull the trigger on shared target libs I think there will be a period of instability during which we have to work out all these nightmares of libgcc and libstdc++ incompatibilities, but it's really something that we just have to grin and bear. Also this isn't exactly a new condition per se: remember that g++ changed ABIs between 3.3 and 3.4, so any C++ libraries would have had to have been rebuilt when we made that transition as well. I don't remember a whole lot of fuss back then (but maybe I just wasn't paying very close attention) which leads me to think that the number of actual C++ libraries in the distro may be small. Or maybe we just have a lot more packages today than we did then so it's an invalid comparison. Brian
RE: gcc 4.x for Cygwin?
On 29 November 2007 17:09, Corinna Vinschen wrote: On Nov 27 18:38, Corinna Vinschen wrote: Now for something completely different: Did anything happen in the gcc 4.x world which would help us to get a gcc 4.x for Cygwin at one point? Are some of the problems reported in http://sourceware.org/ml/cygwin-apps/2006-05/msg00044.html fixed in the meantime? As for Charles' options how to go on: (1) either you drop ada and java support, and we live with the ever-increasing brokenness that will accumulate in the sjlj code, or (2) you switch to dwarf2, we keep ada and java, but loose the callback stuff and break backward compatibility. (3) you release TWO entire SETS of compilers: an sjlj one with only C/C++/Fortran, and a real one with DWARF2 and the full compiler suite. This is a support nightmare; I recommend against. I'd opt for option 2. Dave? Any opinion from the gcc maintainer? Option 2. I don't see there's any other sensible choice. Ultimately I guess I'd like to figure out a way to make unwinding and exceptions interwork with the native SEH to address the potential downside. cheers, DaveK -- Can't think of a witty .sigline today
RE: gcc 4.x for Cygwin?
On 29 November 2007 17:09, Corinna Vinschen wrote: Dave? Any opinion from the gcc maintainer? My opinion is I'll have time to catch up on this thread at the weekend but I've been in crisis-release-deadline-firefighting mode all week and really need to get a night with more than three hours' sleep first. Sorry for not being more responsive. cheers, DaveKzzsnorkgRMMGF I WAS JUST RESTING MY EYES HONEST! -- Can't think of a witty .sigline today
Re: gcc 4.x for Cygwin?
On Nov 29 17:15, Dave Korn wrote: On 29 November 2007 17:09, Corinna Vinschen wrote: Dave? Any opinion from the gcc maintainer? My opinion is I'll have time to catch up on this thread at the weekend but I've been in crisis-release-deadline-firefighting mode all week and really need to get a night with more than three hours' sleep first. Sorry for not being more responsive. Ok. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gcc 4.x for Cygwin?
On Nov 27 18:38, Corinna Vinschen wrote: Now for something completely different: Did anything happen in the gcc 4.x world which would help us to get a gcc 4.x for Cygwin at one point? Are some of the problems reported in http://sourceware.org/ml/cygwin-apps/2006-05/msg00044.html fixed in the meantime? As for Charles' options how to go on: (1) either you drop ada and java support, and we live with the ever-increasing brokenness that will accumulate in the sjlj code, or (2) you switch to dwarf2, we keep ada and java, but loose the callback stuff and break backward compatibility. (3) you release TWO entire SETS of compilers: an sjlj one with only C/C++/Fortran, and a real one with DWARF2 and the full compiler suite. This is a support nightmare; I recommend against. I'd opt for option 2. Dave? Any opinion from the gcc maintainer? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gcc 4.x for Cygwin?
On Tue, 27 Nov 2007 18:38:15 +0100 FWIW, my 2 cents: Corinna Vinschen wrote: As for Charles' options how to go on: (1) either you drop ada and java support, and we live with the ever-increasing brokenness that will accumulate in the sjlj code, or (2) you switch to dwarf2, we keep ada and java, but loose the callback stuff and break backward compatibility. (3) you release TWO entire SETS of compilers: an sjlj one with only C/C++/Fortran, and a real one with DWARF2 and the full compiler suite. This is a support nightmare; I recommend against. I'd opt for option 2. Dave? Charles? Anybody? I am also inclined towards preferring option 2. In my case, I have no interest in the ada or java compiler components, and as yet use cygwin for GUI work very little or nil. From what I understand of the issues, dwarf2 exception handling is the far cleaner approach, contrasted with sjlj. The jump from release 3 to release 4 GCC seems like the right time to make a switch that might confound some user's uninformed expectations (i.e. What? You mean I cannot just switch from gcc-3.x.x to gcc-4.x.x on Cygwin without knowing about ramifications?). If the switch isn't made at the 3-4 transition boundary it becomes that much less easily remembered and communicated to users as they come along. I'm also in agreement with the notion expressed by Brian Dessent (in [EMAIL PROTECTED]): [...] switch to DW2 exception handling as default for all of Cygwin and then think about providing a fallback/parallel installation sjlj package for anyone doing Win32 GUI stuff. Not that I suggest it would be a trivial effort for someone to support such a parallel package; but if someone was *willing* to do so it seems like a solution that would provide options valuable to some Cygwin users. Regards. -- All unaccompanied children will be given espresso and a free kitten. -- Find out how you can get spam free email. http://www.bluebottle.com/tag/3
gcc 4.x for Cygwin?
Now for something completely different: Did anything happen in the gcc 4.x world which would help us to get a gcc 4.x for Cygwin at one point? Are some of the problems reported in http://sourceware.org/ml/cygwin-apps/2006-05/msg00044.html fixed in the meantime? As for Charles' options how to go on: (1) either you drop ada and java support, and we live with the ever-increasing brokenness that will accumulate in the sjlj code, or (2) you switch to dwarf2, we keep ada and java, but loose the callback stuff and break backward compatibility. (3) you release TWO entire SETS of compilers: an sjlj one with only C/C++/Fortran, and a real one with DWARF2 and the full compiler suite. This is a support nightmare; I recommend against. I'd opt for option 2. Dave? Charles? Anybody? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gcc 4.x for Cygwin?
Corinna Vinschen wrote:
Did anything happen in the gcc 4.x world which would help us to get a
gcc 4.x for Cygwin at one point? Are some of the problems reported in
http://sourceware.org/ml/cygwin-apps/2006-05/msg00044.html fixed in the
meantime?
Mainline gcc still won't build shared target libraries on Win32, which
means exceptions across DLLs is still broken. Grumble. Danny's 4.2
MinGW test release has shared libgcc and shared libstdc++ but it was
done by hand by him, by some ugly kind of extract objects from lib.a
and relink dll thing. It would be great to get this finally solved
upstream so we can stop suffering all the negative consequences that
static target libs bring -- static libgcj for example makes the Java
exceptions stuff really broken, from what I understand, making it nearly
unusable.
MinGW has it doubly bad here in that it's hard for them to make shared
libgcc default because everyone using MinGW is all about making
standalone binaries and hate having to distribute some libgcc_s.dll
file. However for us, there is no good reason why we shouldn't make
shared {libgcc,libgfortran,libstdc++,libgomp} the default since we have
a packaging system. This will make it a little easier since the specs
file is already designed to work this way, having e.g. a -static-libgcc
override for when you need it, but not the other way around.
I think it would be prudent just to ignore ada and java for the time
being; there's no reason for them to hold up C/C++/fortran. Danny's
MinGW 4.2 preview omitted java but not ada. They could be filled in
later, if for example somebody interested in shoring up upstream for
Win32 gets on the ball.
I believe that dllimport on forward declarations of classes has been
fixed; there was a major rewrite of the dllimport/export handling code.
The DW2/SJLJ thing still looms of course. I'd be tempted to say we
switch to DW2 exception handling as default for all of Cygwin and then
think about providing a fallback/parallel installation sjlj package for
anyone doing Win32 GUI stuff. This is kinda what Danny did as well.
The final (somewhat embarrassing) thing is that the last time I tried
building Cygwin itself with gcc 4.x it was impossible to get something
that didn't crash hard at startup due to aliasing booboos, even with
-fno-strict-aliasing. But that may have changed, I haven't tried in a
long while.
Brian
Re: gcc 4.x for Cygwin?
Corinna Vinschen wrote: Now for something completely different: Did anything happen in the gcc 4.x world which would help us to get a gcc 4.x for Cygwin at one point? Are some of the problems reported in http://sourceware.org/ml/cygwin-apps/2006-05/msg00044.html fixed in the meantime? As for Charles' options how to go on: (1) either you drop ada and java support, and we live with the ever-increasing brokenness that will accumulate in the sjlj code, or (2) you switch to dwarf2, we keep ada and java, but loose the callback stuff and break backward compatibility. (3) you release TWO entire SETS of compilers: an sjlj one with only C/C++/Fortran, and a real one with DWARF2 and the full compiler suite. This is a support nightmare; I recommend against. I'd opt for option 2. Dave? Charles? Anybody? FWIW, I would opt for dwarf2 Corinna -- Roger Wells, P.E. SAIC 221 Third St Newport, RI 02840 401-847-4210 (voice) 401-849-1585 (fax) [EMAIL PROTECTED]
GCC 4.x for cygwin
Where can I find it? (From the installer it seems that the latest available version is 3.4.4, but this is really unusable for serious C++ development.) All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC 4.x for cygwin
Roberto Bagnara wrote: Where can I find it? (From the installer it seems that the latest available version is 3.4.4, but this is really unusable for serious C++ development.) There's too much on this subject in the archives to be summarized. Why not look yourself? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc 4.x?
There is an email thread from 2006 to this topic: http://cygwin.com/ml/cygwin/2006-03/msg00507.html I have compiled my own GCC 4.2.0 for cygwin, but not tested and not really used it a lot. And I must admit that what Charles et al were talking about is not my core expertise. I would appreciate any status update on 4.x, too. Brian Hassink wrote: Just curious what the issues are that are holding up [..] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc 4.x?
My apologies, I must have missed the latest one about GCC 4.2.0 RC3 for some reason, sorry. Tom wrote: There is an email thread from 2006 to this topic: http://cygwin.com/ml/cygwin/2006-03/msg00507.html I have compiled my own GCC 4.2.0 for cygwin, but not tested and not really used it a lot. And I must admit that what Charles et al were talking about is not my core expertise. I would appreciate any status update on 4.x, too. Brian Hassink wrote: Just curious what the issues are that are holding up [..] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
gcc 4.x with libmudflap - is it possible on cygwin?
Good day. I trying to compile gcc (4.1.1 release and 4.2 from snapshot) and it's all ok, but i can't compile it with mudflap library: checking for the name of the symbol used for the entry point... unknown configure: error: none of the known symbol names works make[1]: *** [configure-target-libmudflap] Error 1 Is it possible to fix something in configure script, or it's not cygwin problem? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
gcc 4.x?
Just curious what the issues are that are holding up the release of a gcc 4.x package? Thanks, Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC 4.x+
Brian Dessent wrote: Angelo Graziosi wrote: I have built GCC-3.4.6, 4.0.3, 4.1.0 in this way (using the Cygwin GCC-3.4.4-1): ./configure --prefix=/usr/local/gcc-3.4.6 (or 4.0.3, 4.1.0) make make install I like to use --enable-version-specific-runtime-libs because it seems cleaner and that's the way the Cygwin gcc packages do it. I also use --disable-nls since I don't care for those dozens of various message catalog files for languages I don't speak. You will also need --enable-sjlj-exceptions if you ever plan to compile code that could throw an exception inside a stack frame containing foreign (non-DW2-enabled) compiled code, such as a win32 callback. This can be common in win32 GUI applications, but not an issue if you don't use C++ exceptions and/or you don't write code that could be called from a win32 callback. The dwarf2 EH is a lot faster too. I thought there were some patches to the cygwin gcc 3.4.x version that had not yet been migrated to the official sources? I'd be glad to be wrong, however. Also, wasn't there some issue with the std::string implementation that was causing problems for both cygwin-special and mingw-special g++? Otherwise, if it's so simple, I don't understand why Gerrit hasn't released gcc-4.x as a test version, nor [OT:] why Danny hasn't released a gcc-4.0 candidate for mingw. Other than we're just mean. :-) I mean, hey, they're volunteers and far be it from me to criticize, given my lackluster record as a maintainer of late...but somehow I doubt that it's really as easy as you claim -- otherwise those two guys woulda done it by now. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC 4.x+
Charles Wilson wrote: Brian Dessent wrote: Angelo Graziosi wrote: I have built GCC-3.4.6, 4.0.3, 4.1.0 in this way (using the Cygwin GCC-3.4.4-1): ./configure --prefix=/usr/local/gcc-3.4.6 (or 4.0.3, 4.1.0) make make install I like to use --enable-version-specific-runtime-libs because it seems cleaner and that's the way the Cygwin gcc packages do it. I also use --disable-nls since I don't care for those dozens of various message catalog files for languages I don't speak. You will also need --enable-sjlj-exceptions if you ever plan to compile code that could throw an exception inside a stack frame containing foreign (non-DW2-enabled) compiled code, such as a win32 callback. This can be common in win32 GUI applications, but not an issue if you don't use C++ exceptions and/or you don't write code that could be called from a win32 callback. The dwarf2 EH is a lot faster too. I thought there were some patches to the cygwin gcc 3.4.x version that had not yet been migrated to the official sources? I'd be glad to be wrong, however. Also, wasn't there some issue with the std::string implementation that was causing problems for both cygwin-special and mingw-special g++? Otherwise, if it's so simple, I don't understand why Gerrit hasn't released gcc-4.x as a test version, nor [OT:] why Danny hasn't released a gcc-4.0 candidate for mingw. We don't appear to have a full concensus even on the build options, although copying some of the options which appear in cygwin special gcc might be a start. Also, as pointed out above, building standard gcc out of the box doesn't enable all of the features required of cygwin. At least a few of those versions mentioned above include the option to build treelang, enabling the option -ftree-vectorize. For me, this passes all of gcc-testsuite, but still exhibits some serious problems which I can't reproduce in linux. I haven't succeeded in building libstdc++ for gcc-4.1 or 4.2. Maybe the discussion above implies a few others have seen the same problem. That would be enough to explain to me why such a version hasn't appeared in cygwin, even if it's a relatively simple patch (maybe even trivially obvious to someone). I've heard of some reluctance among gcc developers to continue support for cygwin. There seems to be a lack of interest in problem solving, or in overcoming the binutils bottleneck in the way of a 64-bit native cygwin. I see some effort toward making gcc-4.2 gomp work for cygwin, thus some counter to the pessimism I just expressed. otNo doubt, the reported 4% market penetration of 64-bit Windows may be dissuading some from thinking Windows has much prospect for near term progress. When Microsoft cc'd me an e-mail suggesting a $30,000 budget for each customer to find out how to run CCS, my own doubts were hardly put to rest. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC 4.x+
On Fri, Mar 17, 2006 at 10:55:53PM -0800, Tim Prince wrote: I've heard of some reluctance among gcc developers to continue support for cygwin. There seems to be a lack of interest in problem solving, or in overcoming the binutils bottleneck in the way of a 64-bit native cygwin. Huh? Could you point me at a developer who is expressing reluctance? I know most of them and hang out on the gcc irc channel and no one has said anything to me. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC 4.x+
Brian Dessent wrote: The dwarf2 EH is a lot faster too Does this mean to use: --with-dwarf2 option in 'configure'? Thanks a lot, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC 4.x+
Angelo Graziosi wrote: The dwarf2 EH is a lot faster too Does this mean to use: --with-dwarf2 option in 'configure'? No, that's setting the default debug symbol type to dwarf2 instead of stabs (I think). You get dwarf2 exception handling by default without having to specify anything unless you override with --enable-sjlj-exceptions. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
GCC 4.x+
Hi, is there a plan to move Cygwin over to newer GCC? GCC 3.4.4 is getting old. I could use the strictness of C++ compiler it brings. Vaclav Haisman signature.asc Description: OpenPGP digital signature
Re: GCC 4.x+
Václav Haisman wrote: is there a plan to move Cygwin over to newer GCC? GCC 3.4.4 is getting old. I could use the strictness of C++ compiler it brings. There's no reason why you can't build gcc 4.x on your own, it works fine in Cygwin. If you pick a proper --prefix (or use --program-suffix and --enable-version-specific-runtime-libs) it will be completely separate from the installed version of gcc, you can use the two side by side. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC 4.x+
Brian Dessent wrote: If you pick a proper --prefix (or use --program-suffix and --enable-version-specific-runtime-libs) it will be completely separate from the installed version of gcc, you can use the two side by side. I have built GCC-3.4.6, 4.0.3, 4.1.0 in this way (using the Cygwin GCC-3.4.4-1): ./configure --prefix=/usr/local/gcc-3.4.6 (or 4.0.3, 4.1.0) make make install May you suggest other optimal options for 'configure' ? Thanks, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC 4.x+
Angelo Graziosi wrote: I have built GCC-3.4.6, 4.0.3, 4.1.0 in this way (using the Cygwin GCC-3.4.4-1): ./configure --prefix=/usr/local/gcc-3.4.6 (or 4.0.3, 4.1.0) make make install I like to use --enable-version-specific-runtime-libs because it seems cleaner and that's the way the Cygwin gcc packages do it. I also use --disable-nls since I don't care for those dozens of various message catalog files for languages I don't speak. You will also need --enable-sjlj-exceptions if you ever plan to compile code that could throw an exception inside a stack frame containing foreign (non-DW2-enabled) compiled code, such as a win32 callback. This can be common in win32 GUI applications, but not an issue if you don't use C++ exceptions and/or you don't write code that could be called from a win32 callback. The dwarf2 EH is a lot faster too. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
