x86_64 Perftools RPM about gperftools HOT 11 CLOSED

I agree.  I don't build the RPMs on an x86_64 machine myself, so I don't know 
how
difficult it would be for me to add it.  I also create and upload RPMs manually 
for
each release, so as the number gets bigger it becomes a bit more work for me.

I'm fine if people want to create such things themselves!  I think you can 
create an
issue or something where you attach the rpm file.

Did you considered services like openSUSE Build Service
(http://en.opensuse.org/Build_Service)? I don't use it myself and don't know 
much
about it, but this service is developed exactly for this purpose. Some days ago 
they
announced that this Service is available for building packages for different
repositories.
I know that building packages for different repositories/architectures is a real
headache.

Here is a set of RPMs I have built for x86_64.  Let me know if these work.

This issue is resolved as we could build 64bit gmalloc rpm. Thanks for your 
help on this.

I haven't forgotten about this!  I finally got a good machine for building a 
64-bit
deb file (no rpm though).  However, it's tricky because for 64-bit x86_64 
machines,
tcmalloc requires you to either use libunwind, or to build with frame pointers 
(which
requires all your applications to use frame pointers too).  Neither is very 
appealing
pre-packaged: I don't want to include libunwind, or add a dependency on it, but 
I
also don't want to build with frame pointers since there's no good way to 
advertise
that apps need to be built with frame pointers too.

I'm not sure the best way to proceed.  Maybe I'll just build it with frame 
pointers
and hope for the best.  But I'm worried that will create a support headache.  
So now
I'm paralyzed into doing nothing at all. :-}

I tried to build a RPM for google-perftoos 1.2 on 64-bit. I found the 2 
following 
problems and here my suggestions if it may help:

- Because of the libunwind pb, it'd be nice to be able to pass the 
--enable-frame-
pointers option to configure in the spec file. This requires a minor mod in the 
spec 
file itself :

./configure %{configure_opts}

and in rpm.sh to add the following --define :

  --define "configure_opts ${FRAME_POINTERS_OPT" \

FRAME_POINTERS_OPT could be defined to the empty string by default and it 
should be 
possible to pass it as an opt argument to rpm.sh.

- There is a problem with pprof.1 location in the %file section. make install 
put in 
share/man/... where the spec file looks for it in man/...

An additional issue I missed it that libraries should be installed into 
/usr/lib64 
instead of /usr/lib. But this is also very easy to passe it with a macro from 
the 
script rpm.sh based on uname. This is very important as it makes sense to 
install 
both version on a 64-bit machine, one for the 32-bit apps, one for the 64-bit 
apps.

Cheers,

Michel

Hi Michel, thanks for your feedback.  I have been wrestling with this very 
issue.

I'm reluctant to put out a 64-bit RPM with --enable-frame-pointers, because 
that's
not a "Just Works" solution -- the user of the library needs to understand the
repercussions, and that they need to compile everything else with frame pointers
enabled as well.  I'd rather folks compile from source, so they can be aware of 
this.

On the other hand, most users probably only want the malloc functionality, and 
don't
need all the facilities that require stack-tracing, like the cpu profiler.  So 
for
them, --enable-frame-pointers makes sense.  Maybe I could provide a 'minimal' 
library
for 64 bit.

As for lib vs lib64 -- what about systems that are 64-bit only?  Does /lib64 
exist
there as well?  I don't know much about packaging for 64-bit systems.  For other
opensource packages I maintain, it seems to use /usr/lib for all libraries.

I can't figure out what to do, so in the meantime I've been doing nothing. :-/

Hi,

You are completely right, this is not a full version. But from your notes I 
understood that --enable-frame-pointers was ok on 64-bit as long as you use 
only 
tcmalloc. My goal was only to have a RPM easy to use for deployment on RH-based 
system and adding libunwind constraint seemed to much. I didn't take the time 
to 
build a RPM with tcmalloc only but I agree this would be the cleanest solution.

On RH derivative (RH, Fedora, Scientific Linux, Centos...) at least (I don't 
know 
about other family of distros), 64-bit libs are ALWAYS installed in a lib64 
directory. 'lib' directories are supposed to contain only 32-bit libs, either 
on a 
pure 32-bit OS or a 64-bit OS with 32-bit compatibility installed (in fact 
mainly 32-
bit libs).

If it helps I attached a tweaked version of rpm.sh and rpm.spec that works 
properly 
to build the 64-bit RPM on a 64-bit system and should be backward compatible 
for 
other systems.

By the way, you should be able to get the RPM from 
https://quattorsrv.lal.in2p3.fr/
packages/glite/3.1/externals.


Michel

Issue 240 has been merged into this issue.

Here's my comment in issue 240, which I'm repeating here for ease of reference:
---
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.
---

I think it's probably time to finally deal with this issue.  I've been advised 
that I shouldn't be in the package-creating business at all, which is probably 
right.  I provide RPMs and deb's for convenience, but they account for less 
than 15% of all downloads I see.  Given that the great majority of people 
compile from source anyway, and that there's no good default for 64-bit 
building (libunwind is still not quite suitable, after all these years), I'm 
going to close this WillNotFix.