Re: [RFC/ia64] link against libunwind rather than using dlopen

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Fri, 17 Jun 2011 18:10:42 +0200, Joel Brobecker wrote:
> Next on the list is to delete the libunwind_load phase, and use the unw_*
> symbols directly (so all the function unw_*_p pointers will disappear).

The gdb binary years ago could be freely copied across hosts and it still
worked.  GDB could also still provide ia64 debugging even if it runtime failed
to find libunwind.so.7.

This seems to be the original goal of the code:
	RFA: libunwind basic support
	http://sourceware.org/ml/gdb-patches/2003-10/msg00504.html
	http://sourceware.org/ml/gdb-patches/2003-11/msg00228.html
	> > - is it considered a "system library" (like libc, or libthread_db)?
	> 
	> I would have to say no.  It is currently an optional library.
	> This is one of the reasons I chose to use a dynamic load mechanism.


Unfortunately since DT_NEEDED libpython this feature is already lost so it
should be OK now even for libunwind.so.7.  Also with ubiquitous virtualization
the matching OS and GDB binary are usually more available now so the binary
build compatibility is not such an issue.


On Wed, 22 Jun 2011 17:36:25 +0200, Joel Brobecker wrote:
> But I did send a message to Jan asking him if he could test on a newer
> distro,

As sent offlist I have not found any problems you described on ia64 RHEL-4 and
RHEL-5 boxes.


Thanks,
Jan