Re: Fixing the state of C++ in Cygwin

Angelo Graziosi wrote: > Your test case (http://svn.variadic.org/public/trunk/weirdbug/) DOES NOT > abort also if one rebuilds GCC WITHOUT ADDING > --enable-fully-dynamic-string BUT APPLYING the patch PR24196! Yes, that's all in the bug report, but why I'd avoid it is that they were still undecid

Re: Fixing the state of C++ in Cygwin

Steven Brown wrote: > There's simply no way to solve this for all cases without a recompile of > libstdc++. I wrote: > Your test case DOES NOT abort if one builds it with GCC that was rebuilt > whitout that patch but configured with --enable-fully-dynamic-string! Your test case (http://svn

Re: Fixing the state of C++ in Cygwin

Steven Brown wrote: > As an example of why just patching the headers won't work, try to > compile and run my old weirdbug[1] example - type make and run > xxx-cygwin.exe. If it aborts, the problem still exists on your system. I > just tested it, and as expected, simply patching the files like t

Re: Fixing the state of C++ in Cygwin

Angelo Graziosi wrote: After applying the PR24196 patch to basic_string.h and basic_string.tcc, rebuilding ROOT, it works! Possibly ROOT uses a templated form of string other than the ones explicitly instantiated in libstdc++ (char/wchar I believe), as this simply shouldn't work due to the e

Re: Fixing the state of C++ in Cygwin

Steven Brown wrote: > Does rOOt disable explicit instantiation via tweaking > _GLIBCXX_EXTERN_TEMPLATE? I cannot answer this. I am only an user of ROOT (http://root.cern.ch/), not a developer. I know only that it is almost an year that the build made with GCC-3.4.4 do not work. After applyin

Re: Fixing the state of C++ in Cygwin

(resending as the list seems to have eaten it, apologies if it gets duplicated) Angelo Graziosi wrote: > It seems that applying the patch only, without rebuilding GCC works (the > ROOt, a CERN application, problems seem solved). The template is explicitly instantiated in libstdc++, so that shoul

Re: Fixing the state of C++ in Cygwin

Brian Dessent wrote: > Since the patch only touches two libstdc++ include files you *might* be > able to apply it directly to the installed c++ headers without having to > rebuild the compiler from source, but I don't guarantee that that's > possible. It seems that applying the patch only, with

Re: Fixing the state of C++ in Cygwin

Steven Brown wrote: > I could build the packages and fix the sh/diff this weekend given a call > on which path to take - draft patch or --enable-fully-dynamic-string. I > just don't want it to fall through the cracks again This would be very appreciated! If your request is not accepted, may

Re: Fixing the state of C++ in Cygwin

Brian Dessent wrote: I just want to remind everyone that using --enable-fully-dynamic-string will incur a somewhat significant performance hit, and it's the reason this hasn't been set as the default for Cygwin. In the PR there is a patch that is reported to fix the problem without the full per

Re: Fixing the state of C++ in Cygwin

Angelo Graziosi wrote: > May you give some more details? > Where is the patch? It is attached to the PR, see comment #11 or . > How to build applying that? Like any other patch, apply to the source an

RE: Fixing the state of C++ in Cygwin

> From: Angelo Graziosi > > Brian Dessent wrote: > > > In the PR there is a patch that is reported to fix the > problem without > > the full performance hit, so that would be preferable to > use rather than > > the 20-ton hammer > > > May you give some more details? > > Where is the patch?

Re: Fixing the state of C++ in Cygwin

Brian Dessent wrote: > In the PR there is a patch that is reported to fix the problem without > the full performance hit, so that would be preferable to use rather than > the 20-ton hammer May you give some more details? Where is the patch? How to build applying that? Thanks, Angelo

Re: Fixing the state of C++ in Cygwin

On Thu, Apr 27, 2006 at 03:00:05PM -0700, Brian Dessent wrote: >-mno-cygwin ought to work fine from the stock FSF sources I'm told >(provided of course that you build it twice, once as i686-pc-cygwin and >then again as i686-pc-mingw and install them to the same prefix.) I would hope that it does b

Re: Fixing the state of C++ in Cygwin

Dave Korn wrote: > This sounds like an error in your configure arguments getting transcribed > into the generated makefiles to me. It's not an extra '&& )', it's something > missing between the '&&' and the ')' that's the real problem, and that > probably happened because a shell variable used

Re: Fixing the state of C++ in Cygwin

Doyle Rhynard wrote: > Did you have much trouble building gcc-3.4.4-1? I have been trying off > and on for several weeks to get it to build with no errors. > Interestingly, the --enable-fully-dynamic-string is set by default in > the build script. I just want to remind everyone that using --enabl

Re: Fixing the state of C++ in Cygwin

Charles Wilson wrote: > The whole point of the cygwin packaging system is that SUPPOSEDLY, if > you use the packaged script, you can rebuild the package exactly as the > official distributed one was built As I have written (http://cygwin.com/ml/cygwin/2006-04/msg00822.html), I used the packaged

Re: Fixing the state of C++ in Cygwin

On 27-Apr-2006, Angelo Graziosi wrote: | In the Cygwin distribution there are packages like Octave that are | incompatible with gcc-3.4.4-1, yet. Octave on Cygwin would also be helped if libstdc++ were built as a DLL. Has there been any progress on that? Is there anyone else who is interested i

Re: Fixing the state of C++ in Cygwin

Dave Korn wrote: The bash script that does the build will not even run due an error with an extra "&& )" into the install2 option. There is also a problem with a libstdc++ Makefile that might be caused by an error in bash, itself. This sounds like an error in your configure arguments getting

RE: Fixing the state of C++ in Cygwin

On 27 April 2006 06:46, Doyle Rhynard wrote: > Did you have much trouble building gcc-3.4.4-1? I have been trying off > and on for several weeks to get it to build with no errors. > Interestingly, the --enable-fully-dynamic-string is set by default in > the build script. Building gcc on cygwin

Re: Fixing the state of C++ in Cygwin

Doyle Rhynard wrote: > Did you have much trouble building gcc-3.4.4-1? I have been trying off > and on for several weeks to get it to build with no > errors. Interestingly, the --enable-fully-dynamic-string is set by > default in the build script. I have followed these steps: _

Re: Fixing the state of C++ in Cygwin

Angelo Graziosi wrote: There is a CERN application, ROOT, that when it is built with current Cygwin GCC 3.4.4-1, has problems at runtime (hang, stackdump...). But following this http://cygwin.com/ml/cygwin/2006-04/msg00634.html, I have made a build of GCC-3.4.4 that includes --enable-fully-dyna

Re: Fixing the state of C++ in Cygwin

There is a CERN application, ROOT, that when it is built with current Cygwin GCC 3.4.4-1, has problems at runtime (hang, stackdump...). But following this http://cygwin.com/ml/cygwin/2006-04/msg00634.html, I have made a build of GCC-3.4.4 that includes --enable-fully-dynamic-string. This new GC

Re: Fixing the state of C++ in Cygwin

Steven Brown wrote: So, time for phase 2: C++ programs are also affected by gcc bug #24196[1] (passing std::string between exes and dlls), which causes hard to track down crashes. This was discussed in an earlier thread[2] and the conclusion seemed to be that building with --enable-fully-dyn

Re: Fixing the state of C++ in Cygwin

> > The cause of this is apparently /tmp being a textmode mount. If > > switched to binary, cat << EOF works as expected. Is that really what's > > supposed to happen? It doesn't seem right that a system configured to > > act binmode is going textmode just due to using '<< EOF' syntax. > > That

Re: Fixing the state of C++ in Cygwin

Steven Brown wrote: > The cause of this is apparently /tmp being a textmode mount. If > switched to binary, cat << EOF works as expected. Is that really what's > supposed to happen? It doesn't seem right that a system configured to > act binmode is going textmode just due to using '<< EOF' synt

Re: Fixing the state of C++ in Cygwin

Steven Brown wrote: Steven [EMAIL PROTECTED] ~/src $ cat << EOF | file - > foo > EOF /dev/stdin: ASCII text, with CRLF line terminators [...] Is this by design or a bug? It seems like the wrong thing for it to be doing. The cause of this is apparently /tmp being a textmode mount. If swi

Re: Fixing the state of C++ in Cygwin

Corinna Vinschen wrote: On Apr 11 22:35, Steven Brown wrote: I can look into the problem with sed 4.1.5 as well, [...] So the question is this: Is it a textmode/binmode issue and if so, why are the files created with CRLF line endings at all? If they are not created with CRLF line endings

Re: Fixing the state of C++ in Cygwin

On Apr 11 22:35, Steven Brown wrote: > Christopher Faylor wrote: > > >How about figuring out what the "for some reason" is that makes sed 4.1.5 > >(theoretically) fail? > > The thread regarding sed 1.4.5 and libtool: > http://www.cygwin.com/ml/cygwin/2006-02/msg00846.html > > Wouldn't it be best

Re: Fixing the state of C++ in Cygwin

Christopher Faylor wrote: How about figuring out what the "for some reason" is that makes sed 4.1.5 (theoretically) fail? The thread regarding sed 1.4.5 and libtool: http://www.cygwin.com/ml/cygwin/2006-02/msg00846.html Wouldn't it be best to first return to sed 4.1.4 before debugging why up

Re: Fixing the state of C++ in Cygwin

On Tue, Apr 11, 2006 at 09:13:14PM -0700, Steven Brown wrote: >Currently in Cygwin, C++ apps using libtool will fail to build for some >reason due to sed 4.1.5 - you have to downgrade to 4.1.4, which is not >the default being installed. C++ programs are also affected by gcc bug >#24196[1] (pass

Fixing the state of C++ in Cygwin

Currently in Cygwin, C++ apps using libtool will fail to build for some reason due to sed 4.1.5 - you have to downgrade to 4.1.4, which is not the default being installed. C++ programs are also affected by gcc bug #24196[1] (passing std::string between exes and dlls), which causes hard to trac