[Mono-list] Martin's debugger in CVS

[Martin Baulig]

Peter Williams <peterw@ximian.com> writes:

> Your libbfd probably relies on another library that the debugger's
> configuration script doesn't know about. It's probably one of the other
> libraries included in whatever release of binutils you're using. You
> could try adding them to the configure check around line 107 of the
> configure.in (using the -lopcodes check as a reference for how to do
> that) and see if one of them fixes it.

Well, these symbols come from -liberty.

However, do not add a check for it to configure.in, that is wrong.  I was previously
checking for it, but intentionally removed the check.

What we need to do is having a check in configure.in which checks whether you can link
against -lbfd alone (without specifying -liberty !) and have it explicitly abort if it
cannot find _sch_istable.

We can probably do this by checking whether you can get _sch_istable just by linking
against -lbfd, for instance

        extern void _sch_istable (void);
        int main () { void *ptr = &_sch_istable; }

must work.

If this doesn't work, then your libbfd is unusable and you must manually compile it.

> > configure:8443: checking for bfd_get_arch in -lbfd
> > configure:8470: gcc -o conftest -g -Wall -Wunused -Wmissing-prototypes 
> > -Wmissing-declarations -Wstrict-prototypes  -Wmissing-prototypes 
> > -Wnested-externs  -Wshadow -Wpointer-arith -Wno-cast-qual -Wcast-align 
> > -Wwrite-strings   conftest.c -lbfd   >&5
> > configure:8458: warning: function declaration isn't a prototype
> > configure:8461: warning: function declaration isn't a prototype
> > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libbfd.a(archures.o): In 
> > function `bfd_default_scan':
> > archures.o(.text+0x192): undefined reference to `_sch_istable'
> > archures.o(.text+0x19f): undefined reference to `_sch_istable'
> > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libbfd.a(bfd.o): In 
> > function `_bfd_abort':
> > bfd.o(.text+0x4ec): undefined reference to `xexit'
> > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libbfd.a(bfd.o): In 
> > function `bfd_errmsg':
> > bfd.o(.text+0x10f): undefined reference to `xstrerror'

I'll add the following to README.FreeBSD:

====
binutils and libbfd issues:
===========================

The debugger needs a shared libbfd and libopcodes.

If you get any problems with `_sch_istable' being undefined, then your libbfd is unusable
for the debugger and you need to manually compile a shared one.  Note that adding a check
for -liberty (that's where that symbol is defined) to configure.in is wrong and will not
work !

There are two ways of compiling binutils:

a) You create a non-shared libbfd.  This seems to be the default on FreeBSD and probably
   some other systems and it creates static libiberty.a, libbfd.a and libopcodes.a.

   If you use --enable-shared, you also get a shared libbfd.so, but that doesn't matter -
   it's still unusable for the debugger.  It is a shared library which is intended to be
   linked into an application - and that application must also statically link against
   -liberty.

   If you do this, you'll get an application which has -liberty (which is small)
   statically linked in and dynamically links against -lbfd (which is big).

   This doesn't work for the debugger since it must dlopen() the library and thus needs a
   shared -liberty as well.

b) You create a shared libbfd.  To do this, you need to give configure the (unfortunately
   undocumented) --enable-commonbfdlib argument.

   This'll create a shared libbfd.so and libopcodes.so - and the libbfd.so has all the
   object files from -liberty linked in.

   Such a libbfd.so doesn't depend on any non-shared libraries and thus it can be
   dlopen()ed - that's what the debugger needs.

====

-- 
Martin Baulig
martin@gnome.org
martin@ximian.com