public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
To: Luis Machado <luis.machado@arm.com>,
	"binutils@sourceware.org" <binutils@sourceware.org>
Subject: Re: [PATCH] gprofng: PR29987 bfd/archive.c:1447: undefined reference to `filename_ncmp'
Date: Mon, 16 Jan 2023 16:05:34 -0800	[thread overview]
Message-ID: <0e70554b-6c1e-25ae-3c83-efed1ed5f854@oracle.com> (raw)
In-Reply-To: <85078aba-407e-2576-7eb4-58a457924adc@arm.com>

Hi Luis,

On 1/16/23 06:10, Luis Machado wrote:
> Hi,
>
> I bisected a broken build on aarch64-linux Ubuntu 22.04 to this commit.
>
> It seems to cause a number of undefined references when building with 
> --enable-targets=all.
>
> -- 
> gprofng/src/../../../../repos/binutils-gdb/gprofng/src/Elf.cc:142: 
> undefined reference to `bfd_init'
>
> /usr/bin/ld: ./.libs/libgprofng.a(Elf.o): in function `Elf::Elf(char*)':
> -- 
>
> A master build of binutils-gdb should hopefully run into the problem. 
> Passing --disable-gprofng seems to make the build complete OK.
>
> Could you please take a look at it?



I don't have Ubuntu.
I cannot reproduce the problem on my configuration:

% uname -a
Linux OL8.4-beta3 5.4.17-2102.200.13.el8uek.aarch64 #2 SMP Sun Mar 28 
15:24:03 PDT 2021 aarch64 aarch64 aarch64 GNU/Linux

% gcc --version
gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1.0.1)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% libtool --version
libtool (GNU libtool) 2.4.6
Written by Gordon Matzigkeit, 1996
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


gprofng depends on libopcodes and as I see now gprofng directly depends 
on libbfd.
We use libtool to link gprofng only with libopcodes.
It looks like on my machines, libtool automatically links gprofng with 
libbfd because libopcodes depends on libbfd.

I propose the fix below.
All builds on my machines are OK with and without this fix.
Could you check my fix on your machine ? Or should I push my path to the 
master branch now ?


Thank you,
-Vladimir


% cat 0001-gprofng-link-with-libbfd.patch
 From 8b2b7967649a605935d6810aa58c97437cd46b6b Mon Sep 17 00:00:00 2001
From: Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
Date: Mon, 16 Jan 2023 15:51:44 -0800
Subject: [PATCH] gprofng: link with libbfd

gprofng/ChangeLog
2023-01-16  Vladimir Mezentsev <vladimir.mezentsev@oracle.com>

     PR gprofng/29987
     * src/Makefile.am: Link with libbfd.
     * src/Makefile.in: Rebuild.
---
  gprofng/src/Makefile.am | 1 +
  gprofng/src/Makefile.in | 4 +++-
  2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/gprofng/src/Makefile.am b/gprofng/src/Makefile.am
index 2278b9a39bb..b3423e121e3 100644
--- a/gprofng/src/Makefile.am
+++ b/gprofng/src/Makefile.am
@@ -132,6 +132,7 @@ libgprofng_la_LDFLAGS = -version-info 0:0:0
  # when -nostdlib is passed to libtool.
  # See bug 29364 - libgprofng.so: needs to link against -pthread
  libgprofng_la_LIBADD = $(top_builddir)/../opcodes/libopcodes.la \
+    $(top_builddir)/../bfd/libbfd.la \
      -lpthread -ldl

  dbedir = $(SYSCONFDIR)
diff --git a/gprofng/src/Makefile.in b/gprofng/src/Makefile.in
index 71dccf5f952..90455880ec7 100644
--- a/gprofng/src/Makefile.in
+++ b/gprofng/src/Makefile.in
@@ -158,7 +158,8 @@ am__uninstall_files_from_dir = { \
  am__installdirs = "$(DESTDIR)$(pkglibdir)" "$(DESTDIR)$(bindir)" \
      "$(DESTDIR)$(man1dir)" "$(DESTDIR)$(dbedir)"
  LTLIBRARIES = $(pkglib_LTLIBRARIES)
-libgprofng_la_DEPENDENCIES = $(top_builddir)/../opcodes/libopcodes.la
+libgprofng_la_DEPENDENCIES = $(top_builddir)/../opcodes/libopcodes.la \
+    $(top_builddir)/../bfd/libbfd.la
  am__objects_1 = Application.lo BaseMetric.lo BaseMetricTreeNode.lo \
      CallStack.lo CatchOutOfMemory.lo ClassFile.lo Command.lo \
      CompCom.lo DataObject.lo DataSpace.lo Data_window.lo \
@@ -554,6 +555,7 @@ libgprofng_la_LDFLAGS = -version-info 0:0:0
  # when -nostdlib is passed to libtool.
  # See bug 29364 - libgprofng.so: needs to link against -pthread
  libgprofng_la_LIBADD = $(top_builddir)/../opcodes/libopcodes.la \
+    $(top_builddir)/../bfd/libbfd.la \
      -lpthread -ldl

  dbedir = $(SYSCONFDIR)
-- 
2.31.1










  parent reply	other threads:[~2023-01-17  0:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-12 20:56 vladimir.mezentsev
2023-01-13 23:41 ` Vladimir Mezentsev
2023-01-16 14:10   ` Luis Machado
2023-01-16 19:28     ` Joseph Myers
2023-01-17  0:05     ` Vladimir Mezentsev [this message]
2023-01-17 10:21       ` Luis Machado
2023-01-18  3:35         ` Vladimir Mezentsev

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=0e70554b-6c1e-25ae-3c83-efed1ed5f854@oracle.com \
    --to=vladimir.mezentsev@oracle.com \
    --cc=binutils@sourceware.org \
    --cc=luis.machado@arm.com \
    /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).