Hi Neil, Il giorno ven, 15/05/2009 alle 16.11 +0100, Neil Williams ha scritto: > On Fri, 15 May 2009 16:24:03 +0200 > Francesco Namuri <[email protected]> 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?
the last version of pmidi (1.6.0) has been released in December 2003, after this no more official relases. To solve this problem can I repackage the source removing these two files? > > 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. I've tried and the configure works, the builds fine linking to new glib-2.0. > 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. Yes, the .diff.gz, contais all the autotools regenerated files... > What patch system are you proposing to use to implement this change to > configure.in ? I have not considered this issue, maybe simple path system? But I don't know if another patch system can offer enhancements managing a problem like this one. Thanks for your help, francesco -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
