Re: [Libunwind-devel] Build glibc linking libunwind

[Ken Werner]

On 10/12/2011 04:40 PM, Paul Pluzhnikov wrote:
> On Wed, Oct 12, 2011 at 4:14 AM, Ken Werner<address@hidden>  wrote:
> > On 09/24/2011 11:46 PM, Fabio wrote:
> > > Hi all,
> > > I am trying to build glibc and link libunwind to get a backtrace at
> > > the beginning of some glibc function like strcpy for example but I
> > > can't get them to build.
> > > I include -lunwind in the CFLAGS and I export
> > > LD_LIBRARY_PATH=/usr/local/lib, but when it comes to build ld.so it
> > > fails:
> > >
> > > /home/wintermute/tesi/glibc/2.14/custom/glibc-2.14/string/strcpy.c:43:
> > > undefined reference to `_Ux86_getcontext'
> > > /home/wintermute/tesi/glibc/2.14/custom/glibc-2.14/string/strcpy.c:44:
> > > undefined reference to `_ULx86_init_local'
> > > collect2: ld returned 1 exit status
> > >
> > > Am I missing something? Sorry for asking a dumb question and thanks in
> > > advance.
> >
> > I suspect you're on a system where the linker does not pull in indirect
> > shared libs (the default behavior of recent Debian or Fedora based distros).
> > I had a similar issue - see:
> > http://lists.gnu.org/archive/html/libunwind-devel/2011-03/msg00002.html.
> > You're probably just missing to link against libunwind-x86_64.so. Adding
> > -lunwind-x86 to your CLFAGS/LDFLAGS should be sufficient.
>
> The link failure is while linking ld.so itself. It better not use
> libunwind-x86_64.so (or any other shared library) for obvious reasons.

Oh, ok. So, you modified strcpy.c of glibc to make use of 
functionalities provided by libunwind. And it looks like strcpy.c gets 
also pulled in when the ld.so is being built. Maybe you can ifdef the 
code that uses libunwind functionalities. I had a quick look into glibc 
and found that eglibc/libc/include/libc-symbols.h defines _LIBC:

/* This is defined for the compilation of all C library code.  features.h
   tests this to avoid inclusion of stubs.h while compiling the library,
   before stubs.h has been generated.  Some library code that is shared
   with other packages also tests this symbol to see if it is being
   compiled as part of the C library.  We must define this before including
   config.h, because it makes some definitions conditional on whether libc
   itself is being compiled, or just some generator program.  */
#define _LIBC   1

Regards
Ken