public inbox for libabigail@sourceware.org
 help / color / mirror / Atom feed
From: "Sochat, Vanessa" <sochat1@llnl.gov>
To: Mark Wielaard <mark@klomp.org>
Cc: "libabigail@sourceware.org" <libabigail@sourceware.org>
Subject: Re: Patch for Incorrect Symbol DW_LANG_PL1 -> DW_LANG_PLI
Date: Mon, 18 Oct 2021 15:27:56 +0000	[thread overview]
Message-ID: <3FA78256-D980-42E6-87EE-F2CE00957B63@llnl.gov> (raw)
In-Reply-To: <YWyeA4C3T+BT02XB@wildebeest.org>

Hi Mark,

I tried the gamut of versions from elfutils, down to 0.163 in spack:

https://github.com/spack/spack/blob/30e8dd95b54bb60b0b696ec85fb7f9b71f5e79dc/var/spack/repos/builtin/packages/elfutils/package.py#L25

And no luck. Notably, when I originally added libabigail I didn't see this error: https://github.com/spack/spack/commit/ef9a607c4c3bd01d6bcf3141244fd2941725e92f#diff-a8ac1d28334e9664af1280644c56095a1ba1160e5cc8b9ceec6ef8ec85491653 so my early conclusion was that something had changed about libabigail between the previous (1.8x and 2.0) releases. I simply couldn't get it working without this patch, regardless of the versions of elfutils or dwarf that I pinned.

If the previous symbol was wrong and changed, others are likely to hit this issue as I have, and I think it should be fixed in libabigail, and your patch looks like it would fit the bill (I didn't notice that the incorrect name extended beyond this one symbol). Will the maintainers accept the patch? On a high level note, I wonder if it would be possible to provide better scripts (or even a container) that demonstrates installing libabigail successfully -  The instructions to install from source and from the release on the libabigail site work only under very specific conditions it seems (and I haven't gotten the from source/git working at all) and it's definitely a pain point. The steps to run autoreconf and then make, etc. are not fully reproducible it seems. For reference I do have a container -> https://github.com/buildsi/build-abi-containers/blob/main/docker/libabigail/Dockerfile and between 1.82 and 2.0 I had to add the "f" for "force" to autoreconf -I because it failed without it.

If you want to reproduce my error, you can simply try installing with spack and commenting out the patch and you'll see the error. It's not surprising given the old symbol imho. I hope that we can get this patch applied, it seems reasonable to require a newer version of elfutils because 2016 was a long time ago! We could then remove the patch from spack.

Thanks!

Best,

Vanessa

On 10/17/21, 4:05 PM, "Mark Wielaard" <mark@klomp.org> wrote:

    Hi Vanessa,

    On Sun, Oct 17, 2021 at 08:53:52PM +0000, Sochat, Vanessa via Libabigail wrote:
    > A symbol in elfutils was renamed (see line 7 here) in elfutils:
    > 
    > https://urldefense.us/v3/__https://chromium.googlesource.com/external/elfutils/*/515dd0acc77673c953380bcf5ccfb05b83c5a3ab/NEWS__;Kw!!G2kpM7uM-TzIFchu!i3A6K6aPjMNqFLQkt4JXZzu8KXj5LrUQG8nyBxoUBrnqpH8x6Zijq8TSRSasaItU$ 
    >
    > This results in this error when trying to install the 2.0 libabigail
    > release (and I suspect others depending on the version of elfutils
    > used): error: 'DW_LANG_PL1' was not declared in this scope; did you
    > mean 'DW_LANG_PLI'

    Although that typo was indeed fixed, an compatibility define was left
    if libdw/dwarf.h:

    /* Old (typo) '1' != 'I'.  */
    #define DW_LANG_PL1 DW_LANG_PLI

    So I am slightly surprised you are getting that error, every version
    of elfutils really should have DW_LANG_PL1 (even though the correct
    name is DW_LANG_PLI) precisely to prevent any such compile errors.

    Are you sure you are using the correct dwarf.h from elfutils/libdw ?

    > And after some poking I figured out that this line
    > https://urldefense.us/v3/__https://sourceware.org/git/?p=libabigail.git;a=blob;f=src*abg-dwarf-reader.cc;h=1d6ad24cbfcc2d94c07311bb04112f14f4f0e71c;hb=HEAD*l11056__;LyM!!G2kpM7uM-TzIFchu!i3A6K6aPjMNqFLQkt4JXZzu8KXj5LrUQG8nyBxoUBrnqpH8x6Zijq8TSRZ7RpD9q$ 
    > needs to be DW_LANG_PLI instead of DW_LANG_PL1.  I am attaching the
    > patch I used to make the fix in spack:
    > https://urldefense.us/v3/__https://github.com/spack/spack/blob/03f84fb440770101816dad61ca59cf1bebf1997b/var/spack/repos/builtin/packages/libabigail/package.py*L37__;Iw!!G2kpM7uM-TzIFchu!i3A6K6aPjMNqFLQkt4JXZzu8KXj5LrUQG8nyBxoUBrnqpH8x6Zijq8TSRfFOmoPZ$ 

    I think the patch itself is correct, but you probably want to fix the
    typo in libabigail itself (see attached - this might be an api break
    for libabigail though without compatibility symbols).

    Note that this would mean libabigail won't compile with elfutils
    versions before 0.168, but that is probably no problem given that
    version is from 2016.

    Cheers,

    Mark


  reply	other threads:[~2021-10-18 15:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-17 20:53 Sochat, Vanessa
2021-10-17 22:04 ` Mark Wielaard
2021-10-18 15:27   ` Sochat, Vanessa [this message]
2021-10-18 16:25     ` Mark Wielaard
2021-10-18 17:08       ` Sochat, Vanessa
2021-10-18 18:03         ` Ben Woodard
2021-10-18 20:38           ` Sochat, Vanessa
2021-10-19 10:58 ` Dodji Seketeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3FA78256-D980-42E6-87EE-F2CE00957B63@llnl.gov \
    --to=sochat1@llnl.gov \
    --cc=libabigail@sourceware.org \
    --cc=mark@klomp.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).