Re: Patch for Incorrect Symbol DW_LANG_PL1 -> DW_LANG_PLI

["Sochat, Vanessa" <sochat1@llnl.gov>]

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