From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTPS id 93F6E3858C60 for ; Mon, 18 Oct 2021 18:03:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 93F6E3858C60 Received: from mail-pf1-f200.google.com (mail-pf1-f200.google.com [209.85.210.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-439-MAw9F2E8NVu9GLieNo1Ilw-1; Mon, 18 Oct 2021 14:03:35 -0400 X-MC-Unique: MAw9F2E8NVu9GLieNo1Ilw-1 Received: by mail-pf1-f200.google.com with SMTP id j2-20020a056a00174200b0044d39a43c9bso9483863pfc.22 for ; Mon, 18 Oct 2021 11:03:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=amlnlpG3KeVhxyMJrgP5MVwvDbbiSH4CB4fs+T/vxE8=; b=JUZfOIJvPTqGZBfWAP47dfHmIfzweZxXQJBYiXk16PYjJgY5ddc899wqIlFjz6Yfdn 1vYGocgf7a5fUKCSaUkxIhobn4Wi9TT2+ffd7IklnaY9NqTMua1ufV8A/ZJrT1izSUCr 1kD7Z9z53tcBdozFclquYoDfUPEXeCpPoSiZsol5GQgqtc7TC4waMBvHJTBwOF83MB+Y cZT1+BNI9+RvS92A9RD3xCrTxKwRxxwgsaJ4s5iQUR3Ybud4ARQ8inf06opil2gCce0c kVZCJqrvr0izdiZRvByJvm8GF2JcbEDfuBOpJTeQKIf1mIKXKox0KJt6gp9dAd98mvRT XgWQ== X-Gm-Message-State: AOAM532n5uG8kRgZ9AWzeyRdFPEXxZASgK8skylJNPFQybo7m4MtpVN/ NKqFR+++CxajDLSPR0xCDZIfq9l+v1NZ3c5+N0HO4CQuiZTtu4hy0+kx6jzxjYaRgdNTdFMFD8T t6qa7DEN82aDYUDT8+lSq X-Received: by 2002:a05:6a00:ccb:b0:44c:eb4b:f24e with SMTP id b11-20020a056a000ccb00b0044ceb4bf24emr29764234pfv.16.1634580214142; Mon, 18 Oct 2021 11:03:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyN9yinHJjjlvZgX/Dd+7Zjbdbj61l3osTuEDnwdgh7ewKxmFcuJzsbBCKSW07gqrlhz1IrgA== X-Received: by 2002:a05:6a00:ccb:b0:44c:eb4b:f24e with SMTP id b11-20020a056a000ccb00b0044ceb4bf24emr29764180pfv.16.1634580213587; Mon, 18 Oct 2021 11:03:33 -0700 (PDT) Received: from smtpclient.apple (47-208-193-143.trckcmtc01.res.dyn.suddenlink.net. [47.208.193.143]) by smtp.gmail.com with ESMTPSA id z126sm9957545pgz.55.2021.10.18.11.03.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Oct 2021 11:03:33 -0700 (PDT) From: Ben Woodard Message-Id: <8D884A1E-2505-4FCF-A554-52C81BB8209C@redhat.com> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Patch for Incorrect Symbol DW_LANG_PL1 -> DW_LANG_PLI Date: Mon, 18 Oct 2021 11:03:27 -0700 In-Reply-To: Cc: "libabigail@sourceware.org" To: "Sochat, Vanessa" References: <3FA78256-D980-42E6-87EE-F2CE00957B63@llnl.gov> <68dda582d8a4fd0d58ed355df45e6ceecc18a36f.camel@klomp.org> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, KAM_INFOUSMEBIZ, KAM_LOTSOFHASH, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2021 18:03:48 -0000 What do you get when you do pkg-config =E2=80=94libs libxml-2.0? $ pkg-config --libs libxml-2.0 -lxml2=20 Which version of autoconf do you have?=20 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://au= totools.io/pkgconfig/pkg_check_modules.html there were some older version o= f the modules that didn=E2=80=99t have this behavior. $ cat -n configure.ac | grep -A5 -B5 XML 243=09 244=09AC_SUBST(DW_LIBS) 245=09AC_SUBST([ELF_LIBS]) 246=09 247=09dnl Check for dependency: libxml 248=09LIBXML2_VERSION=3D2.6.22 249=09PKG_CHECK_MODULES(XML, libxml-2.0 >=3D $LIBXML2_VERSION) 250=09 251=09AC_SUBST(LIBXML2_VERSION) 252=09AC_SUBST(XML_LIBS) 253=09AC_SUBST(XML_CFLAGS) 254=09 255=09dnl Check for some programs like rm, mkdir, etc ... 256=09AC_CHECK_PROG(HAS_RM, rm, yes, no) 257=09if test x$HAS_RM =3D xno; then 258=09 AC_MSG_ERROR([could not find the program 'rm' installed]) -- 549=09AM_CONDITIONAL(ENABLE_FEDABIPKGDIFF, test x$ENABLE_FEDABIPKGDIFF = =3D xyes) 550=09AM_CONDITIONAL(ENABLE_RUNNING_TESTS_WITH_PY3, test x$RUN_TESTS_WIT= H_PY3 =3D xyes) 551=09AM_CONDITIONAL(ENABLE_PYTHON3_INTERPRETER, test x$PYTHON3_INTERPRE= TER !=3D xno) 552=09AC_SUBST(PYTHON) 553=09 554=09DEPS_CPPFLAGS=3D"$XML_CFLAGS" 555=09AC_SUBST(DEPS_CPPFLAGS) 556=09 557=09dnl Check for the presence of doxygen program 558=09 559=09if test x$ENABLE_APIDOC !=3D xno; then -- 591=09 592=09AX_VALGRIND_CHECK 593=09 594=09dnl Set the list of libraries libabigail depends on 595=09 596=09DEPS_LIBS=3D"$XML_LIBS $ELF_LIBS $DW_LIBS" 597=09AC_SUBST(DEPS_LIBS) 598=09 599=09if test x$ABIGAIL_DEVEL !=3D x; then 600=09 CFLAGS=3D"-g -Og -Wall -Wextra -Werror -D_FORTIFY_SOURCE=3D2" 601=09 CXXFLAGS=3D"-g -Og -Wall -Wextra -Werror -D_FORTIFY_SOURCE=3D2 = -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=E2=80=99t see how you are getting past th= e configure test and getting all of the way down to the build where it fail= s. -ben > On Oct 18, 2021, at 10:08 AM, Sochat, Vanessa via Libabigail wrote: >=20 > Hi Mark, >=20 > That was a great idea! It was an oversight to add libdwarf, and it compil= es without it. For an install from source, the issue I'm hitting is that th= e link line doesn't appear to have -lxml2: >=20 > libtool: link: /opt/spack/lib/spack/env/gcc/g++ -fvisibility=3Dhidden -I/= code/libabigail/include -I/code/libabigail > /tools -fPIC -g -O2 -std=3Dc++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 abi= sym.o -L/opt/spack/opt/spack/linux-ubuntu18.04-sky > lake/gcc-11.0.1/libxml2-2.9.12-524uah5j47mrx6brrbe7vd2g52ql57s= u/lib ../src/.libs/libabigail.so -lpthread -lelf -l > dw -Wl,-rpath -Wl,/opt/spack/opt/spack/linux-ubuntu18.04-skyla= ke/gcc-11.0.1/libabigail-master-ffmphynv5gylndtupyl > gupunh4uuexmd/lib >=20 > And that results in all sorts of expected errors (truncated): >=20 >>> 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' >=20 > Is there something special I need to do to have it generated, and if it's= explicitly left out, why is that? >=20 > Best, >=20 > Vanessa >=20 > =EF=BB=BFOn 10/18/21, 10:25 AM, "Mark Wielaard" wrote: >=20 > Hi Vanessa, >=20 > 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: >>=20 >> https://urldefense.us/v3/__https://github.com/spack/spack/blob/30e8dd95b= 54bb60b0b696ec85fb7f9b71f5e79dc/var/spack/repos/builtin/packages/elfutils/p= ackage.py*L25__;Iw!!G2kpM7uM-TzIFchu!h0AKXbCcCRl3iqq3HUc8C5GUYSCIXn5_pIKG3A= ejPVKHJ_N1lT4GhawmND2exwge$=20 >>=20 >> And no luck. >=20 > In that case I suspect somehow the build isn't using the right dwarf.h > header. It might be the: >=20 > depends_on('libdwarf') >=20 > 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. >=20 > elfutils-devel install it in /usr/include/dwarf.h > while libdwarf-devel installs it in /usr/include/libdwarf/dwarf.h >=20 > So in theory they shouldn't conflict, unless the compiler has > /usr/include/libdwarf on the include path. >=20 >> Notably, when I originally added libabigail I didn't see this error: >> https://urldefense.us/v3/__https://github.com/spack/spack/commit/ef9a607= c4c3bd01d6bcf3141244fd29__;!!G2kpM7uM-TzIFchu!h0AKXbCcCRl3iqq3HUc8C5GUYSCIX= n5_pIKG3AejPVKHJ_N1lT4GhawmNCpML59m$=20 >> 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. >=20 > Not saying the PL1/PLI confusion shouldn't be fixed (it is a really od= d > 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? >=20 > Cheers, >=20 > Mark >=20