Bug 2404830 - objcopy from binutils-2.45.50-5.fc44 can't handle btrfs-efi's libbtrfs.so
Summary: objcopy from binutils-2.45.50-5.fc44 can't handle btrfs-efi's libbtrfs.so
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: binutils
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Nick Clifton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 2384486
TreeView+ depends on / blocked
 
Reported: 2025-10-17 20:46 UTC by Michel Lind
Modified: 2025-11-03 13:34 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)
libbtrfs.so (1.28 MB, application/octet-stream)
2025-10-18 13:35 UTC, Florian Weimer
no flags Details

Description Michel Lind 2025-10-17 20:46:45 UTC
Up to F43's binutils-2.45-1.fc43, objcopy works fine in btrfs-efi's build process.

However, with Rawhide's binutils-2.45.50-5.fc44 it fails with "file format not recognized"

Reproducible: Always

Steps to Reproduce:
1. Rebuild btrfs-efi-20230328^git20240824.496ae85-5.fc43
2. Now rebuild F43's binutils with an epoch bump and the same btrfs-efi in a mock chainbuild
Actual Results:
The first fails with

/usr/bin/objcopy: /builddir/build/BUILD/btrfs-efi-20230328_git20240824.496ae85-build/btrfs-efi-496ae8501f244e38e8
12f234968121bb809e248b/redhat-linux-build/libbtrfs.so: file format not recognized

See https://koji.fedoraproject.org/koji/taskinfo?taskID=138236708 for a Koji scratch build

The second succeeds

Expected Results:
Both succeed, just like in F43: https://koji.fedoraproject.org/koji/buildinfo?buildID=2845519

Comment 1 Florian Weimer 2025-10-18 13:35:29 UTC
Created attachment 2110112 [details]
libbtrfs.so

The objcopy input file, in case it's relevant.

Comment 2 Nick Clifton 2025-11-03 13:34:55 UTC
I have been unable to reproduce this problem locally, but I suspect that I know the cause of the issue:  A bug has been fixed in the objcopy program, where its "--target=<FOO>" command line option was supposed to affect the format of both the input file and the output file.  Instead however it was only selecting the format of the output file.  Now that this bug has been fixed (in the 2.45.50 binutils) --target does what it is supposed to do.  Unfortunately this causes problems for packages that use "objcopy --target..." to change the file format of a binary file.  The change means that the objcopy will fail because the input file is not in the same format as the output file, and --target has said that they are the same.

Fortunately there is a simple fix for this problem:  Use objcopy's --output-target=<FOO> command line option instead of --target=<FOO>.  This will set the format of the output file only, and leave objcopy to automatically determine the format of the input file.  In addition this change is backwards compatible.  ie the --output-target option is supported by all versions of objcopy, even very old ones.

I hope that this helps.


Note You need to log in before you can comment on or make changes to this bug.