Processing commands for cont...@bugs.debian.org:
# I believe libgcj-commmon is the new home for aot-compile?
# In this case I think j-g-c-dev is buggy.
# Reassign as appropriate if it's actually the other way round
# In any case, installing java-gcj-compat-dev exhibits this error...
reassign
Processing commands for cont...@bugs.debian.org:
unmerge 529402
Bug#529402: file conflict(s) with libgcj-common
Bug#529412: configure fails - not overwriting local files
Bug#529725: file conflicts with java-gcj-compat-dev
Disconnected #529402 from all other report(s).
reopen 529402
Bug#529402:
unmerge 529402
reopen 529402
thanks
Debian Bug Tracking System wrote:
reassign 529402 libgcj-common
forcemerge 529412 529402
forcemerge 529402 529725
thanks
Version: 1:4.4.0-6
Not really.
See e.g.
java-gcj-compat_1.0.80-3_i386.changes uploaded successfully to localhost
along with the files:
java-gcj-compat_1.0.80-3.dsc
java-gcj-compat_1.0.80-3.diff.gz
java-gcj-compat-dev_1.0.80-3_i386.deb
java-gcj-compat-headless_1.0.80-3_i386.deb
java-gcj-compat_1.0.80-3_i386.deb
Greetings,
Accepted:
java-gcj-compat-dev_1.0.80-3_i386.deb
to pool/main/j/java-gcj-compat/java-gcj-compat-dev_1.0.80-3_i386.deb
java-gcj-compat-headless_1.0.80-3_i386.deb
to pool/main/j/java-gcj-compat/java-gcj-compat-headless_1.0.80-3_i386.deb
java-gcj-compat_1.0.80-3.diff.gz
to
--- Comment #5 from mikpe at it dot uu dot se 2009-05-22 10:07 ---
Created an attachment (id=17900)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17900action=view)
put ARM EABI atomic builtins in both shared and static libgcc
I reviewed the original ARM EABI atomic builtins code
--- Comment #6 from joseph at codesourcery dot com 2009-05-22 10:22 ---
Subject: Re: exception propagation support not enabled
in libstdc++ 4.4 on {armeabi,hppa}-linux
On Fri, 22 May 2009, mikpe at it dot uu dot se wrote:
Created an attachment (id=17900)
--
--- Comment #7 from mikpe at it dot uu dot se 2009-05-22 11:16 ---
(In reply to comment #6)
This patch is obviously wrong - if you put things in shared libgcc you
also need to assign symbol versions to them based on the version in which
they were actually added.
Yeah, I realized
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
mikpe at it dot uu dot se changed:
What|Removed |Added
Attachment #17900|0 |1
is obsolete||
--- Comment #8 from mikpe at it dot uu dot se 2009-05-22 19:18 ---
Created an attachment (id=17902)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17902action=view)
always pass -lgcc to linker
The link error reported by Matthias Klose is caused by the following:
1. g++ links shared
Package: libphobos-4.1-dev
Version: 0.25-4.1.2-23.2
Severity: normal
Here is the relevant VERBOSE=1 output (with line wrapping and separating
invidual commands by return) from a make command that has been
configured with cmake to build a shared D library.
[100%] Building D object
--- Comment #9 from paolo dot carlini at oracle dot com 2009-05-22 20:30
---
Two general comments: 1- Patches should be in any case posted to the
gcc-patches mailing list; 2- I got previous feedbacks from Joseph as meaning
that the issue is general, not restricted to the arm config; 3-
14 matches
Mail list logo