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 : > 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.