--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-01-06
15:27 ---
I'm not so sure (that it's cygwin specific).
http://www.google.co.uk/search?q=locale_facets.tcc++internal++error:+Segmentation+fault&hl=en&client=firefox-a&rls=org.mozilla:en-US:of
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-01-15
19:08 ---
I've just run into this problem too.
In earlier versions of Aaron's shared libgcc patch, we extracted ctors.o and
chkstk.o and placed them whole into the import lib. I'm not sure w
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-15
21:18 ---
Created an attachment (id=17109)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17109&action=view)
Order BACKENDLIBS by dependencies.
I'd consider this fix obvious. Verified that it
tatus: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet:
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-01-16
13:41 ---
(In reply to comment #5)
> If you look at the (static) libgcc.a, when shared libs are enabled, it
> contains only symbols that are not exported from the shared dll. Only the
> 'API-stabl
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-01-16
13:43 ---
This bug is fixed and should be closed now. A new PR, bug 37660, has been
created for the separate issue in comment 4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37915
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-01-18
00:17 ---
This is now fixed.
Will file a separate PR later for -lstdc++ problems.
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed |Added
rap failure on Cygwin vs. libiberty.
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-18
00:31 ---
Created an attachment (id=17131)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17131&action=view)
Remove troublesome clause from libiberty configure
Now testing vs. both src/ and gcc/
--
0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-18
00:41 ---
Oh, I forgot to mention a further non-standardness about the DLL's name: on the
Cygwin platform, the shared library version number should be separated from the
name by a hyphen, not an underscore
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-01-18
05:57 ---
Created an attachment (id=17132)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17132&action=view)
Move _ctors* and _chkstk* to import lib
Danny, this is the approach that I think I'd
--- Comment #2 from dave dot korn dot cygwin at gmail dot com 2009-01-18
21:40 ---
Fixed on HEAD by r.143487; sorry, forgot to put the PR/ reference in the SVN
logfile.
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed |Added
--- Comment #9 from dave dot korn dot cygwin at gmail dot com 2009-01-19
04:54 ---
(In reply to comment #8)
> (In reply to comment #7)
> > Created an attachment (id=17132)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17132&action=view) [edit]
> > Move _
--- Comment #11 from dave dot korn dot cygwin at gmail dot com 2009-01-20
04:32 ---
Created an attachment (id=17151)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17151&action=view)
Fill out missing syms from shared libgcc using static libgcc archive.
(In reply to comm
--- Comment #2 from dave dot korn dot cygwin at gmail dot com 2009-01-22
16:42 ---
Created an attachment (id=17163)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17163&action=view)
Fix shared libgcc naming scheme.
Patch now in testing, fixes DLL naming scheme for both Cyg
ures in new stackalign tests
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-23
18:10 ---
Created an attachment (id=17168)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17168&action=view)
Force assembler labels to match.
Now testing this fairly straightforward approach to mak
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-01-23
19:02 ---
Right you are. Either one should work, but I don't have any more spare time
than you for testing things on Linux right now. It's non-critical, so I'll
keep a patch in my local tree and
: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-23
23:31 ---
Created an attachment (id=17169)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17169&action=view)
Simple throw-catch testcase
Test cases don't come much simpler than this.
--- Comment #2 from dave dot korn dot cygwin at gmail dot com 2009-01-23
23:31 ---
Created an attachment (id=17170)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17170&action=view)
Pre-processed source of testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-01-23
23:32 ---
Created an attachment (id=17171)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17171&action=view)
Generated assembler for testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-01-23
23:44 ---
The bug manifests itself as a crash on exit from main(); $eip is set to zero
and we get a SEGV.
On entry to main(), the registers show:
esp0x22cc40 0x22cc40
ebp0x22cca8
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-01-24
00:10 ---
Here is a disassembly of the start of the main function:
(gdb) disass main
Dump of assembler code for function main:
0x00401070 :push %ebp
0x00401071 :mov%esp,%ebp
0x00401073 :and
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-01-24
01:08 ---
Here is the RTL that is created by the .130r.eh pass: everything between note 2
and call_insn 3, was added after expand.
try_optimize_cfg iteration 2
(note 1 0 4 NOTE_INSN_DELETED)
(note 4 1 2 2 [bb 2
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-01-24
06:23 ---
Not IRA-related, it seems, but reload-backend interaction. -fno-ira doesn't
make any difference to the generated code to calculate the frame pointer for
the jmp_buf. In a non-IRA build, pass 172r
--- Comment #9 from dave dot korn dot cygwin at gmail dot com 2009-01-24
18:12 ---
Thanks for the test results and confirmation, Uros. It looks like more or less
exactly the same list of FAILs as I see on Cygwin, so I think this confirms a
generic issue with frame pointer elimination
--- Comment #15 from dave dot korn dot cygwin at gmail dot com 2009-01-24
18:20 ---
[ David B. CC'd in for clarification requested ]
I'm under the impression that the bug is fixed now, so no objections from me.
I'm not sure why David B. just confirmed it though, I mea
--- Comment #17 from dave dot korn dot cygwin at gmail dot com 2009-01-24
23:15 ---
(In reply to comment #16)
> Just ignore my post at comment #13 to update the status. Sorry for the
> noise.
> I should have read to the bottom of the PR before acting.
>
That'
--- Comment #18 from dave dot korn dot cygwin at gmail dot com 2009-01-24
23:22 ---
(In reply to comment #17)
> (In reply to comment #16)
> > Just ignore my post at comment #13 to update the status. Sorry for the
> > noise.
> > I should have read to the bo
--- Comment #11 from dave dot korn dot cygwin at gmail dot com 2009-01-25
05:33 ---
Thanks for your help HJ. I'll do some more debugging and add notes while
you're away. Happy New Year!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
--- Comment #12 from dave dot korn dot cygwin at gmail dot com 2009-01-25
05:56 ---
Created an attachment (id=17177)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17177&action=view)
Correct code compiled with -mpreferred-stack-boundary=2
Adding "-mpreferred-stack-bo
--- Comment #13 from dave dot korn dot cygwin at gmail dot com 2009-01-25
05:58 ---
Created an attachment (id=17178)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17178&action=view)
Diffs between good and bad versions
This shows a diff between the testcase compil
--- Comment #14 from dave dot korn dot cygwin at gmail dot com 2009-01-25
06:05 ---
Adding "-mpreferred-stack-boundary=2" to the command line generates correct
code.
Here are the diffs between code generated by that setting and the default
(-mpreferred-stack-boundary=4) for
--- Comment #15 from dave dot korn dot cygwin at gmail dot com 2009-01-25
06:33 ---
(In reply to comment #14)
> And that is presumably the intention of this if clause in ix86_can_eliminate:
>
> if (stack_realign_fp)
> return ((from == ARG_POINTER_REGNUM
>
--- Comment #16 from dave dot korn dot cygwin at gmail dot com 2009-01-25
06:40 ---
./eh.C: In function 'int main()':
./eh.C:11: internal compiler error: in print_reg, at config/i386/i386.c:10466
Please submit a full bug report,
with preprocessed source if appropriate.
--- Comment #17 from dave dot korn dot cygwin at gmail dot com 2009-01-25
07:47 ---
And this is what I'll try:
-- Target Hook: bool TARGET_BUILTIN_SETJMP_FRAME_VALUE ()
This target hook should return an rtx that is used to store the
address of the current frame int
--- Comment #18 from dave dot korn dot cygwin at gmail dot com 2009-01-25
21:36 ---
Created an attachment (id=17183)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17183&action=view)
Implement TARGET_BUILTIN_SETJMP_FRAME_VALUE.
Now testing this patch which should fix
--- Comment #19 from dave dot korn dot cygwin at gmail dot com 2009-01-25
23:07 ---
Created an attachment (id=17184)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17184&action=view)
Implement TARGET_BUILTIN_SETJMP_FRAME_VALUE *correctly*.
Dur. Corrected patch for retu
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-01-26
09:48 ---
http://gcc.gnu.org/ml/gcc/2009-01/msg00367.html
Confirmed by OP.
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed |Added
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-01-26
09:58 ---
Hi HP,
(In reply to comment #5)
> Glancing at the assembly and simulator trace (no looking at rtl or tree dumps
> yet), the value of "p" (sp after the first alloca) is somehow lost
--- Comment #8 from dave dot korn dot cygwin at gmail dot com 2009-01-26
18:49 ---
Oh, bah, I misread the Host field for Target!
Guess it probably won't be TARGET_BUILTIN_SETJMP_FRAME_VALUE then. You only
need it if your stack frames have unpredicatable gaps in them so that you
--- Comment #21 from dave dot korn dot cygwin at gmail dot com 2009-01-26
19:03 ---
Hi Joey, thanks for helping look at this bug.
If you catch up with all the comments, you'll see that it's not just Cygwin,
SjLj was broken on Linux too; the mechanism works the same w
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-01-31
18:53 ---
Bug fixed.
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed |Added
.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
GCC build triplet: i686-
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-05-08
11:53 ---
Created an attachment (id=17826)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17826&action=view)
Simple testcase
It doesn't get much more trivial than this.
--
http://gcc.gnu.
--- Comment #2 from dave dot korn dot cygwin at gmail dot com 2009-05-08
11:55 ---
To reproduce the bug, compile the attached testcase
g++-4 -fpreprocessed -S vti.ii
and view the very end of the .s file emitted:
.section .drectve
.ascii " -export:_ZTV12XMLExce
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-05-10
01:11 ---
Created an attachment (id=17841)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17841&action=view)
inherit dllexport from class to typeinfo
Now testing a solution based on the approach of
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-05-10
11:17 ---
(In reply to comment #4)
> Hello Dave,
Hi Danny!
> Rather than use DLL linkage (and so force client to resort to auto-import
> magic)
> why not just always emit the RTTI with one-only co
--- Comment #54 from dave dot korn dot cygwin at gmail dot com 2009-05-14
06:25 ---
I've started work on the binutils support for this. Work-in-progress patch at
http://sourceware.org/ml/binutils/2009-05/msg00228.html
Once that's complete, I could deal with the GCC end
--- Comment #56 from dave dot korn dot cygwin at gmail dot com 2009-05-20
04:25 ---
Created an attachment (id=17895)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17895&action=view)
Target option and autoconf test to enable aligned common support.
Currently putting the a
--- Comment #57 from dave dot korn dot cygwin at gmail dot com 2009-05-20
21:16 ---
Bah. In case anyone else was about to point this out to me,
+gcc_GAS_CHECK_FEATURE([.comm with alignment], gcc_cv_as_comm_has_align,
+ [2,19,52],,
+ [.comm foo,1,32],,
+[AC_DEFINE
--- Comment #58 from dave dot korn dot cygwin at gmail dot com 2009-05-23
11:46 ---
Created an attachment (id=17906)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17906&action=view)
Revised patch
Revised version of the patch that defines the autoconf feature test macro
--- Comment #59 from dave dot korn dot cygwin at gmail dot com 2009-05-23
14:08 ---
Created an attachment (id=17909)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17909&action=view)
D'oh. Quick respin.
Huh. Alignment is passed to the backend as number of bits, b
ran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40309
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-05-30
15:01 ---
It's not entirely straightforward, it seems. An earlier attempt appears to
have fizzled out:
http://gcc.gnu.org/ml/fortran/2007-09/threads.html#00289
I do not yet understand Andrew Pinski's
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-05-30
15:19 ---
About to test this:
$ svn diff -x -p fortran/trans-decl.c
Index: fortran/trans-decl.c
===
--- fortran/trans-decl.c(revision
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-05-30
15:34 ---
(In reply to comment #3)
> About to test this:
That was wrong. This is what I should have said:
$ svn diff fortran/trans-decl.c
Index: fortran/trans-dec
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-05-30
15:38 ---
The patch in comment 4 works.
dkad...@ubik /tmp/fortran
$ ./hello-fixed.exe
Hello World!
dkad...@ubik /tmp/fortran
$ gdb ./hello-fixed.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-05-30
16:12 ---
Groan.
PASS: gfortran.dg/Wall.f90 (test for excess errors)
spawn [open ...]
Internal Error: insert(): Duplicate key found!
FAIL: gfortran.dg/Wall.f90 execution test
In other words, exactly what Andrew
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-05-30
17:09 ---
http://gcc.gnu.org/ml/fortran/2009-05/msg00452.html
We have two functions that both match MAIN_NAME_P, because they share the same
DECL_NAME. This happens when there is a "PROGRAM main" di
--- Comment #11 from dave dot korn dot cygwin at gmail dot com 2009-06-01
08:05 ---
I checked the fix and it works. Verified.
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed |Added
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-06-16
11:26 ---
Could you re-run that with --save-temps, and attach the .i, .s, .o and .exe
files to the PR please?
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-06-16
11:40 ---
Already fixed at r.148523, according to:
http://gcc.gnu.org/ml/gcc/2009-06/msg00339.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40456
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-06-25
15:37 ---
Hmm, I'm getting somewhere with this.
By compiling the g++ testsuite "ptrflags.C" case with --save-temps, manually
hacking all the superfluous typeinfo stuff out, and re-assembling an
--- Comment #20 from dave dot korn dot cygwin at gmail dot com 2009-06-29
15:12 ---
I think the best solution to this problem is to enable libstdc++ as a DLL, and
export _S_empty_rep from it. Then every C++ DLL and EXE will link against
libstdc++ and they'll all import the exact
--- Comment #64 from dave dot korn dot cygwin at gmail dot com 2009-07-04
12:47 ---
(In reply to comment #63)
> GCC still generates a segfaulting executable when used with the testcase in
> the
> report, most likely because my assembler doesn't support the 3-argument .co
--- Comment #66 from dave dot korn dot cygwin at gmail dot com 2009-07-04
13:21 ---
(In reply to comment #65)
> Indeed, i should have expected this, and after rereading the comments here you
> even mentioned this problem already. Sorry for the noise.
>
That's OK. G
--- Comment #13 from dave dot korn dot cygwin at gmail dot com 2009-07-04
15:48 ---
This should all be resolved by the fixes applied in the past few days to
binutils CVS HEAD.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40455
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-07-04
15:56 ---
(In reply to comment #4)
> (In reply to comment #2)
> > Might be safer to rename to GNAT_FOPEN or something like that? FOPEN is
> > likely
> > to be taken on more than one platform
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-07-04
16:15 ---
You might like to test this again. It was very likely fixed by the these
patches
http://gcc.gnu.org/viewcvs?view=rev&revision=146425
http://gcc.gnu.org/viewcvs?view=rev&revision=146515
I
--- Comment #15 from dave dot korn dot cygwin at gmail dot com 2009-07-04
23:27 ---
(In reply to comment #14)
> I am on cygwin-1.5. will these fixes get pushed to setup? or am I stuck? or
> is
> there a work around?
Hi Jerry,
I can't answer that question. There is
--- Comment #17 from dave dot korn dot cygwin at gmail dot com 2009-07-04
23:55 ---
It is beta, yeah. But it's a damn good beta :) Can't promise you won't
stumble across a new bug or two, but it's reliable enough for fairly heavy-duty
everyday usage.
--
--- Comment #20 from dave dot korn dot cygwin at gmail dot com 2009-07-05
23:47 ---
(In reply to comment #19)
> (In reply to comment #18)
> > As Dave suggests in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40455#c13,
> > this
> > is fixed,
> >
>
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libffi
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40807
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-07-19
17:50 ---
(In reply to comment #0)
> I notice that ffi_call_SYSV has to handle all the return types, but not
> ffi_closure_SYSV nor ffi_closure_raw_SYSV. Does anyone know why that is?
To answer
--- Comment #12 from dave dot korn dot cygwin at gmail dot com 2009-03-25
08:03 ---
Hi all.
This patch caused g++.dg/ext/dllimport7.C to regress (in one subtest) between
4.3.2 and 4.3.3 on Cygwin, although it could be that the testcase is out of
date.
// { dg-do compile { target i?86
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-03-29
17:47 ---
For Cygwin, we just recently made --enable-auto-import the default in CVS
binutils. Now that we're moving to shared library runtimes throughout it made
sense.
However, I think this is a real bug,
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-04-22
11:20 ---
Hi Rob,
I just ran into this on i686-pc-cygwin. I think the reason you see it on
some builds and not others is because of the "--enable-libgcj-debug" option;
presumably that makes t
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-04-22
11:22 ---
Created an attachment (id=17671)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17671&action=view)
Fix debug asserts.
Adjust the assert to test the casted pointer.
--
http://gcc.
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-04-22
11:24 ---
That gets me about three files further through the build, then there's another
failure:
In file included from
/gnu/gcc/gcc/libjava/gnu/classpath/natConfiguration.cc:17:
/gnu/gcc/gcc/libjav
--- Comment #8 from dave dot korn dot cygwin at gmail dot com 2009-04-22
11:34 ---
Yep. From the .ii file:
class gnu::classpath::Configuration : public ::java::lang::Object
{
Configuration();
static ::java::lang::String * classpath_home();
static jboolean debug();
static
--- Comment #9 from dave dot korn dot cygwin at gmail dot com 2009-04-22
22:38 ---
Created an attachment (id=17679)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17679&action=view)
Part two of fix
This renames the DEBUG macro to __GCJ_DEBUG throughout. It fixed the buil
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-04-27
21:39 ---
I just got this failure during bootstrap:
libtool: compile: /gnu/gcc/obj3/gcc/gcj
-B/gnu/gcc/obj3/i686-pc-cygwin/libjava/ -B/gnu/gcc/obj3/gcc/ -ffloat-store
-fomit-frame-pointer -Usun -fclasspath
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-04-28
03:30 ---
(In reply to comment #4)
> I just got this failure during bootstrap:
> I'm going to try reverting r146831 locally and see if it helps.
Doing so allowed the build to complete. See als
--- Comment #68 from dave dot korn dot cygwin at gmail dot com 2009-09-03
12:53 ---
(In reply to comment #67)
> Will the fix for this bug be backported to the 4.4 branch?
>
I wasn't planning to do so myself, in the near future at any rate. All my
personal time is going i
87 matches
Mail list logo
