On Sat, Jul 13, 2013 at 04:15:44PM -0700, Jonathan Nieder wrote:
> Hi Kurt,
>
> In November, 2012, you wrote (re elfutils's plugin path):
>
> > unarchive 632281
> > reopen 632281
> > #It doesnt do the right thing in case of non-multi arch now
>
> How should $LIB be set to support this? I'm wo
Hi Kurt,
In November, 2012, you wrote (re elfutils's plugin path):
> unarchive 632281
> reopen 632281
> #It doesnt do the right thing in case of non-multi arch now
How should $LIB be set to support this? I'm worried that there's
no value of ORIGIN and LIB that would make
"$ORIGIN/../
On Fri, Jul 01, 2011 at 07:44:01PM +0200, Kurt Roeckx wrote:
>
> Anyway, I think ld.so does what it's supposed to do in case
> everything was multiarch, the files would need to be moved
> there in that case. But I think it's wrong to only try
> the multiarch location.
So the elfutils code does:
On Fri, Jul 01, 2011 at 07:39:51PM +0200, Kurt Roeckx wrote:
> On Fri, Jul 01, 2011 at 09:28:24AM -0700, Ian Wienand wrote:
> > Hi,
> >
> > Thanks, I realised this after I sent it
> >
> > I'm not sure though if it's multi-arch or elfutils? The man page says
> >
> >$LIB The string $LIB
On Fri, Jul 01, 2011 at 09:28:24AM -0700, Ian Wienand wrote:
> Hi,
>
> Thanks, I realised this after I sent it
>
> I'm not sure though if it's multi-arch or elfutils? The man page says
>
>$LIB The string $LIB (or equivalently ${LIB}) in an rpath corresponds
> to the syst
On Fri, Jul 01, 2011 at 12:11:35AM -0700, Ian Wienand wrote:
> 346 void *h = dlopen (dsoname, RTLD_LAZY);
> (gdb) print (char*)dsoname
> $2 = 0xbfffeccc "$ORIGIN/../$LIB/elfutils/libebl_i386.so"
>
> but following that through in strace it seems $LIB gets expanded by
> ld.so to "i386-linu
Package: elfutils
Version: 0.152-1
Severity: important
The eu- tools aren't finding their backend plugins, thus falling back
to a default ELF parser. You notice this if you're trying to look at
machine specific fields
It's weird, I can see that it is trying to dlopen what seems to be a
sane path
7 matches
Mail list logo
