[Pan-users] Re: Error compiling under Ubuntu 8.04

[Duncan]

David Shochat <address@hidden> posted
address@hidden, excerpted below, on  Sat, 26 Apr 2008
17:44:02 -0400:

> I have a suspicion that this has already come up (was it that long
> thread about glib includes?), but here's the error I'm getting:
> 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
> 
> I see in my-tree.cc:
> #include <glib/gmessages.h> // for g_assert But poking around, it looks
> like g_assert is actually defined not in gmessages.h, but in
> gtestutils.h. Making that substitution fixed it.
> 
> Ok, it looks like Duncan at least ran into this:
> http://lists.gnu.org/archive/html/pan-users/2008-03/msg00041.html (and
> many others)
> How do I figure out what glib version I have? Going by package listing,
> it looks like maybe I have 2.16.3.

2.16.3 is AFAIK the newest glib, yes, so that's likely what you have on a 
brand new distribution version.  And yes, your problem is indeed glib 
2.16 related.

I posted it on that thread but for convenience and in case you missed it, 
here's the bug with the updated patch.  It should take care of the 
problem.  Note that you may well need the gcc 4.3 patch as well if the 
shipped gcc is equally up to date.  (Wow, they SURE make it hard to 
figure out what version of GCC it ships with.  They talk about this and 
that and the other thing, but seem to be ashamed, for some reason, of 
actual version numbers on stuff that matters to folks already in the 
Linux community, like gcc, xorg, etc.  Most announcements at least have a 
link to a list of apps and their versions.  I couldn't even find that in 
their publicity, tho the beta as announced on LWN is said to carry gcc 
4.2.3, not quite so new after all, if they didn't update from that.)

glib 2.16 bug with patch (use the 2008-04-08 patch)
http://bugzilla.gnome.org/show_bug.cgi?id=524620

gcc 4.3 bug with patch
http://bugzilla.gnome.org/show_bug.cgi?id=524625

> Another issue I've noticed since upgrading to "hardy heron" is that
> quitting from pan sometimes takes a long time (20 seconds or so). This
> is independent of whether I use the version I compiled myself or the one
> supplied by with Ubuntu (which is also 0.132).

I've not the foggiest on that one.  Of course, with a dual-dual-core 
Opteron 290 (2.8 GHz) system, 8 gigs memory, and 4-way kernel/md RAID-6 
main system storage, it's quite likely I'd NOT notice such a slowdown... 
unless it was MAJOR.

Does it happen if you switch groups, wait say 20-30 seconds without 
downloading or marking read, and /then/ quit pan?  Switching groups 
causes pan to save the state on the group you are leaving, same as it 
would when you quit if it had unsaved group state at quit (tho a quit 
saves a few other things as well, accel mapping at least), so switching 
groups first, then quitting pan without doing anything to generate any 
group state changes in the new group, should allow you to figure out 
whether it's the group state save or the actual quit that's taking the 
time.  

If you had been in the same group for some time before quit and had a lot 
of unsaved state to save, particularly if your memory is low enough some 
of it may have to be paged back in from swap in ordered to save, then I 
can see it taking some time, sure.  I dislike the possibility of a pan or 
system crash causing pan to forget where I was in a group -- it was 
happening pretty regularly at one point when I was running then still new 
and unstable xorg and KDE composite support, X and therefore pan would 
crash at of course less than the most convenient times =8^( -- so I've 
developed the habit of quickly changing out and back into a group 
periodically, if I'm doing a lot of work in it, and of always switching 
groups immediately before I leave pan for awhile, so here, pan very 
rarely has any group state info to update at quit.  If that's what's 
slowing you down, that's another reason I'm not seeing it here.

Particularly if it started happening exactly when you updated, especially 
if you run the distribution kernel (as opposed to building it yourself 
from kernel.org sources or the like) so it would have updated at the same 
time, double-check your hard drive drivers as well.  Use 
hdparm -I /dev/<device> (this will work for both old hd/IDE devices and 
new SATA/sd devices, not sure about true SCSI if you have that) to get 
information about current settings directly off the device.  Verify that 
DMA is active.

What I'm thinking here is that with the upgrade, particularly if you 
changed kernel with it as you would if you use distribution supplied 
kernels, it may have changed the drivers you are using from the chipset 
specific ones, which normally automatically enable DMA, to the the 
generic ones, which won't.  With DMA off your disk access will be much 
slower than normal, and disk access is already slow, so you don't need it 
even slower.  If that's the case, I'd suggest you seek help in your 
distribution forums and/or file a bug, to get the right driver running 
and dma enabled once again.  

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman