On Mon, 2006-08-14 at 10:52 +0200, Steinar H. Gunderson wrote:
> [Cc-ing Glenn since he's expressed interest in this ITP earlier]
>
> On Sun, Jun 18, 2006 at 02:12:02PM +0200, Miriam Ruiz wrote:
> > What's the current status of this ITP?
>
> I don't know what the status of the original submitters
On Wed, 2006-03-01 at 21:16 +0100, Matej Vela wrote:
> On Fri, Dec 02, 2005 at 08:52:41 -0600, Andrew Lenharth wrote:
> > This package has been abandoned upstream for almost 5 years, and I
> > consider unison to be a better replacement. Thus, this packages is
> > abandoned.
Package: wnpp
Severity: normal
This package has been abandoned upstream for almost 5 years, and I
consider unison to be a better replacement. Thus, this packages is
abandoned. If it is not picked up I will have it removed from unstable.
--
Andrew Lenharth <[EMAIL PROTECTED]>
signatu
Is it possible to revert this patch until upstream fixes things?
the binutil people seem to thing it is the cause of the problem, but
don't seem interested in fixing it anytime soon.
http://sourceware.org/ml/binutils/2005-05/msg00736.html
I would be happy to test any proposed fix.
Andrew
--
So, my last message was premature. Here is the profile 60 minutes
through a 130 minute link.
fenris:~# opreport -l /usr/local/bin/ld
CPU: Alpha EV67, speed 666.667 MHz (estimated)
Counted CYCLES events (Total cycles) with a unit mask of 0x00 (No unit
mask) count 10
samples %symbol na
I decided to run oprofile on ld and it is spending all it's time in
bfd_elf_size_dynsym_hash_dynstr.
At this point (6 minutes into a 130 minute link, use to be 15 minutes
total), 99.9998% of time is being spent in that function.
Andrew
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subj
As a way of correction, ld does not loop infinately, just take > 10x as
long as it use to. It seems that it grows the GOT table too slowly, and
has to increase it for every few symbols (which for a large program is a
problem). This is just guess work from looking at it with gdb.
--
And
As a way of correction, ld does not loop infinately, just take > 10x as
long as it use to. It seems that it grows the GOT table too slowly, and
has to increase it for every few symbols (which for a large program is a
problem). This is just guess work from looking at it with gdb.
--
And
Package: binutils
Version: 2.16.1cvs20050902-1
Severity: important
Binutils in testing (2.16.1?) is unusable on alpha with gcc-4.0 as it cannot
assemble most things gcc spits out. so after upgrading to this version,
I find that when linking, ld appears to hang. Links that took 15 minutes
I have
On Fri, 2005-10-14 at 11:42, Falk Hueffner wrote:
> Andrew Lenharth <[EMAIL PROTECTED]> writes:
>
> > When performing integer division, the following relocation is generated (to
> > the libc divide function)
> > jsr $23,($27),__divq!lituse_jsrdirect
Package: gcc-4.0
Version: 4.0.2-2
Severity: important
When performing integer division, the following relocation is generated (to the
libc divide function)
jsr $23,($27),__divq!lituse_jsrdirect!79
the assembler does not understand this :
/tmp/ccFszcSs.s: Assembler messages:
/tmp/ccFsz
eek-of-Mon-20050418/025743.html
There shouldn't be any reason not to do the same thing to the 1.4 src
package.
Andrew Lenharth
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
uite
> following.
(CCing the bug and thus the submitter)
sounds like a missing built-depends, at least graphviz, possibly
something else. Could you give us some of the error output from your
build to help narrow things down?
Thanks
Andrew Lenharth
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
13 matches
Mail list logo
