Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Mar 2014 17:22:54 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Ryan Lortie <desrt@desrt.ca>
Cc:        kwm@freebsd.org, freebsd-geom@freebsd.org
Subject:   Re: GLib vs. libgeom: g_close()
Message-ID:  <20140318152254.GF21331@kib.kiev.ua>
In-Reply-To: <1395110234.28391.95721417.1EBDEC74@webmail.messagingengine.com>
References:  <1395110234.28391.95721417.1EBDEC74@webmail.messagingengine.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--yRA+Bmk8aPhU85Qt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 17, 2014 at 10:37:14PM -0400, Ryan Lortie wrote:
> hi,
>=20
> I'm part of a team that's trying to get the latest versions of GNOME
> (out of git) building on FreeBSD with the eventual goal of getting a
> "continuous integration" sort of setup so that we can flag FreeBSD
> portability issues in GNOME at an earlier stage.
>=20
> We've made some pretty good progress so far:
>=20
>   https://wiki.gnome.org/Projects/Jhbuild/FreeBSD
>=20
> We hit an issue a bit over a month ago when attempting to get libgtop
> working with the latest GLib on FreeBSD.  Specifically: GLib added a
> g_close() function during the 2.36 cycle which conflicts with the
> g_close() function that is exported by libgeom.
>=20
>   https://developer.gnome.org/glib/stable/glib-File-Utilities.html#g-close
>   http://www.unix.com/man-page/FreeBSD/3/g_close/
>=20
> I tried to write to pjd@ to ask for advice but I didn't receive any
> reply.
>=20
> In tthe short term is that we have had to remove support for reporting
> disk usage statistics on FreeBSD from libgtop in order to avoid the
> conflict.
>=20
> In the medium-long term (maybe FreeBSD 11 timeframe) I was wondering if
> it would be possible to change libgeom so that it only uses one
> namespace (eg: geom_) instead of three (geom_, gctl_, g_).  This would
> allow us to re-enable support for disk statistics and would avoid future
> problems that will surely come up in other situations due to this
> conflict.
>=20
> I understand that GLib was the second library to use the name 'g_close'
> but there are some factors that I think weigh in favour of GLib's
> continued use of the name:
>=20
>  - GLib has a very strong and publicly-stated policy of API/ABI
>    stability
>=20
>  - GLib is extremely widely used on essentially every platform in
>    existence
>=20
>  - GLib's use of the g_ namespace is long-established, predating the
>    existence of libgeom.  It currently has approximately 4000 symbols
>    starting with g_ in this namespace.
>=20
>  - I don't personally believe that it's a good idea to have multiple
>    libraries sharing a namespace, and libgeom is also using three
>    separate namespaces...
>=20
> I appreciate any input on this issue.  I particularly hope to be able to
> find a solution that would allow us to re-enable the filesystem
> statistics reporting on FreeBSD.

You really cannot avoid conflict globally. The solution is to start use
versioning for both glib and libgeom, but this is something which cannot
help immediately. BTW, does Linux build of glib provides versioning ?

As an interim solution, something like the following code fragment should
provide stop-gap measure:

void
my_g_close_hack(int fd)
{
	void *libgeom;
	int (*g_close_f)(int);

	libgeom =3D dlopen("libgeom.so.5", RTLD_LAZY);
	if (libgeom =3D=3D NULL) {
		fprintf(stderr, "Cannot open libgeom.so.5: %s\n", dlerror());
		return;
	}
	g_close_f =3D (int (*)(int))dlfunc(libgeom, "g_close");
	if (g_close_f =3D=3D NULL) {
		fprintf(stderr, "libgeom.so does not resolve g_close: %s\n",
		    dlerror());
		dlclose(libgeom);
		return;
	}
	g_close_f(fd);
	dlclose(libgeom);
}

--yRA+Bmk8aPhU85Qt
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)

iQIcBAEBAgAGBQJTKGTNAAoJEJDCuSvBvK1BVrIP/jpPQ/XpBm7DC0v7Y0tkCPZB
CCQr7B24sAWE4dIYf/TkhZemYU39hrssjzbwoistvycNucyBQBPJ7dKcVL3oEAe+
rJL+etxyaafcVdJxjoHO2TZdBJfUPfbPtfEVF0EGBL4y2yJSnFAeOYhSz7LIr3fc
4uRuKaYMYq8Cxpquaw8tvaqzNnyln2+kq9eCNM5sjEAfyi37J1ruOlFBRCoU7Oxm
1L17L37fh7phCKe1sGcUfTU2gIOAm45WjjqpG+etUzLigmazy/A0VCcq0tbPC9du
zjnnH11SWLO4i3CJx+o859ds7oNM0QWyeC64Mnqz2vgiele+gHtRwho8PZi3TUwg
Zl5ebrqZXoSWSFE6+ZJdhE35e1NOV5s7fdymWeL3UstL9frtsyXmagL6meNM6YzT
e/1F9jdrndHZw9/m975LYivNtFD/qxAOceOt6zWaiUMhELpRkJpo4qlO9n6rFepv
iX/MPepl9jg9pWNMVz0yttmojIKKM3BaHzgfkoTKhX4Vsf43MDsfHMTZiOUsbeyo
VkWBdSv6jh2jKGEBybAyfT/NmRBBoJQWt2F2BRM9JjpwZiUXR+hRp36VLZV+/ZTy
1hh2RcmZxel6s/i6ajAC8L6CUYbe38NbVZzlu03pRrZY6uo3jXOonPPrhvy41Ekm
xbHybwlO52ltC/w+iokT
=5QRr
-----END PGP SIGNATURE-----

--yRA+Bmk8aPhU85Qt--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140318152254.GF21331>