Yaakov S (Cygwin Ports) wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerrit P. Haase wrote:
As long as GCC does not support recent libtool versions it is not easy
to build dynamic libraries.
What about just replacing the autogenerated libtool script with a newer
one (manually hacked
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerrit P. Haase wrote:
> As long as GCC does not support recent libtool versions it is not easy
> to build dynamic libraries.
What about just replacing the autogenerated libtool script with a newer
one (manually hacked if necessary for options) after
On Thu, 6 Oct 2005, Gerrit P. Haase wrote:
> I will probably use the flag to rebuild gcc with this changed libstdc++,
> regardless if there is a performance issue or not.
What about Danny Smith's suggestion ?
http://www.cygwin.com/ml/cygwin/2005-10/msg00080.html
--
Unsubscribe info: http:
Pavel Tsekov wrote:
On Wed, 5 Oct 2005, Gerrit P. Haase wrote:
Pavel Tsekov wrote:
I'll try to rebuild libstdc++ now with _GLIBCXX_FULLY_DYNAMIC_STRING
defined and will report back if there is interest. I would like to help
to get this issue resolved.
Yes, much appreciated. Please CC me
On Wed, 5 Oct 2005, Gerrit P. Haase wrote:
> Pavel Tsekov wrote:
>
> > I'll try to rebuild libstdc++ now with _GLIBCXX_FULLY_DYNAMIC_STRING
> > defined and will report back if there is interest. I would like to help
> > to get this issue resolved.
>
> Yes, much appreciated. Please CC me when you
Pavel Tsekov wrote:
On Tue, 4 Oct 2005, James R. Phillips wrote:
Does fixing this bug require upstream intervention, or can you just develop a
patch, and submit it to upstream?
If it is only the std::string implementation that uses the described
optimization the problem can be worked aroun
James R. Phillips wrote:
Does fixing this bug require upstream intervention, or can you just develop a
patch, and submit it to upstream?
A patch would be nice!
Anecdotal evidence [1] exists that this issue may be what prevents compiling a
working version of octave 2.1.71 with gcc 3.4.4. Th
On Tue, 4 Oct 2005, James R. Phillips wrote:
> Does fixing this bug require upstream intervention, or can you just develop a
> patch, and submit it to upstream?
If it is only the std::string implementation that uses the described
optimization the problem can be worked around by just rebuilding li
James R. Phillips wrote:
John also wonders [2] why libstdc++ is static as opposed to shared on cygwin.
I have searched the archives, and verified its static nature, but was unable to
find an explanation.
[1] http://www.octave.org/mailing-lists/help-octave/2005/3734
[2] http://www.octave.org/mai
Does fixing this bug require upstream intervention, or can you just develop a
patch, and submit it to upstream?
Anecdotal evidence [1] exists that this issue may be what prevents compiling a
working version of octave 2.1.71 with gcc 3.4.4. This comes from John Ewing
(octave upstream), who states
Pavel Tsekov wrote:
Can we get this fixed ?
I entered a bugreport:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
Gerrit
--
=^..^=
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygw
Hello,
I noticed the following problem while porting an internal C++ application
from linux to Cygwin. If a std::string instance created in one module
(exe or dll) is passed to another say as an argument of a function call,
the program crashes or hangs. I did debug for a while and it turned
out th
12 matches
Mail list logo
