Bug 229049 - Mk/bsd.port.mk relies on to-be-removed objdump
Summary: Mk/bsd.port.mk relies on to-be-removed objdump
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Port Management Team
URL: https://reviews.freebsd.org/D15904
Depends on:
Blocks: 229046
  Show dependency treegraph
Reported: 2018-06-15 17:13 UTC by Ed Maste
Modified: 2019-09-06 08:58 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer 2018-06-15 17:13:46 UTC
objdump is being removed from the base system (target 12.0). It is currently being used by Mk/bsd.port.mk. Using readelf instead should be relatively straightforward.

objdump -R emits (only) dynamic relocs, while readelf -r emits all relocs; a little awk or sed triggering on the headers (e.g. "Relocation section with addend (.rela.dyn):") may work.
Comment 1 Mathieu Arnold freebsd_committer 2018-06-19 14:04:03 UTC
I was kinda hoping I would never have to touch that make target and that awk script.

Now the problem is going to be find a port that actually triggers those.

It seems readelf only output the file names if more than one file is passed as an argument while objdump always outputs it.  Is there some flag I could not find that would make readelf always write its `File:` header?
Comment 2 Mathieu Arnold freebsd_committer 2018-06-19 14:45:20 UTC
There are three ports using ${OBJDUMP}:


Not sure how they can be fixed.
Comment 3 Ed Maste freebsd_committer 2018-06-19 14:49:35 UTC
(In reply to Mathieu Arnold from comment #2)
Ports that need objdump can just require the binutils port be installed.
Comment 4 Mathieu Arnold freebsd_committer 2018-06-19 14:57:01 UTC
Started a review to fix the problem.
Comment 5 Ed Maste freebsd_committer 2018-06-19 14:57:48 UTC
Ah, it looks like the objdump use is just to see if there is a reference to gets, mktemp, tempnam, tmpnam, or in audit mode also strcpy, strcat, sprintf.

Equivalent information (in a different format) should be available from `nm --dynamic`, and nm also accepts `--print-file-name` if desired.
Comment 6 Mathieu Arnold freebsd_committer 2018-06-20 08:01:57 UTC
Mmmm, nm --print-file-name looks interesting. But the format it uses is harder to parse, especially if the file path contains a space.
I think I'll keep using readelf with a nonexistent first argument, which does what we need here.
Comment 7 Mark Linimon freebsd_committer freebsd_triage 2018-06-25 06:49:50 UTC
New errorlog on aarch64-current with 'configure: error: unable to find objdump':

Comment 8 Ed Maste freebsd_committer 2018-06-29 19:41:08 UTC
(In reply to Mark Linimon from comment #7)
That failure is on arm64 which has never installed GNU objdump. It should be added to PR 229046 or as a blocker of PR 229046, or just add USE_BINUTILS=yes to the port.
Comment 9 Tobias Kortkamp freebsd_committer 2018-06-30 03:53:22 UTC
(In reply to Ed Maste from comment #8)
mbuffer was already fixed in ports r472625
Comment 10 Mark Linimon freebsd_committer freebsd_triage 2018-06-30 04:24:27 UTC
(In reply to Tobias Kortkamp from comment #9)

I hadn't notice that commit.  Thanks.
Comment 11 commit-hook freebsd_committer 2018-06-30 08:37:59 UTC
A commit references this bug:

Author: mat
Date: Sat Jun 30 08:37:33 UTC 2018
New revision: 473605
URL: https://svnweb.freebsd.org/changeset/ports/473605

  Convert to readelf.

  objdump is being removed from HEAD, make sure everything still works
  when this happens.

  PR:		229049
  Reported by:	emaste
  Sponsored by:	Absolight
  Differential Revision:	https://reviews.freebsd.org/D15904

Comment 12 Ed Maste freebsd_committer 2018-11-30 14:05:58 UTC
There are currently two instances of objdump in Mk/:

70:OBJDUMP?=            /usr/bin/objdump


The second (bsd.port.mk) is fine: it is setting up a loop for tools to be set under USE_BINUTILS. I'm not sure what we should do about the first, probably just remove it.

That said, I think this PR can be closed?