Need some help with libyui-ncurses and libyui-mga-ncurses FTBFS

[Neal Gompa]

Hello all,

I've been trying to figure out how to fix the builds for
libyui-ncurses[1] and libyui-mga-ncurses[2].

The errors in both package builds confuse me. It looks like the
"friend" declarations are all broken and it leads to all kinds of
missing methods and members, which breaks the whole thing.

Anyone have any idea how to fix this? I'm out of ideas...

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1987670
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1987669


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Jerry James]

On Sat, Sep 11, 2021 at 1:49 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  I've been trying to figure out how to fix the builds for
>  libyui-ncurses[1] and libyui-mga-ncurses[2].
>
>  The errors in both package builds confuse me. It looks like the
>  "friend" declarations are all broken and it leads to all kinds of
>  missing methods and members, which breaks the whole thing.
>
>  Anyone have any idea how to fix this? I'm out of ideas...
>
>  [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1987670
>  [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1987669 
With libyui-ncurses, at least, I see this when preprocessing YNCursesUI.cc:

# 143 "/usr/include/etip.h" 3 4
class NCURSES_CXX_IMPEXP NCursesPanel;
class NCURSES_CXX_IMPEXP NCursesMenu;
class NCURSES_CXX_IMPEXP NCursesForm;

class NCURSES_CXX_IMPEXP NCursesException
{
...

That is, the macro NCURSES_CXX_IMPEXP has not been expanded.  It is
defined in /usr/include/cursesw.h.

The problem seems to be that libyui-ncurses has its own copy of
/usr/include/cursesw.h, named src/ncursesw.h, but the definitions in
it are not an exact match for the system header file.  It pulls in the
system etip.h, and the mismatched definitions cause the errors you are
seeing.

A simple workaround is to add this to the top of %build:

export CXXFLAGS="-DNCURSES_CXX_IMPEXP= %{build_cxxflags}"

but the real fix would involve reconciling the libyui-ncurses code to
the latest GNU ncurses headers.

I haven't looked at libyui-mga-ncurses, but if the same fix doesn't
work, ping me and I'll take a look.  Regards,
-- 
Jerry James
http://www.jamezone.org/

[Neal Gompa]

On Sat, Sep 11, 2021 at 4:47 PM Jerry James <loganjerry(a)gmail.com&gt; wrote:
>  On Sat, Sep 11, 2021 at 1:49 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  > I've been trying to figure out how to fix the builds for
>  > libyui-ncurses[1] and libyui-mga-ncurses[2].
>  >
>  > The errors in both package builds confuse me. It looks like the
>  > "friend" declarations are all broken and it leads to all kinds of
>  > missing methods and members, which breaks the whole thing.
>  >
>  > Anyone have any idea how to fix this? I'm out of ideas...
>  >
>  > [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1987670
>  > [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1987669
>
>  With libyui-ncurses, at least, I see this when preprocessing YNCursesUI.cc:
>
>  # 143 "/usr/include/etip.h" 3 4
>  class NCURSES_CXX_IMPEXP NCursesPanel;
>  class NCURSES_CXX_IMPEXP NCursesMenu;
>  class NCURSES_CXX_IMPEXP NCursesForm;
>
>  class NCURSES_CXX_IMPEXP NCursesException
>  {
>  ...
>
>  That is, the macro NCURSES_CXX_IMPEXP has not been expanded.  It is
>  defined in /usr/include/cursesw.h.
>
>  The problem seems to be that libyui-ncurses has its own copy of
>  /usr/include/cursesw.h, named src/ncursesw.h, but the definitions in
>  it are not an exact match for the system header file.  It pulls in the
>  system etip.h, and the mismatched definitions cause the errors you are
>  seeing.
>
>  A simple workaround is to add this to the top of %build:
>
>  export CXXFLAGS="-DNCURSES_CXX_IMPEXP= %{build_cxxflags}"
>
>  but the real fix would involve reconciling the libyui-ncurses code to
>  the latest GNU ncurses headers.
>
>  I haven't looked at libyui-mga-ncurses, but if the same fix doesn't
>  work, ping me and I'll take a look.  Regards, 
I tried to figure out how to fix the headers and gave up. For now, I
went with the workaround you suggested and submitted it to Bodhi:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-117b32eafe

Thanks for the help!



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Fabio Valentini]

On Sat, Sep 11, 2021 at 9:49 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  Hello all,
>
>  I've been trying to figure out how to fix the builds for
>  libyui-ncurses[1] and libyui-mga-ncurses[2].
>
>  The errors in both package builds confuse me. It looks like the
>  "friend" declarations are all broken and it leads to all kinds of
>  missing methods and members, which breaks the whole thing.
>
>  Anyone have any idea how to fix this? I'm out of ideas... 
Take this with a grain of salt, I'm certainly not an expert when it
comes to C++. Though I think I might have found the issue in the
ncurses header files. Comparing the contents of ncurses-devel between
f34 (which builds fine) and f35/rawhide (which doesn't), particularly
the /usr/include/ncurses_dll.h file, where those definitions seem to
live:

- NCURSES_IMPEXP is actually defined to a sensible value on f34
- NCURSES_IMPEXP is defined to be NCURSES_EXPORT_GENERAL_EXPORT on f35+
- NCURSES_EXPORT_GENERAL_EXPORT looks like it might not be properly
defined, or at least, defined *after* it is used in the definition of
NCURSES_IMPEXP

This might be a bug in the development snapshot of ncurses that we
seem to be shipping?

Fabio

[Jerry James]

On Sat, Sep 11, 2021 at 2:49 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  Take this with a grain of salt, I'm certainly not an expert when
> it
>  comes to C++. Though I think I might have found the issue in the
>  ncurses header files. Comparing the contents of ncurses-devel between
>  f34 (which builds fine) and f35/rawhide (which doesn't), particularly
>  the /usr/include/ncurses_dll.h file, where those definitions seem to
>  live:
>
>  - NCURSES_IMPEXP is actually defined to a sensible value on f34
>  - NCURSES_IMPEXP is defined to be NCURSES_EXPORT_GENERAL_EXPORT on f35+
>  - NCURSES_EXPORT_GENERAL_EXPORT looks like it might not be properly
>  defined, or at least, defined *after* it is used in the definition of
>  NCURSES_IMPEXP
>
>  This might be a bug in the development snapshot of ncurses that we
>  seem to be shipping? 
No, that's fine.  Macros are expanded lazily, so you can define them
in any order, so long as they are all defined before being used.
-- 
Jerry James
http://www.jamezone.org/