Bug 1863475

Created attachment 1704033 [details]
build.log

file build.log too big, will only attach last 32768 bytes

Created attachment 1704034 [details]
root.log

file root.log too big, will only attach last 32768 bytes

Created attachment 1704035 [details]
state.log

This package was supposed to be opted-out of LTO and did so via the usual mechanisms.  But someone had explicitly added -flto into the passed-in flags.

Until this package switches from ASM based symbol versioning to attribute based symbol versioning it must not use LTO.  I've remove the explicit LTO bits.

THe package still fails its abitest.  So there's still work to do here.

This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

Dear Maintainer,

your package has an open Fails To Build From Source bug for Fedora 33.
Action is required from you.

If you can fix your package to build, perform a build in koji, and either create
an update in bodhi, or close this bug without creating an update, if updating is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to
acknowledge this. If you have already fixed this issue, please close this Bugzilla report.

Following the policy for such packages [2], your package will be orphaned if
this bug remains in NEW state more than 8 weeks (not sooner than 2020-09-28).

A week before the mass branching of Fedora 34 according to the schedule [3],
any packages not successfully rebuilt at least on Fedora 32 will be
retired regardless of the status of this bug.

[1] https://fedoraproject.org/wiki/Updates_Policy
[2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
[3] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html

Dear Maintainer,

your package has an open Fails To Build From Source bug for Fedora 33.
Action is required from you.

If you can fix your package to build, perform a build in koji, and either create
an update in bodhi, or close this bug without creating an update, if updating is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to
acknowledge this. If you have already fixed this issue, please close this Bugzilla report.

Following the policy for such packages [2], your package will be orphaned if
this bug remains in NEW state more than 8 weeks (not sooner than 2020-09-28).

A week before the mass branching of Fedora 34 according to the schedule [3],
any packages not successfully rebuilt at least on Fedora 32 will be
retired regardless of the status of this bug.

[1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
[2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
[3] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html

Dear Maintainer,

your package has an open Fails To Build From Source bug for Fedora 33.
Action is required from you.

If you can fix your package to build, perform a build in koji, and either create
an update in bodhi, or close this bug without creating an update, if updating is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to
acknowledge this. If you have already fixed this issue, please close this Bugzilla report.

Following the policy for such packages [2], your package will be orphaned if
this bug remains in NEW state more than 8 weeks (not sooner than 2020-09-28).

A week before the mass branching of Fedora 34 according to the schedule [3],
any packages not successfully rebuilt at least on Fedora 32 will be
retired regardless of the status of this bug.

[1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
[2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
[3] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html

From the attached build log:

gcc -O2 -flto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GL
IBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m6
4 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto -std=gnu11 -funsigned-char -fvisibility=hidden
 -specs=/builddir/build/BUILD/efivar-37/src/include/gcc.specs -fno-merge-constants  -L. -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/us
r/lib/rpm/redhat/redhat-hardened-ld -flto  -Wl,--add-needed -Wl,--build-id -Wl,--no-allow-shlib-undefined -Wl,--no-undefined-version -Wl,-z
,now -Wl,-z,muldefs -Wl,-z,relro -Wl,--fatal-warnings     -DLIBEFIVAR_VERSION=37 -D_GNU_SOURCE -I/builddir/build/BUILD/efivar-37/src/includ
e/  -shared -Wl,-soname,libefivar.so.1 -Wl,--version-script=libefivar.map  \
  -o libefivar.so crc32.o dp.o dp-acpi.o dp-hw.o dp-media.o dp-message.o efivarfs.o error.o export.o guid.o guids.o guid-symbols.o lib.o va
rs.o -ldl 
{standard input}: Assembler messages:
{standard input}: Error: invalid attempt to declare external version name as default in symbol `efi_set_variable@@LIBEFIVAR_0.24'
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed

That was worked around by disabling LTO in efivar-37-13.

Now only abicheck tests fail on some architectures:

+ make abicheck
make -C src abicheck
make[1]: Entering directory '/builddir/build/BUILD/efivar-37/src'
make[2]: Entering directory '/builddir/build/BUILD/efivar-37/src'
make[2]: Nothing to be done for 'deps'.
make[2]: Leaving directory '/builddir/build/BUILD/efivar-37/src'
abidiff \
	--suppr abignore \
	--headers-dir2 /builddir/build/BUILD/efivar-37/src/include/efivar/ \
	libefivar.abixml \
	libefivar.so
Functions changes summary: 0 Removed, 2 Changed (8 filtered out), 0 Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
2 functions with some indirect sub-type change:
  [C]'function int _efi_set_variable_variadic(efi_guid_t, const char*, uint8_t*, size_t, uint32_t)' at lib.c:44:1 has some indirect sub-type changes:
    parameter 6 of type '...' was added
  [C]'function int efi_error_set(const char*, const char*, int, int, const char*)' at error.c:86:1 has some indirect sub-type changes:
    parameter 6 of type '...' was added
make[1]: *** [/builddir/build/BUILD/efivar-37/src/include/rules.mk:41: libefivar.abicheck] Error 4
make[1]: Leaving directory '/builddir/build/BUILD/efivar-37/src'

*** Bug 1881315 has been marked as a duplicate of this bug. ***

(In reply to Petr Pisar from comment #9)
> Now only abicheck tests fail on some architectures:
> 
Because the test is executed only on x86_64.

The test compares just-compiled header files against a prebuilt XML ABI representation (obtained from debugging data in an old ELF). Current header file (as well as the library) indeed contains the 6th variadic argument:

extern int efi_error_set(const char *filename,
             const char *function,
             int line,
             int error,
             const char *fmt, ...)
            __attribute__((__visibility__ ("default")))
            __attribute__((__nonnull__ (1, 2, 5)))
            __attribute__((__format__ (printf, 5, 6)));

But the prebuilt ABI representation does not list the argument:

    <function-decl name='efi_error_set' mangled-name='efi_error_set' filepath='/usr/include/string.h' line='100' column='1' visibility='default' binding='global' size-in-bits='64' elf-symbol-id='efi_error_set@@LIBEFIVAR_1.30'>
      <parameter type-id='type-id-58' name='filename' filepath='/usr/include/string.h' line='100' column='1'/>
      <parameter type-id='type-id-58' name='function' filepath='/usr/include/string.h' line='101' column='1'/>
      <parameter type-id='type-id-4' name='line' filepath='/usr/include/string.h' line='102' column='1'/>
      <parameter type-id='type-id-4' name='error' filepath='/usr/include/string.h' line='103' column='1'/>
      <parameter type-id='type-id-58' name='fmt' filepath='/usr/include/string.h' line='104' column='1'/>
      <return type-id='type-id-4'/>
    </function-decl>

So either some of the numerous patches changed one of these without the other one, or current abidiff tool handles the variadic argument differently.

A difference between the last passed build (515f6c544746c6f2aaa2ca3d66a5ec14a9ca70fd) and the first failed build (0ed404667277661aac7e90671e6bce470389b809) is only a spec release 
number bump. So the failure is solely triggered by changing the build root.

The original linker error (invalid attempt to declare external version name as default in symbol `efi_set_variable@@LIBEFIVAR_0.24') is triggered by upgrading binutils. It passes with 2.34.0-8.fc33, fails with 2.35-1.fc33.
The new abidiff error (adding a variadic type) is triggered by removing -flto from efivar.spec CFLAGS.

When I regenerate the prebuilt ABI representation compiled without -flto, abigail notices the variadic 6th argument in the debugging data:

    <function-decl name='efi_error_set' mangled-name='efi_error_set' filepath='src/error.c' line='86' column='1' visibility='default' binding='global' size-in-bits='64' elf-symbol-id='efi_error_set@@LIBEFIVAR_1.30'>
      <parameter type-id='type-id-166' name='filename' filepath='src/error.c' line='86' column='1'/>
      <parameter type-id='type-id-166' name='function' filepath='src/error.c' line='87' column='1'/>
      <parameter type-id='type-id-7' name='line' filepath='src/error.c' line='88' column='1'/>
      <parameter type-id='type-id-7' name='error' filepath='src/error.c' line='89' column='1'/>
      <parameter type-id='type-id-166' name='fmt' filepath='src/error.c' line='90' column='1'/>
      <parameter is-variadic='yes'/>
      <return type-id='type-id-7'/>
    </function-decl>

Now the question is whether it's was just a bug fixed in the compiler/binutils and it annotates the variadic arguments correctly now, or whether ABI of the function indeed changed. I'm inclined to the first option. Otherwise it would mean that the ABI of the library never matched the API in the header file and hopefully somebody would notice.

I reported the missing variadic argument to gcc (bug #1891787). I think a workaround for efivar is to patch the pregenerated XML ABI representation.

FEDORA-2020-6d829f1605 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6d829f1605

FEDORA-2020-6d829f1605 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-6d829f1605`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6d829f1605

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-6d829f1605 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.