Re: compile failure due to undefined symbol

["Peter S. Mazinger" <ps dot m at gmx dot net>]

On Fri, 28 Sep 2007, Nick Clifton wrote:

> Hi Peter,
> 
> 
> >>> libbfd.so (libtool problem) mentioned before LIBADD. Why not hardcoding 
> >>> the path to the right libbfd.so then ($(top_buildir)/bfd/libbfd.la)?
> >> Have you tried doing this ?  If so did it work for both native builds and cross 
> >> host builds ?
> > 
> > I did it natively, haven't checked on a cross build. I have used 
> > hardcoded libbfd.so path, since libbfd.la has libdir= set based on 
> > configure options already and I thought that libtool might fail to pick up 
> > the right one.
> 
> Hmm, OK, do you have a patch that I might try out then ?

Attached you'll find what I used, for convenience I have added a second 
patch, so that you do not need autotools. I do not know which binutils' ld 
began supporting -rpath-link, else -L"`pwd`/../bfd/.libs" could be used. 
I have used the versioned name instead of -lbfd, so that libbfd.la does 
not influence the result (the dependency is though on libbfd.a, the we 
can be sure that libbfd-VERSION.so is also present).
Replacing -rpath-link with -rpath would be maybe an option too, I haven't 
though checked if libtool links the first libopcodes.so in the build 
directory with the `pwd`/../bfd/.libs path and later on install relinking 
with -rpath $(libdir), probably to support this BFDLIB_HARDCODE has to be 
ignored in the second link.

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Attachment: binutils-2.18-zdefs_2.patch
Description: Binary data

Attachment: binutils-2.18-zdefs.patch
Description: Text document