I'm getting the following error when trying to emerge pan: my-tree.cc: In member function 'virtual void pan::DataImpl::MyTree::set_filter(pan::Data::ShowType, const pan::FilterInfo*)': my-tree.cc:99: error: 'g_assert' was not declared in this scope my-tree.cc: In member function 'void pan::DataImpl::MyTree::add_articles(const std::vector<const pan::DataImpl::ArticleNode*, std::allocator<const pan::DataImpl::ArticleNode*> >&)': my-tree.cc:404: error: 'g_assert' was not declared in this scope my-tree.cc:417: error: 'g_assert' was not declared in this scope my-tree.cc:481: error: 'g_assert' was not declared in this scope my-tree.cc:494: error: 'g_assert' was not declared in this scope make[3]: *** [my-tree.o] Error 1 make[3]: *** Waiting for unfinished jobs.... make[3]: Leaving directory `/var/tmp/portage/net-nntp/pan-0.132-r1/work/pan-0.132/pan/data-impl' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/net-nntp/pan-0.132-r1/work/pan-0.132/pan' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/net-nntp/pan-0.132-r1/work/pan-0.132' make: *** [all] Error 2 * * ERROR: net-nntp/pan-0.132-r1 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 2092: Called die This appears to be unrelated to bug #211670 since I'm using gcc i686-pc-linux-gnu-4.1.2. Output from emerge --info follows: Portage 2.1.4.4 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0,glibc-2.3.4.20040808-r1, 2.6.18-gentoo-r6 i686) ================================================================= System uname: 2.6.18-gentoo-r6 i686 Intel(R) Pentium(R) 4 CPU 2.60GHz Timestamp of tree: Sun, 23 Mar 2008 21:00:01 +0000 ccache version 2.4 [disabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r9 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -fprefetch-loop-arrays -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=pentium4 -fprefetch-loop-arrays -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://cudlug.cudenver.edu/gentoo ftp://ftp.ussg.iu.edu/pub/linux/gentoo" LANG="en" LC_ALL="en_US" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X Xaw3d acl acpi alsa apache2 apm arts berkdb bindist bonobo cairo cdr cli cracklib crypt cups curl dbus doc dri dvd dvdr dvdread eds emboss encode esd evo fam fastcgi firefox flash foomaticdb fortran gdbm gif gimp gnome gpm gps gstreamer gtk gtkhtml hal iconv imap ipv6 isdnlog java jikes jpeg kde kerberos ldap mad maildir mcal midi mikmod motif mp3 mpeg mudflap mysql ncurses nls nptl nptlonly ogg oggvorbis opengl openmp oss pam pcre pdf perl plotutils png ppds pppd python qt qt3 qt3support qt4 quicktime readline reflection samba sasl scanner sdl seamonkey session slang slp snmp spell spl sse ssl svg svga tcltk tcpd tetex tiff truetype unicode usb vorbis win32codecs x86 xml xml2 xorg xosd xv zeo zlib" ALSA_CARDS="emu10k1 ice1712" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 i810 imstt mach64 mga neomagic nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
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.
