Summary: | net-nntp/pan-0.132-r1 fails to compile | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Lindsay Haisley <fmouse-gentoo> |
Component: | Current packages | Assignee: | Gentoo Net-news project <net-news> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | 1i5t5.duncan, bjt23, chris, gnome, jrmalaq |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
URL: | http://bugzilla.gnome.org/show_bug.cgi?id=524620 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 213352 | ||
Attachments: | Patch to my-tree.cc to locate g_assert definition |
Description
Lindsay Haisley
2008-03-23 21:52:05 UTC
I suspect this is a problem due to glib-2.16, could you confirm this is the version you have installed ? Created attachment 147070 [details, diff]
Patch to my-tree.cc to locate g_assert definition
This looks like pan isn't up with glib. I'm runnning glib-2.16.1. As of glib-2.14.6, which was current on another box I updated last week, this would have worked. The #define for g_assert has been apparently been moved from gmessages.h to gtestutils.h. What else might this break?
I've uploaded a patch which addresses this.
(In reply to comment #1) > I suspect this is a problem due to glib-2.16, could you confirm this is the > version you have installed ? > Yep. Confirmed. See Comment #2 Actually, I note that I have glib in /etc/portage/package.keywords on the affected box. This was done some time ago in response to some other problem that was solved by tracking the unstable version of glib. Were this not the case this wouldn't have happened. The patch I posted removes the reference to glib/gmessages.h and replaces it with a reference to gtestutils.h, but the situation is obviously more complicated than this since the latter file doesn't exist in glib-2.14 and #including glib/gtestutils.h in the source for pan will likewise error out. I created a similar patch, but found another reference as well. Maybe it's stale and unneeded now? (Or maybe it has been added since 0.132, since I'm using svn.) Anyway, might be worth looking into, here's the extra chunk as I have it here. As with the above attachment, it'll need either ifdefs or a conditional application in the ebuild, depending on which version of glib it's building against. The upstream/pan bug, BTW, is http://bugzilla.gnome.org/show_bug.cgi?id=524620 -- pan/data-impl/my-tree.cc.214 +++ pan/data-impl/my-tree.cc @@ -19,7 +19,7 @@ #include <config.h> #include <cassert> -#include <glib/gmessages.h> // for g_assert +#include <glib/gtestutils.h> // for g_assert #include <pan/general/debug.h> #include <pan/general/foreach.h> #include <pan/general/quark.h> (In reply to comment #5) > -- pan/data-impl/my-tree.cc.214 > +++ pan/data-impl/my-tree.cc > @@ -19,7 +19,7 @@ > > #include <config.h> > #include <cassert> > -#include <glib/gmessages.h> // for g_assert > +#include <glib/gtestutils.h> // for g_assert > #include <pan/general/debug.h> > #include <pan/general/foreach.h> > #include <pan/general/quark.h> Duncan, is this patch sufficient to cover the case of both the old and new glib? Won't the make error out with "error: gtestutils.h: No such file or directory" in case the older glib is present? Any fix to pan must take both situations into account and not depend solely on the (currently unstable) glib-2.16.1. This is the solution I came up with, too, but only for Gentoo on my personal desktop for which it's a single point solution. (In reply to comment #6) > Duncan, is this patch sufficient to cover the case of both the old and new > glib? Won't the make error out with "error: gtestutils.h: No such file or > directory" in case the older glib is present? Any fix to pan must take both > situations into account and not depend solely on the (currently unstable) > glib-2.16.1. You are correct. This isn't sufficient as a general solution. That's why I said it'd need ifdefs or conditionally applied in the ebuild. It's simple enough to use eutils to test for the glib version, but that's a gentoo-only solution. If someone who knows what they are doing can create the proper #IFDEFs as I'm hoping, it should be cleanly applicable upstream without creating problems for anyone. There's gotta be a simple way to ifdef based on glib version. I just don't know enough about it to know what it is. (Grr!! I keep trying to put either gcc, because most of the bugs I'm working with ATM are gcc-4.3 patches and in fact there's one of those for pan too, or glibc! Hope I didn't miss any mentions of them in the above, it's glib!) What excuse does pan have to not #include <glib/glib.h> as is expected? (In reply to comment #8) > What excuse does pan have to not #include <glib/glib.h> as is expected? There's another patch that does just that, but the problem is that while it works on 2.14 and 2.16, it doesn't work (according to reports) on 2.12 and previous. Since pan has until now been backward compatible all the way to glib 2.4 (according to the Gentoo depends, and I know it's something like that), we/upstream (I'm including myself as a regular on the pan lists, and one of several actively working on this ATM) are trying to maintain that if possible. The current working solution (proposed by Dan Rahn, OpenSuSE), still buggy as it's not working here, we're trying to trace why, is to replace all the various glib component references in various pan source files with references to a single new pan file, glib-compat.h, which would then handle all the compatibility voodoo in one place. As presently written, it unconditionally includes glib.h (thereby answering your question), but then also conditionally includes other files as necessary based on glib version tests. Since all the compatibility voodoo is consolidated in one place, it should tremendously simplify any further adjustments, should they ever be needed. (Likely, given that at least between 2.12, 2.14, and now 2.16, the API has changed three times, with now single non-conditional solution compatible with all three.) It's not working yet here, so I've not posted it yet. Meanwhile, the unconditional patch above (or just substituting glib.h, either one), works for those desperate to have a compilable against 2.16 version. Duncan I ran into this problem too -- the patch over on gnome bugzilla (http://bugzilla.gnome.org/attachment.cgi?id=108842) works well for me here. (In reply to comment #10) > I ran into this problem too -- the patch over on gnome bugzilla > (http://bugzilla.gnome.org/attachment.cgi?id=108842) works well for me here. Thanks. It's tested working here as well. I helped test it during development, as you can see by the signed-off-by, but just hadn't gotten around to posting a followup here yet. That patch should work without further trouble back all the way thru glib 2.6 at least, and likely further back only nobody has tested back before 2.6. It's probably what'll go into upstream, when Charles gets around to putting out another tarball release, which would be 0.133 as it's tested with live SVN as well. Duncan applied in -r2. |