From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53004 invoked by alias); 12 Feb 2019 20:42:58 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 52725 invoked by uid 89); 12 Feb 2019 20:42:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=whatsoever, ebl X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 12 Feb 2019 20:42:57 +0000 Received: from librem.wildebeest.org (deer0x15.wildebeest.org [172.31.17.151]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id E2F3C30008D6; Tue, 12 Feb 2019 21:42:54 +0100 (CET) Received: by librem.wildebeest.org (Postfix, from userid 1000) id 8B70813F7E4; Tue, 12 Feb 2019 21:42:54 +0100 (CET) Date: Tue, 12 Feb 2019 20:42:00 -0000 From: Mark Wielaard To: Sasha Da Rocha Pinheiro Cc: "elfutils-devel@sourceware.org" , Ben Woodard Subject: Re: unknown error after dwarf_cfi_addrframe() Message-ID: <20190212204254.GI10699@wildebeest.org> References: <20190212064750.GE10699@wildebeest.org> <20190212080955.GH10699@wildebeest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00135.txt.bz2 On Tue, Feb 12, 2019 at 06:49:54PM +0000, Sasha Da Rocha Pinheiro wrote: > Since the openbackend() tries to dlopen twice, and in the second turn > it succeeds opening one libebl_x86_64.so, I even tried to redirect that > symbolic link to a newer version of libebl_x86_64-0.165.so, as seen > below. That won't work. The backends are version specific. That might explain why you see the backend library be opened and then closed. eblopenbackend will do that if the backend init function returns the wrong version. See also the following in NOTES: - the ABI of the backend modules is not guaranteed. Really, no guarantee whatsoever. We are enforcing this in the code. The modules and their users must match. No third-party EBL module are supported or allowed. The only reason there are separate modules is to not have the code for all architectures in all the binaries. > LD_LIBRARY_PATH = /p/paradyn/development/sasha/local/lib/elfutils/:/p/paradyn/development/sasha/local/lib/:/p/paradyn/packages/libdwarf/lib:. So assuming you configure with --prefix=/p/paradyn/development/sasha/local and ran make install Then the following should both return "Build for elfutils 175 x86_64-pc-linux-gnu" eu-strings /p/paradyn/development/sasha/local/lib/libdw.so | grep ^Build eu-strings /p/paradyn/development/sasha/local/lib/elfutils/libebl_x86_64.so \ | grep ^Build Hope that helps, Mark