Created attachment 1753399 [details]
build.log

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

Created attachment 1753400 [details]
root.log

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

Created attachment 1753401 [details]
state.log

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

Dear Maintainer,

your package has an open Fails To Build From Source bug for Fedora 34.
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 2021-03-29).

A week before the mass branching of Fedora 35 according to the schedule [3],
any packages not successfully rebuilt at least on Fedora 33 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-35/f-35-key-tasks.html

Martin, this package is triggering a mismatched-new-delete and due to -Werror is causing the package to FTBFS.

At this point we're just trying to determine if the diagnostic is correct or not.  If the diagnostic is correct, then we'll leave this issue to the package maintainer to fix.  Obviously if the diagnostic is incorrect, then we'll reassign and tackle it on the GCC side.

If you could take a peek (and the one for libyui-mga-qt that I'll cc you on momentarily) it'd be appreciated.  Thanks.

It doesn't look correct.  The warning points to a new expression when it should point to a delete so something's definitely not right.

/builddir/build/BUILD/libyui-ncurses-58463ca0a1d6815404c5f90fa7e2881429b74d54/src/NCWidgetFactory.cc: In member function 'NCWidgetFactory::createPushButton(YWidget*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
/builddir/build/BUILD/libyui-ncurses-58463ca0a1d6815404c5f90fa7e2881429b74d54/src/NCWidgetFactory.cc:76:65: error: 'operator delete(void*)' called on pointer returned from a mismatched allocation function [-Werror=mismatched-new-delete]
   76 |     NCPushButton * pushButton = new NCPushButton( parent, label );
      |                                                                 ^
/builddir/build/BUILD/libyui-ncurses-58463ca0a1d6815404c5f90fa7e2881429b74d54/src/NCWidgetFactory.cc:76:65: note: returned from 'YWidget::operator new(unsigned long)'

I take it back.  I missed that the note says "returned from 'YWidget::operator new(unsigned int)'" i.e., it's a member operator new() that allocated the memory but the global operator delete() that's implicitly invoked during unwinding to release it.

The warning is caused by class YWidget defining a member operator new(size_t) but no corresponding operator delete(void*).  For example, the optimized dump for NCApplication.C shows this:

;; Function NCApplication::askForExistingDirectory (_ZN13NCApplication23askForExistingDirectoryERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES7_, funcdef_no=5110, decl_uid=83576, cgraph_uid=2041, symbol_order=2059)

struct string NCApplication::askForExistingDirectory (struct NCApplication * const this, const struct string & startDir, const struct string & headline)
{
  void * _4;
  ...
  _4 = YWidget::operator new (688);   <<< member operator new
  NCAskForExistingDirectory::NCAskForExistingDirectory (_4, &D.101155, startDir_5(D), headline_6(D));
  ...
<L6>:
  operator delete (_4, 688);          <<< mismatched global operator delete
  _74 = __builtin_eh_pointer (4);
  __builtin_unwind_resume (_74);

  <bb 58> [count: 0]:
<L21>:
  NCursesEvent::~NCursesEvent (&retEvent);
  _73 = __builtin_eh_pointer (32);
  __builtin_unwind_resume (_73);

}

A simple test case that reproduces the warning is this:

$ cat u.C && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout u.C
struct A {
  A ();
  void* operator new (__SIZE_TYPE__);
};

void* f ()
{
  return new A ();
}

;; Function f (_Z1fv, funcdef_no=0, decl_uid=2359, cgraph_uid=1, symbol_order=0)

void * f ()
{
  void * D.2392;
  void * _3;

  <bb 2> [local count: 1073741824]:
  _3 = A::operator new (1);
  A::A (_3);

  <bb 3> [local count: 1073741824]:
  return _3;

  <bb 4> [count: 0]:
<L1>:
  operator delete (_3, 1);
  _6 = __builtin_eh_pointer (1);
  __builtin_unwind_resume (_6);

}


u.C: In function ‘void* f()’:
u.C:8:17: warning: ‘void operator delete(void*, long unsigned int)’ called on pointer returned from a mismatched allocation function [-Wmismatched-new-delete]
    8 |   return new A ();
      |                 ^
u.C:8:17: note: returned from ‘static void* A::operator new(long unsigned int)’

Whether or not this is a real problem depends on how the member operator new is defined.  If it just returns the result of the global operator new it's most likely okay.  If it returns some other pointer (or does something that needs to be undone when the object is deallocated) it's a bug.  Defining YWidget::operator delete(void*) to correspond to YWidget::operator new(size_t) avoids the warning.   This is by design.

It appears that is likely OK to me.  The _usedOperatorNew is a static data member that is initialized to false, set to true in the operator new, then tested in the ctor in a sanity check, then reset to false.

I think at this point we can declare both of these minor issues with the libyui-* packages.  They can either fix their sources or turn off the warning.

FEDORA-2021-0672b91c97 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-0672b91c97

Proposed as a Freeze Exception for 34-beta by Fedora user ngompa using the blocker tracking app because:

 This fixes a FTBFS for the libyui libraries (used by dnfdragora) in F34.

FEDORA-2021-0672b91c97 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-0672b91c97`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-0672b91c97

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

Discussed during the 2021-03-01 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedFreezeException (Beta)" was made as it is a noticeable issue that cannot be fixed with an update.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-03-01/f34-blocker-review.2021-03-01-17.01.txt

FEDORA-2021-0672b91c97 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days