Re: Patch for Incorrect Symbol DW_LANG_PL1 -> DW_LANG_PLI

[Ben Woodard <woodard@redhat.com>]

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
>