configure should better handle lack of libunwind

[GoogleCodeExporter]

It would be very helpful if the ./configure script fail early if libunwind was 
not found, rather than fail later in compilation.

It would be even nicer if ./configure would accept an option such as 
--with-libunwind=<path> in case libunwind is not available. 

Original issue reported on code.google.com by oleg.ale...@gmail.com on 30 Apr 2013 at 12:02

[GoogleCodeExporter]

gperftools does not require libunwind installed, although it will use as 
default in
some cases. For x86 and x86_64:

1. If you use '--enable-frame-pointers', it won't use libunwind (it will use the
stacktrace logic at stacktrace_x86-inl.h)
2. If don't use '--enable-frame-pointers' (default), configure will check if
libunwind if available and usable.

The logic for the selections is basic on 'stacktrace_config.h' and 
'stacktrace.cc'.
Are you have any issues with building without libunwind? If so, what kind of 
issue,
in which system, etc.?

Related to --with-libunwind=<path> I believe it could useful to select another 
libunwind installed on the system.

Original comment by zatr...@gmail.com on 2 May 2013 at 6:25

[GoogleCodeExporter]

Thank you for your very prompt feedback.

I managed to see this problem with both gcc (GCC) 4.4.6 20110731 (Red Hat 
4.4.6-3) and gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973].
I do the default approach:

./configure --prefix=$HOME/packages

It goes through without errors, although config.log does show: /usr/bin/ld: 
cannot find -lunwind

Then, during compilation I get:

/bin/sh ./libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I./src  
-I./src   -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare 
-fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc 
-fno-builtin-cfree -fno-builtin-memalign -fno-builtin-posix_memalign 
-fno-builtin-valloc -fno-builtin-pvalloc  -Wno-unused-result  
-DNO_FRAME_POINTER -g -O2 -MT stacktrace.lo -MD -MP -MF .deps/stacktrace.Tpo -c 
-o stacktrace.lo `test -f 'src/stacktrace.cc' || echo './'`src/stacktrace.cc
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I./src -I./src -Wall 
-Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc 
-fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree 
-fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc 
-fno-builtin-pvalloc -Wno-unused-result -DNO_FRAME_POINTER -g -O2 -MT 
stacktrace.lo -MD -MP -MF .deps/stacktrace.Tpo -c src/stacktrace.cc  -fPIC 
-DPIC -o .libs/stacktrace.o
In file included from src/stacktrace.cc:57:
src/stacktrace_config.h:58:5: error: #error Cannnot calculate stack trace: need 
either libunwind or frame-pointers (see INSTALL file)
src/stacktrace.cc:109:3: error: #error Cannot calculate stack trace: will need 
to write for your environment
cc1plus: warning: unrecognized command line option "-Wno-unused-result"
make: *** [stacktrace.lo] Error 1

Original comment by oleg.ale...@gmail.com on 3 May 2013 at 4:50

[GoogleCodeExporter]

I saw the issue now in my x86_64 system (I didn't notice before because the 
package
manager didn't properly cleanup an old libunwind install), but I don't agree it
should fail at configure because currently only x86_64 uses libunwind (PowerPC, 
ARM,
Windows, CYGWIN all uses gperftools own implementations).

I'll work to add a configure option to specify a non-default libuwind.

Original comment by zatr...@gmail.com on 3 May 2013 at 5:39

[GoogleCodeExporter]

What I mean to say is that in the situation where it is going to fail anyway, 
then it better fail in configure, rather than in compilation.

That is to say, if configure figures out it can get by without libunwind, it 
should not fail, but if configure thinks libunwind is the only way to go, and 
it is not available, it should fail.

Of course, this is a minor thing. Whoever uses gperftools better be proficient 
enough to figure out what to do. But it is better style to fail before 
compilation. 

Original comment by oleg.ale...@gmail.com on 4 May 2013 at 12:04

[GoogleCodeExporter]

good point

Original comment by alkondratenko on 6 Jul 2013 at 10:06

• Changed title: configure should better handle lack of libunwind
• Changed state: Accepted

[GoogleCodeExporter]

merged fix. Consider testing latest master

Original comment by alkondratenko on 17 Feb 2014 at 4:02

• Changed state: Fixed

[GoogleCodeExporter]

What was the fix for this and in which revision was it merged? The 2.4 release 
still contains no configure option to specify a location for libunwind.

Original comment by florian....@gmail.com on 16 Feb 2015 at 5:35

[GoogleCodeExporter]

Fix was about complaining about _missing_ libunwind at configure time rather 
than at build time as was the case before.

If you're willing to submit patch that implements easier configuration of 
libunwind installation path, then I'm certainly willing to merge such path.

As of now you can compile&link to nonstandard libunwind by passing 
-I<libunwind-prefix>/include in CPPFLAGS and -L<libunwind-prefix>/lib in 
LDFLAGS.

E.g.:

./configure CPPFLAGS=-I/home/me/lunw/include LDFLAGS=-L/home/me/lunw/lib

And unless you (or some script) removed .la files installed by libunwind's 
libtool, gperftools' libtool will even automagically add rpath so that you 
don't have to bother your users to do LD_LIBRARY_PATH trick at runtime.

Original comment by alkondratenko on 16 Feb 2015 at 6:26