D&C GLug - Home Page

[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] Debian Stable - Entangle - glibc too low a version

 

On Thu, 04 Oct 2012 14:22:50 +0100
Simon Waters <simon@xxxxxxxxxxxxxx> wrote:

> On 04/10/12 13:54, Adrian Midgley wrote:
> > Given
> > 
> > configure: error: Package requirements (glib-2.0 >= 2.26.0) were not met:
> > 
> > Requested 'glib-2.0 >= 2.26.0' but version of GLib is 2.24.2
> > 
> > How can I most safely give the program what it wants to compile and
> > run, without upsetting the rest of the installation?

A chroot would be the simplest way.

sudo debootstrap wheezy /path/wheezy-chroot

Then you can check if the version limitation could be lowered in the
source.

The package will at least build in a chroot. If it needs X to run then
there's a bit of messing around to do with .Xauthority to be able to
run from inside the chroot.

The thing to do is to edit debian/control in the source of the package
to not specify a version for libglib2.0-dev in the Build-Depends line
and rebuild the package, in wheezy, with the default wheezy build
environment and see if the built package depends on a lower version of
libglib2.0-0.

See later, but because libglib2.0-0 uses properly versioned symbols,
the version of libglib2.0-dev installed on the system has no impact on
the dependency of the final .deb - it is determined by the symbol
versioning support of libglib2.0-dev itself.

> But then I'm running Wheezy on home and work desktops so I have glibc 2.32

Just one point, it's glib-2.0 not glibc. glibc == libc6 which is a much
more difficult package to upgrade/downgrade than libglib2.0-0 which is
quite widely used but not actually as difficult.

> Almost certainly the dependency is not a requirement, but a reflection
> of the default build environment, so you can probably build from source,

Sorry, but that just isn't true any more. If a version is explicitly
required by the ./configure script then it almost certainly *is* a
requirement of the source because libglib2.0 has consistently added new
functions at each point release and all the documentation specifies
when a particular function was introduced. glib2.24 was released Sun,
28 Mar 2010. It's not that old.

https://mail.gnome.org/archives/gnome-announce-list/2010-March/msg00067.html

It *might* be that 2.26.0 is the lowest version that the upstream have
actually tested but that would only really happen if the entire
source code tree is very, very recent. (glib2.0 is sufficiently low down
the dependency chain of source code that if it's going to be used it
will be used everywhere in the project and from the very, very start -
significantly earlier than even the first pre-alpha releases.)

http://developer.gnome.org/glib/2.26/api-index-2-26.html

So if the source code uses GDateTime or .ini type config files or does
clever stuff with timezones then there is every reason for the source
to require 2.26 and it will not build with 2.24. It will also crash if
a version built against 2.26 is forced to run against 2.24 due to
unresolvable symbols.

http://developer.gnome.org/glib/2.26/api-index-2-24.html

If, however, it's doing clever stuff with g_try_malloc and GVariant but
not using GDateTime, then it would probably build against 2.24.

There will be a line in configure.ac | configure.in which specifies
2.26 and you can just try that with a change to 2.24 and running
autoreconf -fs. If autoreconf fails, then complain loudly to upstream
that their upstream build system is insufficiently robust - then make
the same change somewhere in the ./configure script itself. Bear in
mind that the macros in configure.ac | configure.in may cause the
version to be specified in multiple places.

If it builds with 2.24 then it will run with 2.24 and a bug report for
upstream would be warranted to change configure.ac | configure.in.

Build environment version limitations only affect the binary packages,
not the source code. So dh_shlibdeps will generate a dependency on
libglib2.0-0 >= 2.26 in the final .deb but what matters here is whether
the ./configure script will work with libglib2.0-dev >= 2.24 when
generating the Makefiles. If that works, then dh_shlibdeps will
calculate based on what was used in the build environment and generate
a dependency in the final .deb for libglib2.0-0 >= 2.24

It's very important to understand that glib-2.0 has versioned symbols:

/var/lib/dpkg/info/libglib2.0-0:amd64.symbols

Therefore, if the package *could* build with 2.24, dh_shlibdeps would
already have downgraded the upstream specification of 2.26 to 2.24,
whatever version of libglib2.0-dev was actually used to build the
package - unless overridden in debian/control Build-Depends.

So, no, in the case of the increasingly common number of libraries
which use properly versioned symbols, the build environment does not
impact the final version specification *at all*. This is deliberately
implemented in the Debian packaging rules. dh_shlibdeps will generate a
dependency on the lowest version available based on the symbols in use
in that particular build using the data from the symbols file as a
lookup table of all prior releases within that SONAME.

This can be forced by specifying a version in the Build-Depends of the
debian/control file but that is a simple test - just remove the version
specifier in a wheezy build and see what version dh_shlibdeps comes out
with. If that is 2.26 then upstream are correct - that version relies
upon symbols which are only available in libglib2.0-0 >= 2.26 and
changing that means patching the source code to remove the use of those
functions and reimplementing the functionality in some other way.

-- 
Neil Williams <linux@xxxxxxxxxxxxxx>

Attachment: pgp0ANlqJFRW1.pgp
Description: PGP signature

-- 
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/listfaq