Do we want versioned symbols in ncurses?

Do we want versioned symbols in ncurses?

[B. Wilson]

Hey Guix,

Is there any particular reason why our current ncurses packages builds without
versioned symbols? Upstream specifies only default versions (i.e. via @@), no
forced ones, so IIUC that should make the library drop-in replaceable for
everything we have so far. Am I missing something?

Building with symbols is easy enough: just configure --with-versioned-syms=yes.

I ran into this after encountering a project that explicitly uses ncurses
symbol versions. It is simple enough to carry a custom ncurses in my personal
channel for this, but if possible I thought it would be cool to have it in the
main one.

Thoughts?

Re: Do we want versioned symbols in ncurses?

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]

B. Wilson schreef op di 12-04-2022 om 12:04 [+0900]:
> Hey Guix,
> 
> Is there any particular reason why our current ncurses packages builds without
> versioned symbols? Upstream specifies only default versions (i.e. via @@), no
> forced ones, so IIUC that should make the library drop-in replaceable for
> everything we have so far. Am I missing something?
> 
> Building with symbols is easy enough: just configure --with-versioned-syms=yes.
> 
> I ran into this after encountering a project that explicitly uses ncurses
> symbol versions. It is simple enough to carry a custom ncurses in my personal
> channel for this, but if possible I thought it would be cool to have it in the
> main one.
> 
> Thoughts?

Debian has identifier some potential problems, quoted from
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788610#5>:

> When using this option, quite a lot of internal symbols which are not
> part of the API are no longer exported, see the attached list.
> Fortunately according to codesearch.debian.net, very few packages
> seem
> to use any of those symbols:
> 
>  - fpc, in fpcsrc/packages/ncurses/src/form.pp, apparently declares
>    _nc_Default_Form and _nc_Default_Field.  Probably nobody really
>    uses those, but I don't really have a clue of Pascal.
> 
>  - cmake has a lot of hits since it includes a very outdated copy of
>    the form library which is apparently unused.  The /usr/bin/ccmake
>    binary from the cmake-curses-gui package is linked with the system
>    form library and does not use any private symbols from it.
> 
>  - libncursesada and haskell_ncurses declare _nc_has_mouse, but only
>    if NCURSES_VERSION_PATCH < 20081122.  Prior to that date,
>    _nc_has_mouse was actually part of the API so its removal might
>    break some old programs.  This might be a case where the symbol
>    should actually be exported in order not to break the ABI.

We'll have to investigate if this is also a potential problem here.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Do we want versioned symbols in ncurses?

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

B. Wilson schreef op di 12-04-2022 om 12:04 [+0900]:
> I ran into this after encountering a project that explicitly uses ncurses
> symbol versions.

FWIW, there will only ever by one ‘version’ of a symbol, according to
upstream:

<https://lists.nongnu.org/archive/html/bug-ncurses/2016-01/msg00018.html>
(also: <https://bugzilla.redhat.com/show_bug.cgi?id=1875587>)

so I don't quite see the point.

Greetings,
Maxime.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Do we want versioned symbols in ncurses?

[B. Wilson, guix-devel]

Thanks for the quick turnaround.

> Debian has identifier some potential problems, quoted from
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788610#5>:

Ah, yes. The version script also sets a bunch of symbols to local scope. Good
catch.

Off the top of my head, the only sanity-check I can come up with is a brute
force one: iterate through all referrers of ncurses, and check all their ELFs
for missing symbols.

> FWIW, there will only ever by one ‘version’ of a symbol, according to
> upstream:
> 
> <https://lists.nongnu.org/archive/html/bug-ncurses/2016-01/msg00018.html>
> (also: <https://bugzilla.redhat.com/show_bug.cgi?id=1875587>)
> 
> so I don't quite see the point.

Agreed. I'm not sure it's worth the effort given the above.

For in-tree packages, there is vanishing benefit, but my particular pain
point was using a particular external pre-built .so. Oh well.