On Fri, 15 May 2009 16:24:03 +0200 Francesco Namuri <france...@namuri.it> wrote:
> Hi,
> I'm trying to solve bug #523713, it regards pmidi package, the problem
> is that the build depends on glib 1.2 that is going to be removed from
> unstable. I've seen that the program compiles fine with glib 2.0, but
> the configure look only to 1.2 version using the glib-config tool.
>
> Now, I've managed to solve this problem changing these lines in
> config.in
? config.in ? That doesn't sound like a standard autotools file. The
source package contains configure.in - I'm assuming you mean that.
Once configure.in is modified, the configure script needs to be
regenerated. That can cause problems with packages that haven't had an
upstream release in a while.
This is a rather worrying snippet:
dnl If using the system's GLIB library, setup
dnl will exclude the included GLIB
included copy of GLIB 1.2 ???
I know it's only a single small file but still, is there an upstream
for pmidi?
> from:
>
> if test "$included_glib" = "auto" || test "$included_glib" =
> "no"; then AC_PATH_PROG(GLIBCNF, glib-config, true, $PATH)
> CFLAGS="$CFLAGS `$GLIBCNF --cflags`"
> LIBS="$LIBS `$GLIBCNF --libs`"
> WITH_INCLUDED_GLIB=0
> AC_SUBST(GLIBCNF)
> fi
>
> to something like:
>
> if test "$included_glib" = "auto" || test "$included_glib" =
> "no"; then AC_PATH_PROG(GLIBCNF, glib-config, true, $PATH)
The AC_PATH_PROG test will fail as glib-config no longer exists. Why
still test for it? You need to test for where GLIBCNF is used later on
in the package - if it is *off* (as it would be with only glib-2.0)
this could end up causing the data from pkg-config being ignored.
It looks like it will be OK though. objdump -p certainly shows a link
against glib-2.0
Also, most packages look up the path to pkg-config and use that
variable. It is a more portable method.
> CFLAGS="$CFLAGS `pkg-config --cflags glib-2.0`"
> LIBS="$LIBS `pkg-config --libs glib-2.0`"
That overrides those variables. More common practice is to append but
if the package uses no others, it should be OK.
> WITH_INCLUDED_GLIB=0
> AC_SUBST(GLIBCNF)
> fi
>
>
> Is it a good solution, or it's a bad workaround?
It's probably only a partial solution. You'll need to be sure that
other things haven't changed as a result and you'll need to see what
other effects re-running the autotools may cause. (autoreconf -f).
You'll almost certainly have a bloated .diff.gz.
What patch system are you proposing to use to implement this change to
configure.in ?
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
pgplTaN5JjX4f.pgp
Description: PGP signature
