Libnice 0.1.15, shared-library=""

Got a request to add libnice, see

No idea what libnice is still, just installed latest available for my gentoo box, it is 0.1.15

Wonder why library name is empty. All other gir files seems to have valid name entries.

$ emerge -pv libnice

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] net-libs/libnice-0.1.15::gentoo  USE="gnutls introspection upnp -libressl" 0 KiB
head -20 /usr/share/gir-1.0/Nice-0.1.gir 
<?xml version="1.0"?>
<!-- This file was automatically generated from C sources - DO NOT EDIT!
To affect the contents of this file, edit the original C definitions,
and/or use gtk-doc annotations.  -->
<repository version="1.2"
  <include name="GObject" version="2.0"/>
  <include name="Gio" version="2.0"/>
  <package name="nice"/>
  <namespace name="Nice"

Likely a build issue. Please, file a bug.

1 Like

Please don’t report an issue upstream about this. libnice 0.1.15 is almost two years old, so your distro is at fault. The latest libnice is 0.1.17, which has a lot of critical fixes. Talk to the Gentoo maintainer for that package, which seems to be the Gentoo GNOME team. Check for open issues and if necessary email alias gnome at or #gentoo-desktop at FreeNode.


Thank you both for your reply.

The problem is that the one who asked for libnice support is from Japan and wants to use libnice with Windows 8.1. Maybe he wants to write some great software using libnice and wants to distribute that worldwide, and some users may then have also an old libnice version with missing name. Well I will read his request more carefully and maybe ask him.

Especially on Windows it makes sense to bundle all this together with the application. It makes the application’s users’ lives much easier and prevents such issues.

But independent from that you might also want to consider doing the same we do with the Rust bindings, the C# and also Vala bindings: ship the bindings code that is generated from the .gir files with the bindings and update them yourself.

If you rely on your users to have the correct versions you’ll have to debug a lot of annoying problems with wrong annotations and similar issues. You won’t even have a stable API for a single bindings release as various annotations can change the API in higher-level languages.

And also quite important, every now and then you’ll have to apply custom fixes to the .gir files before they end up in an actual release of the underlying C library.

1 Like

Yes that is an option, the main Nim developer A. Rumpf would vote for that. But for GTK4 with frequent updates it may be a lot work unfortunately. I have discussed it in more detail in the framed text titled “The GTK Nim Bindings” in Maybe when the Nim and GTK community will grow we will do that.

Especially with GTK4 I think this makes a lot of sense as it’s a moving target and changes a lot, so you want to ensure that your users are using exactly the version you’re also using or otherwise you’ll have to debug all kinds of interesting bugs nobody else will be able to reproduce :slight_smile:

In Nim, do you have a mechanism for conditional compilation? In Rust this has proven very useful: we can autogenerate the bindings and let the user opt-in up to which API version of the underlying they want to require.
So for example the Rust bindings for GStreamer support everything >= 1.8 and for enabling 1.10 (1.12, etc.) APIs the application developer has to explicitly configure the bindings accordingly. That way it’s always clear also from the application developer’s point of view what the minimum required version of the underlying C library is.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.