Bug 2404830

Summary: objcopy from binutils-2.45.50-5.fc44 can't handle btrfs-efi's libbtrfs.so
Product: [Fedora] Fedora Reporter: Michel Lind <michel>
Component: binutilsAssignee: Nick Clifton <nickc>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: dvlasenk, fweimer, jakub, josmyers, ngompa13, nickc, sipoyare, suraj.ghimire7
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2384486    
Attachments:
Description Flags
libbtrfs.so none

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.