Bug 1875587

When the symbol versioning in ncurses was introduced I asked the upstream about its purpose:

https://lists.nongnu.org/archive/html/bug-ncurses/2016-01/msg00018.html
https://lists.nongnu.org/archive/html/bug-ncurses/2016-01/msg00027.html

To me, it doesn't look like a great fit for Fedora when I consider how easily it can break and require rebuilds of packages that wouldn't be needed without symbol versioning.

Compatibility with Debian would be nice, but it would trade compatibility with distributions that don't use the versioning, which still is the upstream default. Any estimates on what percentage of distributions have this feature enabled?
 
Suggestions are welcome.

I plan to investigate the (automated) creation of a link-time object that replaces the .so symbolic link which does not contain symbol versions. This way, Fedora builds would still not use symbol versions for ncurses symbols (maintaining compatibility with other distributions), but Debian binaries would still run on Fedora because the symbols are available at run time.

I don't know when I can provide tool support for this. (The tool that generates the stub link-time libraries would also be useful in several other contexts.)

(In reply to Miroslav Lichvar from comment #1)
> When the symbol versioning in ncurses was introduced I asked the upstream
> about its purpose:
> 
> https://lists.nongnu.org/archive/html/bug-ncurses/2016-01/msg00018.html
> https://lists.nongnu.org/archive/html/bug-ncurses/2016-01/msg00027.html
> 
> To me, it doesn't look like a great fit for Fedora when I consider how
> easily it can break and require rebuilds of packages that wouldn't be needed
> without symbol versioning.
> 
> Compatibility with Debian would be nice, but it would trade compatibility
> with distributions that don't use the versioning, which still is the
> upstream default. Any estimates on what percentage of distributions have
> this feature enabled?
>  

All Debian family distributions have this, including the *very large* Ubuntu family.

So from a usage perspective, it's a *very common* thing.

I faced this issue when I was trying to build Ruby with the WASH SDK (WebAssembly SDK) upstream project's released binary[1] that was built on the Ubuntu focal environment on their GitHub Actions workflow, on my Fedora 36 environment.[2]


```
$ ./configure LDFLAGS="-Xlinker -zstack-size=16777216" \
  --host wasm32-unknown-wasi \
  --with-destdir=./ruby-wasm32-wasi \
  --with-static-linked-ext \
  --with-ext=ripper,monitor
...
/usr/local/wasi-sdk-16.0/bin/clang: /lib64/libtinfo.so.6: no version
information available (required by /usr/local/wasi-sdk-16.0/bin/clang)
/usr/local/wasi-sdk-16.0/bin/clang: /lib64/libtinfo.so.6: no version
information available (required by /usr/local/wasi-sdk-16.0/bin/clang)
/usr/local/wasi-sdk-16.0/bin/clang: /lib64/libtinfo.so.6: no version
information available (required by /usr/local/wasi-sdk-16.0/bin/clang)
...
```

I had to build the WASH SDK[3] from the source to use it on Fedora environment.


[1] https://github.com/WebAssembly/wasi-sdk/releases
[2] https://bugs.ruby-lang.org/issues/19053#note-1
[3] https://github.com/WebAssembly/wasi-sdk

The same issue happens with LLVM compiler found here: https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm/releases

"clang: /lib64/libtinfo.so.5: no version information available (required by clang)"

Rebuilding and reinstalling the ncurses-compat-libs with --with-versioned-syms fixes the issue.

(In reply to Florian Weimer from comment #2)
> I plan to investigate the (automated) creation of a link-time object that
> replaces the .so symbolic link which does not contain symbol versions. This
> way, Fedora builds would still not use symbol versions for ncurses symbols
> (maintaining compatibility with other distributions), but Debian binaries
> would still run on Fedora because the symbols are available at run time.

Florian, is there any news on this tool?

Not yet. In the meantime, you can do the following:

Build ncurses twice, once with symbol versions, once without.

Install the version variant into %{_libdir} under the soname.

In the developer package, turn {%_libdir}/libncurses.so into a linker script (see libc.so), pointing to the *unversioned* file installed somewhere outside the ld.so search path.

This way, linked binaries remain unversioned, but Fedora is still able to run versioned binaries.

Thanks, Florian. I have something that seems to be working, except the generated provides/requires are wrong. I'll see if I can fix that.

(In reply to Miroslav Lichvar from comment #8)
> Thanks, Florian. I have something that seems to be working, except the
> generated provides/requires are wrong. I'll see if I can fix that.

Oh, I had not thought about that. Maybe removing the executable bit from the unversioned file helps?

But the provides for the versioned symbols should be there? What do the dependencies look like?

The main problem is that the devel subpackage gets the libncurses.so.6() provide which other packages will depend on, which would cause the devel subpackage to be installed everywhere.

Do we want the libs subpackage to have the versioned provides/requires? I thought we would want to filter that.

(In reply to Miroslav Lichvar from comment #10)
> The main problem is that the devel subpackage gets the libncurses.so.6()
> provide which other packages will depend on, which would cause the devel
> subpackage to be installed everywhere.

Right, and removing the executable bit should fix that. I forgot about that aspect, sorry.

> Do we want the libs subpackage to have the versioned provides/requires? I
> thought we would want to filter that.

It does provide the ABI, so it should be okay to reflect it in the RPM dependencies. The dependency generators will look at what's in the linked files and not produce versioned Requires: dependencies, I think.

For simplicity I was installing the ncurses programs compiled with versioned symbols, so it appeared in the requirements. I think I can filter that out.

(In reply to Miroslav Lichvar from comment #12)
> For simplicity I was installing the ncurses programs compiled with versioned
> symbols, so it appeared in the requirements. I think I can filter that out.

Or you could use the binaries from the unversioned build. The versioned self-dependency should be harmless, though? Isn't the guidance anyway that subpackages should depend on the exact NVR (or is this specific to downstream)?

This is in rawhide now. Thanks for the suggestions.

I tested building few applications and it seemed to work well. Please test and report any issues, or request untagging if it manages to completely break the system.

Unsetting the executable bit didn't seem to help, so I used the __provides_exclude_from trick.

I think removing the versioned provides+requires might be useful for detecting packages that unexpectedly link with the versioned symbols, which will break their dependencies, and it will also reduce the number of entries in the rpm database (the number of different versions in the all the ncurses libs combined is quite large).

This change broke building of some packages and was reverted:

https://www.mail-archive.com/devel@lists.fedoraproject.org/msg187104.html