* Patch for Incorrect Symbol DW_LANG_PL1 -> DW_LANG_PLI @ 2021-10-17 20:53 Sochat, Vanessa 2021-10-17 22:04 ` Mark Wielaard 2021-10-19 10:58 ` Dodji Seketeli 0 siblings, 2 replies; 8+ messages in thread From: Sochat, Vanessa @ 2021-10-17 20:53 UTC (permalink / raw) To: libabigail [-- Attachment #1: Type: text/plain, Size: 1555 bytes --] Hi Libabigail (and master Dodji!), A symbol in elfutils was renamed (see line 7 here) in elfutils: https://chromium.googlesource.com/external/elfutils/+/515dd0acc77673c953380bcf5ccfb05b83c5a3ab/NEWS 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' And after some poking I figured out that this line https://sourceware.org/git/?p=libabigail.git;a=blob;f=src/abg-dwarf-reader.cc;h=1d6ad24cbfcc2d94c07311bb04112f14f4f0e71c;hb=HEAD#l11056 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://github.com/spack/spack/blob/03f84fb440770101816dad61ca59cf1bebf1997b/var/spack/repos/builtin/packages/libabigail/package.py#L37 If you want to reproduce that bug, you should be able to clone spack, comment out the line for the patch, add spack’s bin to the path, and then spack install libabigail. I’ve also been having some trouble building libabigail from the git repository – the instructions in the sourceware docs don’t work completely, as I get a “syntax error near unexpected token ‘XML,’ and commenting out that line gets a bit further, but then errors missing library paths for libxml (which I’ve added). Do you have your release scripts you might share to reproduce what is in the release tarball? Thank you, and thank you for all the recent work on libabigail! Best, Vanessa [-- Attachment #2: 0001-plt.patch --] [-- Type: application/octet-stream, Size: 838 bytes --] From ba5e2b5dc9de106635c12ebe9260e2fc0212ff91 Mon Sep 17 00:00:00 2001 From: Vanessa Sochat <sochat1@llnl.gov> Date: Fri, 15 Oct 2021 05:17:47 +0000 Subject: [PATCH] fixing incorrect symbol Signed-off-by: @vsoch <vsoch@noreply.users.github.com> --- src/abg-dwarf-reader.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/abg-dwarf-reader.cc b/src/abg-dwarf-reader.cc index 1d6ad24c..8dd86c5a 100644 --- a/src/abg-dwarf-reader.cc +++ b/src/abg-dwarf-reader.cc @@ -11053,7 +11053,7 @@ dwarf_language_to_tu_language(size_t l) return translation_unit::LANG_Ada95; case DW_LANG_Fortran95: return translation_unit::LANG_Fortran95; - case DW_LANG_PL1: + case DW_LANG_PLI: return translation_unit::LANG_PL1; case DW_LANG_ObjC: return translation_unit::LANG_ObjC; -- 2.17.1 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Patch for Incorrect Symbol DW_LANG_PL1 -> DW_LANG_PLI 2021-10-17 20:53 Patch for Incorrect Symbol DW_LANG_PL1 -> DW_LANG_PLI Sochat, Vanessa @ 2021-10-17 22:04 ` Mark Wielaard 2021-10-18 15:27 ` Sochat, Vanessa 2021-10-19 10:58 ` Dodji Seketeli 1 sibling, 1 reply; 8+ messages in thread From: Mark Wielaard @ 2021-10-17 22:04 UTC (permalink / raw) To: Sochat, Vanessa; +Cc: libabigail [-- Attachment #1: Type: text/plain, Size: 1727 bytes --] 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://chromium.googlesource.com/external/elfutils/+/515dd0acc77673c953380bcf5ccfb05b83c5a3ab/NEWS > > 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://sourceware.org/git/?p=libabigail.git;a=blob;f=src/abg-dwarf-reader.cc;h=1d6ad24cbfcc2d94c07311bb04112f14f4f0e71c;hb=HEAD#l11056 > 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://github.com/spack/spack/blob/03f84fb440770101816dad61ca59cf1bebf1997b/var/spack/repos/builtin/packages/libabigail/package.py#L37 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 [-- Attachment #2: pl1-pli.patch --] [-- Type: text/x-diff, Size: 2109 bytes --] diff --git a/include/abg-ir.h b/include/abg-ir.h index 81147144..7ed97987 100644 --- a/include/abg-ir.h +++ b/include/abg-ir.h @@ -657,7 +657,7 @@ public: LANG_Pascal83, LANG_Modula2, LANG_Java, - LANG_PL1, + LANG_PLI, LANG_UPC, LANG_D, LANG_Python, diff --git a/src/abg-dwarf-reader.cc b/src/abg-dwarf-reader.cc index 1d6ad24c..daecaf79 100644 --- a/src/abg-dwarf-reader.cc +++ b/src/abg-dwarf-reader.cc @@ -11053,8 +11053,8 @@ dwarf_language_to_tu_language(size_t l) return translation_unit::LANG_Ada95; case DW_LANG_Fortran95: return translation_unit::LANG_Fortran95; - case DW_LANG_PL1: - return translation_unit::LANG_PL1; + case DW_LANG_PLI: + return translation_unit::LANG_PLI; case DW_LANG_ObjC: return translation_unit::LANG_ObjC; case DW_LANG_ObjC_plus_plus: @@ -11160,7 +11160,7 @@ get_default_array_lower_bound(translation_unit::language l) case translation_unit::LANG_Java: value = 0; break; - case translation_unit::LANG_PL1: + case translation_unit::LANG_PLI: value = 1; break; case translation_unit::LANG_UPC: diff --git a/src/abg-ir.cc b/src/abg-ir.cc index 4f19e07a..fabc089d 100644 --- a/src/abg-ir.cc +++ b/src/abg-ir.cc @@ -1467,8 +1467,8 @@ translation_unit_language_to_string(translation_unit::language l) return "LANG_Modula2"; case translation_unit::LANG_Java: return "LANG_Java"; - case translation_unit::LANG_PL1: - return "LANG_PL1"; + case translation_unit::LANG_PLI: + return "LANG_PLI"; case translation_unit::LANG_UPC: return "LANG_UPC"; case translation_unit::LANG_D: @@ -1533,8 +1533,8 @@ string_to_translation_unit_language(const string& l) return translation_unit::LANG_Modula2; else if (l == "LANG_Java") return translation_unit::LANG_Java; - else if (l == "LANG_PL1") - return translation_unit::LANG_PL1; + else if (l == "LANG_PLI") + return translation_unit::LANG_PLI; else if (l == "LANG_UPC") return translation_unit::LANG_UPC; else if (l == "LANG_D") ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Patch for Incorrect Symbol DW_LANG_PL1 -> DW_LANG_PLI 2021-10-17 22:04 ` Mark Wielaard @ 2021-10-18 15:27 ` Sochat, Vanessa 2021-10-18 16:25 ` Mark Wielaard 0 siblings, 1 reply; 8+ messages in thread From: Sochat, Vanessa @ 2021-10-18 15:27 UTC (permalink / raw) To: Mark Wielaard; +Cc: libabigail 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Patch for Incorrect Symbol DW_LANG_PL1 -> DW_LANG_PLI 2021-10-18 15:27 ` Sochat, Vanessa @ 2021-10-18 16:25 ` Mark Wielaard 2021-10-18 17:08 ` Sochat, Vanessa 0 siblings, 1 reply; 8+ messages in thread From: Mark Wielaard @ 2021-10-18 16:25 UTC (permalink / raw) To: Sochat, Vanessa; +Cc: libabigail Hi Vanessa, On Mon, 2021-10-18 at 15:27 +0000, Sochat, Vanessa wrote: > 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. In that case I suspect somehow the build isn't using the right dwarf.h header. It might be the: depends_on('libdwarf') libabigail doesn't depend on libdwarf and libdwarf is not part of elfutils. It does provide a dwarf.h header though, that might simply not be compatible. elfutils-devel install it in /usr/include/dwarf.h while libdwarf-devel installs it in /usr/include/libdwarf/dwarf.h So in theory they shouldn't conflict, unless the compiler has /usr/include/libdwarf on the include path. > Notably, when I originally added libabigail I didn't see this error: > https://github.com/spack/spack/commit/ef9a607c4c3bd01d6bcf3141244fd29 > 41725e92f#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. Not saying the PL1/PLI confusion shouldn't be fixed (it is a really odd typo), but it is somewhat curious nobody else has reported this issue. Which is why I suspect that somehow your build is using the "wrong" dwarf.h. Because all elfutils/libdw versions of dwarf.h do have DW_LANG_PL1 defined. If you are picking up a non-elfutils/libdw dwarf.h maybe that explains some of the other build issues too? Cheers, Mark ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Patch for Incorrect Symbol DW_LANG_PL1 -> DW_LANG_PLI 2021-10-18 16:25 ` Mark Wielaard @ 2021-10-18 17:08 ` Sochat, Vanessa 2021-10-18 18:03 ` Ben Woodard 0 siblings, 1 reply; 8+ messages in thread From: Sochat, Vanessa @ 2021-10-18 17:08 UTC (permalink / raw) To: Mark Wielaard; +Cc: libabigail Hi Mark, That was a great idea! It was an oversight to add libdwarf, and it compiles without it. For an install from source, the issue I'm hitting is that the link line doesn't appear to have -lxml2: libtool: link: /opt/spack/lib/spack/env/gcc/g++ -fvisibility=hidden -I/code/libabigail/include -I/code/libabigail /tools -fPIC -g -O2 -std=c++11 -Wl,-rpath -Wl,/opt/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-11.0.1/libxml2-2 .9.12-524uah5j47mrx6brrbe7vd2g52ql57su/lib -o .libs/abisym abisym.o -L/opt/spack/opt/spack/linux-ubuntu18.04-sky lake/gcc-11.0.1/libxml2-2.9.12-524uah5j47mrx6brrbe7vd2g52ql57su/lib ../src/.libs/libabigail.so -lpthread -lelf -l dw -Wl,-rpath -Wl,/opt/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-11.0.1/libabigail-master-ffmphynv5gylndtupyl gupunh4uuexmd/lib And that results in all sorts of expected errors (truncated): >> 307 make[2]: *** [abisym] Error 1 >> 308 /usr/bin/ld: /code/libabigail/src/.libs/libabigail.so: undefined reference to `xmlFree' >> 309 /usr/bin/ld: /code/libabigail/src/.libs/libabigail.so: undefined reference to `xmlStrEqual' Is there something special I need to do to have it generated, and if it's explicitly left out, why is that? Best, Vanessa On 10/18/21, 10:25 AM, "Mark Wielaard" <mark@klomp.org> wrote: Hi Vanessa, On Mon, 2021-10-18 at 15:27 +0000, Sochat, Vanessa wrote: > I tried the gamut of versions from elfutils, down to 0.163 in spack: > > https://urldefense.us/v3/__https://github.com/spack/spack/blob/30e8dd95b54bb60b0b696ec85fb7f9b71f5e79dc/var/spack/repos/builtin/packages/elfutils/package.py*L25__;Iw!!G2kpM7uM-TzIFchu!h0AKXbCcCRl3iqq3HUc8C5GUYSCIXn5_pIKG3AejPVKHJ_N1lT4GhawmND2exwge$ > > And no luck. In that case I suspect somehow the build isn't using the right dwarf.h header. It might be the: depends_on('libdwarf') libabigail doesn't depend on libdwarf and libdwarf is not part of elfutils. It does provide a dwarf.h header though, that might simply not be compatible. elfutils-devel install it in /usr/include/dwarf.h while libdwarf-devel installs it in /usr/include/libdwarf/dwarf.h So in theory they shouldn't conflict, unless the compiler has /usr/include/libdwarf on the include path. > Notably, when I originally added libabigail I didn't see this error: > https://urldefense.us/v3/__https://github.com/spack/spack/commit/ef9a607c4c3bd01d6bcf3141244fd29__;!!G2kpM7uM-TzIFchu!h0AKXbCcCRl3iqq3HUc8C5GUYSCIXn5_pIKG3AejPVKHJ_N1lT4GhawmNCpML59m$ > 41725e92f#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. Not saying the PL1/PLI confusion shouldn't be fixed (it is a really odd typo), but it is somewhat curious nobody else has reported this issue. Which is why I suspect that somehow your build is using the "wrong" dwarf.h. Because all elfutils/libdw versions of dwarf.h do have DW_LANG_PL1 defined. If you are picking up a non-elfutils/libdw dwarf.h maybe that explains some of the other build issues too? Cheers, Mark ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Patch for Incorrect Symbol DW_LANG_PL1 -> DW_LANG_PLI 2021-10-18 17:08 ` Sochat, Vanessa @ 2021-10-18 18:03 ` Ben Woodard 2021-10-18 20:38 ` Sochat, Vanessa 0 siblings, 1 reply; 8+ messages in thread From: Ben Woodard @ 2021-10-18 18:03 UTC (permalink / raw) To: Sochat, Vanessa; +Cc: libabigail What do you get when you do pkg-config —libs libxml-2.0? $ pkg-config --libs libxml-2.0 -lxml2 Which version of autoconf do you have? The PKG_CHECK_MODULES macro in the configure.ac should should AC_SUBST((XML_LIBS)) and so it should be there in the link line. According to https://autotools.io/pkgconfig/pkg_check_modules.html there were some older version of the modules that didn’t have this behavior. $ cat -n configure.ac | grep -A5 -B5 XML 243 244 AC_SUBST(DW_LIBS) 245 AC_SUBST([ELF_LIBS]) 246 247 dnl Check for dependency: libxml 248 LIBXML2_VERSION=2.6.22 249 PKG_CHECK_MODULES(XML, libxml-2.0 >= $LIBXML2_VERSION) 250 251 AC_SUBST(LIBXML2_VERSION) 252 AC_SUBST(XML_LIBS) 253 AC_SUBST(XML_CFLAGS) 254 255 dnl Check for some programs like rm, mkdir, etc ... 256 AC_CHECK_PROG(HAS_RM, rm, yes, no) 257 if test x$HAS_RM = xno; then 258 AC_MSG_ERROR([could not find the program 'rm' installed]) -- 549 AM_CONDITIONAL(ENABLE_FEDABIPKGDIFF, test x$ENABLE_FEDABIPKGDIFF = xyes) 550 AM_CONDITIONAL(ENABLE_RUNNING_TESTS_WITH_PY3, test x$RUN_TESTS_WITH_PY3 = xyes) 551 AM_CONDITIONAL(ENABLE_PYTHON3_INTERPRETER, test x$PYTHON3_INTERPRETER != xno) 552 AC_SUBST(PYTHON) 553 554 DEPS_CPPFLAGS="$XML_CFLAGS" 555 AC_SUBST(DEPS_CPPFLAGS) 556 557 dnl Check for the presence of doxygen program 558 559 if test x$ENABLE_APIDOC != xno; then -- 591 592 AX_VALGRIND_CHECK 593 594 dnl Set the list of libraries libabigail depends on 595 596 DEPS_LIBS="$XML_LIBS $ELF_LIBS $DW_LIBS" 597 AC_SUBST(DEPS_LIBS) 598 599 if test x$ABIGAIL_DEVEL != x; then 600 CFLAGS="-g -Og -Wall -Wextra -Werror -D_FORTIFY_SOURCE=2" 601 CXXFLAGS="-g -Og -Wall -Wextra -Werror -D_FORTIFY_SOURCE=2 -D_GLIBCXX_DEBUG" All of that looks correct to me. So I think something may not be correct in your build environment but I don’t see how you are getting past the configure test and getting all of the way down to the build where it fails. -ben > On Oct 18, 2021, at 10:08 AM, Sochat, Vanessa via Libabigail <libabigail@sourceware.org> wrote: > > Hi Mark, > > That was a great idea! It was an oversight to add libdwarf, and it compiles without it. For an install from source, the issue I'm hitting is that the link line doesn't appear to have -lxml2: > > libtool: link: /opt/spack/lib/spack/env/gcc/g++ -fvisibility=hidden -I/code/libabigail/include -I/code/libabigail > /tools -fPIC -g -O2 -std=c++11 -Wl,-rpath -Wl,/opt/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-11.0.1/libxml2-2 > .9.12-524uah5j47mrx6brrbe7vd2g52ql57su/lib -o .libs/abisym abisym.o -L/opt/spack/opt/spack/linux-ubuntu18.04-sky > lake/gcc-11.0.1/libxml2-2.9.12-524uah5j47mrx6brrbe7vd2g52ql57su/lib ../src/.libs/libabigail.so -lpthread -lelf -l > dw -Wl,-rpath -Wl,/opt/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-11.0.1/libabigail-master-ffmphynv5gylndtupyl > gupunh4uuexmd/lib > > And that results in all sorts of expected errors (truncated): > >>> 307 make[2]: *** [abisym] Error 1 >>> 308 /usr/bin/ld: /code/libabigail/src/.libs/libabigail.so: undefined reference to `xmlFree' >>> 309 /usr/bin/ld: /code/libabigail/src/.libs/libabigail.so: undefined reference to `xmlStrEqual' > > Is there something special I need to do to have it generated, and if it's explicitly left out, why is that? > > Best, > > Vanessa > > On 10/18/21, 10:25 AM, "Mark Wielaard" <mark@klomp.org> wrote: > > Hi Vanessa, > > On Mon, 2021-10-18 at 15:27 +0000, Sochat, Vanessa wrote: >> I tried the gamut of versions from elfutils, down to 0.163 in spack: >> >> https://urldefense.us/v3/__https://github.com/spack/spack/blob/30e8dd95b54bb60b0b696ec85fb7f9b71f5e79dc/var/spack/repos/builtin/packages/elfutils/package.py*L25__;Iw!!G2kpM7uM-TzIFchu!h0AKXbCcCRl3iqq3HUc8C5GUYSCIXn5_pIKG3AejPVKHJ_N1lT4GhawmND2exwge$ >> >> And no luck. > > In that case I suspect somehow the build isn't using the right dwarf.h > header. It might be the: > > depends_on('libdwarf') > > libabigail doesn't depend on libdwarf and libdwarf is not part of > elfutils. It does provide a dwarf.h header though, that might simply > not be compatible. > > elfutils-devel install it in /usr/include/dwarf.h > while libdwarf-devel installs it in /usr/include/libdwarf/dwarf.h > > So in theory they shouldn't conflict, unless the compiler has > /usr/include/libdwarf on the include path. > >> Notably, when I originally added libabigail I didn't see this error: >> https://urldefense.us/v3/__https://github.com/spack/spack/commit/ef9a607c4c3bd01d6bcf3141244fd29__;!!G2kpM7uM-TzIFchu!h0AKXbCcCRl3iqq3HUc8C5GUYSCIXn5_pIKG3AejPVKHJ_N1lT4GhawmNCpML59m$ >> 41725e92f#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. > > Not saying the PL1/PLI confusion shouldn't be fixed (it is a really odd > typo), but it is somewhat curious nobody else has reported this issue. > Which is why I suspect that somehow your build is using the "wrong" > dwarf.h. Because all elfutils/libdw versions of dwarf.h do have > DW_LANG_PL1 defined. If you are picking up a non-elfutils/libdw dwarf.h > maybe that explains some of the other build issues too? > > Cheers, > > Mark > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Patch for Incorrect Symbol DW_LANG_PL1 -> DW_LANG_PLI 2021-10-18 18:03 ` Ben Woodard @ 2021-10-18 20:38 ` Sochat, Vanessa 0 siblings, 0 replies; 8+ messages in thread From: Sochat, Vanessa @ 2021-10-18 20:38 UTC (permalink / raw) To: Woodard, Ben [LLNL Collaborator]; +Cc: libabigail Hey everyone! Okay, everything is working beautifully – here is the final recipe: https://github.com/spack/spack/pull/26807/files And details about what went wrong. The previous issue (resolved) about the missing symbol was because I added libdwarf as a dependency – which didn’t need to be there. Removing that dependency we could remove the patch. After that, the first issue was that without running autoreconf with f, it was looking for some RedHat specific library: g++: fatal error: cannot read spec file '/usr/lib/rpm/redhat/redhat-hardened-ld': No such file or directory Adding the force “fixed” this, but added the unintended consequence that a syntax error was skipped over: >> 117 /code/libabigail/configure: line 16980: syntax error near unexpected token `XML,' 118 /code/libabigail/configure: line 16980: `PKG_CHECK_MODULES(XML, libxml-2.0 >= $LIBXML2_VERSION)' And that hairballed down into not finding any of the xml symbols, and -lxml2 not being added as a flag: >> 307 make[2]: *** [abisym] Error 1 >> 308 /usr/bin/ld: /code/libabigail/src/.libs/libabigail.so: undefined reference to `xmlFree' >> 309 /usr/bin/ld: /code/libabigail/src/.libs/libabigail.so: undefined reference to `xmlStrEqual' (truncated) So first what I tried doing is adding XML_LIBS=-lxml2 to the configure args, and that worked yay! But then Ben (Woodard) told me that on RedHat linux there is a pkgconf library that provides PKG_CHECK_MODULES, and so I added that as a dependency, tried removing the extra flags, and all worked! So really the only thing needed (for spack on a Debian distribution) is to ensure you have pkgconf and then also to still force the autoreconf so it doesn’t look for redhat stuffs 😊 If anyone is interested in a development environment in a container (installing and updating via spack) this should fit the bill: https://github.com/buildsi/libabigail-dev. Until the PR for my updates linked above is merged, you can pull the container from my Docker Hub (instructions in README). Thanks for the help y’all! Best, Vanessa From: Ben Woodard <woodard@redhat.com> Date: Monday, October 18, 2021 at 12:03 PM To: "Sochat, Vanessa" <sochat1@llnl.gov> Cc: "libabigail@sourceware.org" <libabigail@sourceware.org> Subject: Re: Patch for Incorrect Symbol DW_LANG_PL1 -> DW_LANG_PLI What do you get when you do pkg-config —libs libxml-2.0? $ pkg-config --libs libxml-2.0 -lxml2 Which version of autoconf do you have? The PKG_CHECK_MODULES macro in the configure.ac should should AC_SUBST((XML_LIBS)) and so it should be there in the link line. According to https://autotools.io/pkgconfig/pkg_check_modules.html<https://urldefense.us/v3/__https:/autotools.io/pkgconfig/pkg_check_modules.html__;!!G2kpM7uM-TzIFchu!ioaOqe7UPhX3qxJ6N4cgN0sDTf6tqJfHJHSN7mSn-7AjBfi8aVuaNHSQxhNEq7OM$> there were some older version of the modules that didn’t have this behavior. $ cat -n configure.ac | grep -A5 -B5 XML 243 244 AC_SUBST(DW_LIBS) 245 AC_SUBST([ELF_LIBS]) 246 247 dnl Check for dependency: libxml 248 LIBXML2_VERSION=2.6.22 249 PKG_CHECK_MODULES(XML, libxml-2.0 >= $LIBXML2_VERSION) 250 251 AC_SUBST(LIBXML2_VERSION) 252 AC_SUBST(XML_LIBS) 253 AC_SUBST(XML_CFLAGS) 254 255 dnl Check for some programs like rm, mkdir, etc ... 256 AC_CHECK_PROG(HAS_RM, rm, yes, no) 257 if test x$HAS_RM = xno; then 258 AC_MSG_ERROR([could not find the program 'rm' installed]) -- 549 AM_CONDITIONAL(ENABLE_FEDABIPKGDIFF, test x$ENABLE_FEDABIPKGDIFF = xyes) 550 AM_CONDITIONAL(ENABLE_RUNNING_TESTS_WITH_PY3, test x$RUN_TESTS_WITH_PY3 = xyes) 551 AM_CONDITIONAL(ENABLE_PYTHON3_INTERPRETER, test x$PYTHON3_INTERPRETER != xno) 552 AC_SUBST(PYTHON) 553 554 DEPS_CPPFLAGS="$XML_CFLAGS" 555 AC_SUBST(DEPS_CPPFLAGS) 556 557 dnl Check for the presence of doxygen program 558 559 if test x$ENABLE_APIDOC != xno; then -- 591 592 AX_VALGRIND_CHECK 593 594 dnl Set the list of libraries libabigail depends on 595 596 DEPS_LIBS="$XML_LIBS $ELF_LIBS $DW_LIBS" 597 AC_SUBST(DEPS_LIBS) 598 599 if test x$ABIGAIL_DEVEL != x; then 600 CFLAGS="-g -Og -Wall -Wextra -Werror -D_FORTIFY_SOURCE=2" 601 CXXFLAGS="-g -Og -Wall -Wextra -Werror -D_FORTIFY_SOURCE=2 -D_GLIBCXX_DEBUG" All of that looks correct to me. So I think something may not be correct in your build environment but I don’t see how you are getting past the configure test and getting all of the way down to the build where it fails. -ben On Oct 18, 2021, at 10:08 AM, Sochat, Vanessa via Libabigail <libabigail@sourceware.org<mailto:libabigail@sourceware.org>> wrote: Hi Mark, That was a great idea! It was an oversight to add libdwarf, and it compiles without it. For an install from source, the issue I'm hitting is that the link line doesn't appear to have -lxml2: libtool: link: /opt/spack/lib/spack/env/gcc/g++ -fvisibility=hidden -I/code/libabigail/include -I/code/libabigail /tools -fPIC -g -O2 -std=c++11 -Wl,-rpath -Wl,/opt/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-11.0.1/libxml2-2 .9.12-524uah5j47mrx6brrbe7vd2g52ql57su/lib -o .libs/abisym abisym.o -L/opt/spack/opt/spack/linux-ubuntu18.04-sky lake/gcc-11.0.1/libxml2-2.9.12-524uah5j47mrx6brrbe7vd2g52ql57su/lib ../src/.libs/libabigail.so -lpthread -lelf -l dw -Wl,-rpath -Wl,/opt/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-11.0.1/libabigail-master-ffmphynv5gylndtupyl gupunh4uuexmd/lib And that results in all sorts of expected errors (truncated): 307 make[2]: *** [abisym] Error 1 308 /usr/bin/ld: /code/libabigail/src/.libs/libabigail.so: undefined reference to `xmlFree' 309 /usr/bin/ld: /code/libabigail/src/.libs/libabigail.so: undefined reference to `xmlStrEqual' Is there something special I need to do to have it generated, and if it's explicitly left out, why is that? Best, Vanessa On 10/18/21, 10:25 AM, "Mark Wielaard" <mark@klomp.org<mailto:mark@klomp.org>> wrote: Hi Vanessa, On Mon, 2021-10-18 at 15:27 +0000, Sochat, Vanessa wrote: I tried the gamut of versions from elfutils, down to 0.163 in spack: https://urldefense.us/v3/__https://github.com/spack/spack/blob/30e8dd95b54bb60b0b696ec85fb7f9b71f5e79dc/var/spack/repos/builtin/packages/elfutils/package.py*L25__;Iw!!G2kpM7uM-TzIFchu!h0AKXbCcCRl3iqq3HUc8C5GUYSCIXn5_pIKG3AejPVKHJ_N1lT4GhawmND2exwge$<https://urldefense.us/v3/__https:/github.com/spack/spack/blob/30e8dd95b54bb60b0b696ec85fb7f9b71f5e79dc/var/spack/repos/builtin/packages/elfutils/package.py*L25__;Iw!!G2kpM7uM-TzIFchu!h0AKXbCcCRl3iqq3HUc8C5GUYSCIXn5_pIKG3AejPVKHJ_N1lT4GhawmND2exwge$> And no luck. In that case I suspect somehow the build isn't using the right dwarf.h header. It might be the: depends_on('libdwarf') libabigail doesn't depend on libdwarf and libdwarf is not part of elfutils. It does provide a dwarf.h header though, that might simply not be compatible. elfutils-devel install it in /usr/include/dwarf.h while libdwarf-devel installs it in /usr/include/libdwarf/dwarf.h So in theory they shouldn't conflict, unless the compiler has /usr/include/libdwarf on the include path. Notably, when I originally added libabigail I didn't see this error: https://urldefense.us/v3/__https://github.com/spack/spack/commit/ef9a607c4c3bd01d6bcf3141244fd29__;!!G2kpM7uM-TzIFchu!h0AKXbCcCRl3iqq3HUc8C5GUYSCIXn5_pIKG3AejPVKHJ_N1lT4GhawmNCpML59m$<https://urldefense.us/v3/__https:/github.com/spack/spack/commit/ef9a607c4c3bd01d6bcf3141244fd29__;!!G2kpM7uM-TzIFchu!h0AKXbCcCRl3iqq3HUc8C5GUYSCIXn5_pIKG3AejPVKHJ_N1lT4GhawmNCpML59m$> 41725e92f#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. Not saying the PL1/PLI confusion shouldn't be fixed (it is a really odd typo), but it is somewhat curious nobody else has reported this issue. Which is why I suspect that somehow your build is using the "wrong" dwarf.h. Because all elfutils/libdw versions of dwarf.h do have DW_LANG_PL1 defined. If you are picking up a non-elfutils/libdw dwarf.h maybe that explains some of the other build issues too? Cheers, Mark ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Patch for Incorrect Symbol DW_LANG_PL1 -> DW_LANG_PLI 2021-10-17 20:53 Patch for Incorrect Symbol DW_LANG_PL1 -> DW_LANG_PLI Sochat, Vanessa 2021-10-17 22:04 ` Mark Wielaard @ 2021-10-19 10:58 ` Dodji Seketeli 1 sibling, 0 replies; 8+ messages in thread From: Dodji Seketeli @ 2021-10-19 10:58 UTC (permalink / raw) To: Sochat, Vanessa via Libabigail; +Cc: Sochat, Vanessa Hello Vanessa! "Sochat, Vanessa via Libabigail" <libabigail@sourceware.org> a écrit: > Hi Libabigail (and master Dodji!), Hehe, I am unfortunately not a master, just an eternal student who is super happy to welcome you here. > A symbol in elfutils was renamed (see line 7 here) in elfutils: > > https://chromium.googlesource.com/external/elfutils/+/515dd0acc77673c953380bcf5ccfb05b83c5a3ab/NEWS > > 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' > > And after some poking I figured out that this line > https://sourceware.org/git/?p=libabigail.git;a=blob;f=src/abg-dwarf-reader.cc;h=1d6ad24cbfcc2d94c07311bb04112f14f4f0e71c;hb=HEAD#l11056 > needs to be DW_LANG_PLI instead of DW_LANG_PL1. Right. My bad, indeed. Of course that language that I call "PEE ELL ONE" is actually written PLI or PL/1. I can't have it both ways, hehe. Lesson learned :-) > I am attaching the patch I used to make the fix in spack: https://github.com/spack/spack/blob/03f84fb440770101816dad61ca59cf1bebf1997b/var/spack/repos/builtin/packages/libabigail/package.py#L37 Thanks a lot. I have just slightly amended it to add a ChangeLog to the patch and also to fix the typo in several other places of the source code. You will find below the version of the patch that I am applying to the repository. > If you want to reproduce that bug, you should be able to clone spack, comment out the line for the patch, add spack’s bin to the path, and then spack install libabigail. > > I’ve also been having some trouble building libabigail from the git > repository – the instructions in the sourceware docs don’t work > completely, as I get a “syntax error near unexpected token ‘XML,’ and > commenting out that line gets a bit further, but then errors missing > library paths for libxml (which I’ve added). Do you have your release > scripts you might share to reproduce what is in the release tarball? I don't have a particular script, but looking at the hopefully fruitful discussions you had with The Members Of The Crew, in the thread, I think you have it all figured now. > Thank you, and thank you for all the recent work on libabigail! Thanks. And many more thanks for taking the time to look into libabigail. It's really appreciated. Please find below the version of the patch that I applied to the master branch of the git repository. Cheers, From 72034525b2e7e7fb82581aa640296688bf0f78db Mon Sep 17 00:00:00 2001 From: Vanessa Sochat <sochat1@llnl.gov> Date: Fri, 15 Oct 2021 05:17:47 +0000 Subject: [PATCH] Fixing incorrect symbol * include/abg-ir.h (translation_unit::language<>LANG_PLI): Rename LANG_PL1 into this. * src/abg-dwarf-reader.cc (dwarf_language_to_tu_language): Rename DW_LANG_PL1 into DW_LANG_PLI. (get_default_array_lower_bound): Rename translation_unit::LANG_PL1 into translation_unit::LANG_PLI. * src/abg-ir.cc (translation_unit_language_to_string): Rename translation_unit::LANG_PL1 into case translation_unit::LANG_PLI. (string_to_translation_unit_language): Rename translation_unit::LANG_PL1 into translation_unit::LANG_PLI. Signed-off-by: @vsoch <vsoch@noreply.users.github.com> Signed-off-by: Dodji Seketeli <dodji@redhat.com> --- include/abg-ir.h | 2 +- src/abg-dwarf-reader.cc | 6 +++--- src/abg-ir.cc | 8 ++++---- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/include/abg-ir.h b/include/abg-ir.h index a651d1b7..a0ef29b9 100644 --- a/include/abg-ir.h +++ b/include/abg-ir.h @@ -665,7 +665,7 @@ public: LANG_Pascal83, LANG_Modula2, LANG_Java, - LANG_PL1, + LANG_PLI, LANG_UPC, LANG_D, LANG_Python, diff --git a/src/abg-dwarf-reader.cc b/src/abg-dwarf-reader.cc index ccc5e54d..74ab95f3 100644 --- a/src/abg-dwarf-reader.cc +++ b/src/abg-dwarf-reader.cc @@ -11053,8 +11053,8 @@ dwarf_language_to_tu_language(size_t l) return translation_unit::LANG_Ada95; case DW_LANG_Fortran95: return translation_unit::LANG_Fortran95; - case DW_LANG_PL1: - return translation_unit::LANG_PL1; + case DW_LANG_PLI: + return translation_unit::LANG_PLI; case DW_LANG_ObjC: return translation_unit::LANG_ObjC; case DW_LANG_ObjC_plus_plus: @@ -11160,7 +11160,7 @@ get_default_array_lower_bound(translation_unit::language l) case translation_unit::LANG_Java: value = 0; break; - case translation_unit::LANG_PL1: + case translation_unit::LANG_PLI: value = 1; break; case translation_unit::LANG_UPC: diff --git a/src/abg-ir.cc b/src/abg-ir.cc index af16ff32..edebb26f 100644 --- a/src/abg-ir.cc +++ b/src/abg-ir.cc @@ -1522,8 +1522,8 @@ translation_unit_language_to_string(translation_unit::language l) return "LANG_Modula2"; case translation_unit::LANG_Java: return "LANG_Java"; - case translation_unit::LANG_PL1: - return "LANG_PL1"; + case translation_unit::LANG_PLI: + return "LANG_PLI"; case translation_unit::LANG_UPC: return "LANG_UPC"; case translation_unit::LANG_D: @@ -1588,8 +1588,8 @@ string_to_translation_unit_language(const string& l) return translation_unit::LANG_Modula2; else if (l == "LANG_Java") return translation_unit::LANG_Java; - else if (l == "LANG_PL1") - return translation_unit::LANG_PL1; + else if (l == "LANG_PLI") + return translation_unit::LANG_PLI; else if (l == "LANG_UPC") return translation_unit::LANG_UPC; else if (l == "LANG_D") -- 2.32.0 -- Dodji ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-10-19 10:58 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-10-17 20:53 Patch for Incorrect Symbol DW_LANG_PL1 -> DW_LANG_PLI Sochat, Vanessa 2021-10-17 22:04 ` Mark Wielaard 2021-10-18 15:27 ` Sochat, Vanessa 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
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).