[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
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