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
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
(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
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
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
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 textmod
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
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
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
Igor Peshansky wrote:
Sure. This has been discussed on this list a few times this year -- see
the list archives. A Google search for "cygwin dll std:string" should
show some mathces (including a reference to the GCC bug report[*] for
this, which, AFAICS, contains a patch that you can test).
I've run into what appears to be a bug in the g++ toolchain or the STL's
std::string using the latest Cygwin dist (up to date as of right now).
Minimal test case attached.
If my shared library does a callback to a function returning
std::string, and only if the std::string is empty, I get an a
11 matches
Mail list logo
