search

DavidMorre / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

amd64 .deb #239

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
It would be great if in addition to the 386 arch .deb packages, you also 
provided amd64 arch packages; that's pretty much more common for developers 
these days.

Original issue reported on code.google.com by andrewhh...@gmail.com on 3 May 2010 at 7:05

GoogleCodeExporter commented 9 years ago

Original comment by `` on 18 Jan 2012 at 9:51

GoogleCodeExporter commented 9 years ago 
I don't disagree with you.  The problem is that x86_64 packages have a big 
issues 
with stackatraces.  There are a couple of ways to work around it (libunwind, 
which 
works for some people sometimes, and --enable-frame-pointers, which kinda-works 
all 
the time), but each has plusses and minuses, and developers need to understand 
the 
repercussions of the choices they're making, in order to use perftools 
effectively.

Because of that, I've decided it's best to make developers compile from source, 
and 
explicitly choose one of the two options, so they can use perftools 
successfully.

I hope one day libunwind will be good enough we can just go with that solution 
for 
everyone. But for now, I think compiling from source is the best choice.  I'll 
think 
about if there are any compromise solutions I'm missing.

Original comment by csilv...@gmail.com on 3 May 2010 at 10:08