Sorry in advance for this being so long, but I'm covering a lot of info and
hoping for at least some feedback about whether it's useful in the slightest.
I had been running 0.93.3 for over a year because it was not only rock-solid
stable for me, but also because I hadn't managed to ever make the necessary
tweaks to either 0.93.4 or 0.94 to get them to build, run, and be stable for
me. Note that I'm on an uncommon platform (Solaris on Sparc, using Sun's
Forte compiler, and I build 64-bit code whenever possible), so I always
presume that any issues I run into are a result of that environment before I
blame the code in the slightest. 0.93.3 built in that environment with only a
small handful of changes, and resulted in a perfectly functional app that I
would have kept using, if not for the perpetual nagging that I was running an
"ancient" version. :-P
So I grabbed a copy of 0.95 last night and got started. I was pleased to find
out that (like 0.93.3, and unlike 0.94) I only needed to make a small handful
of adjustments to get a good build that would start and run. I'll start with
those.
First, I had to get and install gnu make. Sun's make just didn't want to deal
with the provided Makefiles. This is just an excuse for me to grumble, it's
not a huge deal. I find it frustrating to have to keep both "Sun foo" and
"gnu foo" around on my machine for any arbitrary "foo", but I won't dwell on
it.
Second, I had to manually edit the config.sh to undef all the
'sendfile'-related stuff. Sun's sendfile is rather b0rken, and I know that,
so I knew I'd have to do this. The only follow-up here is that it might be
nice to have a manual override in the configure that would let me turn
sendfile usage off without manual editing. But I won't dwell on this either,
since it's something I'm always well aware of going into a new build.
With the build finally getting underway, I needed to make just 5 small
adjustments to source files to make my compiler happy.
In src/main.c, line 516, there's a call to "raise(SIGTRAP)". For some reason,
while compiling src/core/downloads.c, I get a compile-time warning at line
6261 about "implicit function declaration: raise" and "undefined symbol:
SIGTRAP". Since SIGTRAP only appears at that one location in main.c, it looks
like there's a connection to the main.c file there somehow, but without the
proper declarations of raise and SIGTRAP being available. Anyway, I was able
to get past this and move on by adding:
#include "signal.h"
at line 33 of downloads.c. I'm not sure why this back-reference/connection
occurs, or why the additional include is required. As always, I assume it's
an issue specific to my environment, and it doesn't seem to have created any
problems.
In src/core/gwcache.c, on line 297, my compiler insists that 'left operand
must be modifiable lvalue: op "="'. I was therefore forced to change line 297
to:
file_path_t fpvec[] = {
(losing the "const") to eliminate this complaint and move forward. This also
doesn't seem to have had any ill effects.
In src/core/tx.c, at line 198, there's a return called from within a void
function. My compiler nixed that idea completely, so I had to lose the
return:
TX_FLUSH(tx);
Just like before, there doesn't seem to be a problem with the change here.
In src/ui/gtk/gtk2/interface-glade.c, line 12672 makes a call to
gtk_alignment_set_padding(). This is a new function in GTK 2.4.x, and I still
have 2.2.x installed. I simply commented this line out. I probably messed up
some UI visual somewhere by doing this, but I chose function over form for
now. :) I'll get around to GTK 2.4.x one of these days....
Finally, in src/lib/misc.c, at line 722, my compiler seems to have issues with
the ': (g_assert_not_reached(), -1)' construct, reporting a "syntax error:
empty declaration" at the "if". Now, I've looked at this nested if, and it
makes perfect sense to me. I'm not sure what it is about how this particular
one is set up, but my compiler just refuses to deal with it. For the time
being, I just changed the last line to return a NULL in place of the
"(g_assert_not_reached(), -1)". Yes, I acknowledge that this will probably
cause something to blow up eventually. I was in a hurry. I plan to re-write
this whole function with actual if(){} syntax and see if my compiler is any
happier about it that way. Meanwhile, the NULL will only be returned if bad
info is fed in, which is wrong and would have caused an assert in the first
place, so I'm not too worried about it.
With all that out of the way, the build finished, and I had a runnable 64-bit
binary. Generally, when I build a new 64-bit binary, I expect at least one or
two bus errors or segfaults initially because of overlooked 32-/64- bit
mixups. I'm happy to report that my 64-bit binary fired up, connected to the
network and began operating exactly as expected. It ran all night, and was
still connected to the network and harvesting files in the morning, making
this the single-most successful initial run I've ever had with a 64-bit GTKG.
Woohoo!
The last little problem cropped up when I closed GTKG down. It left a core
due to a segfault during the shutdown procedure. A backtrace on the core puts
the failure inside the zdestroy() function, when it's called from inside
wdestroy(). I've added some debug output to zdestroy() and re-built. I'll
see if I can get the problem to happen again, and find a solution. This is
mostly because I don't like reporting a problem without having a suggested fix
to go with it.
With all that said, I'll reiterate that this was the most stable
first-run-right-after-build I've had. I expect this version will ultimately
prove to be as stable for me as 0.93.3 was - at least as soon as I work out
the kink in the zdestroy().
What I was hoping for was some feedback/critique of the small tweaks I made in
getting it up and going. Any observations about whether these were
good/bad/smart/stupid changes I made, whether they should/shouldn't be
necessary, and so on. I hesitate to classify any of them as "bugfixes",
considering them "adjustments" peculiar to my setup instead. I'd be most
interested in hearing assurances that I haven't *caused* any problems with
these changes bigger than the ones I eliminated. And if any of these changes
do need to be officially classified as bugfixes, I'd be happy to write them up
and submit them to the bugtracker.
I can't say it enough: Thanks to everyone that's worked on GTKG for all your
effort - I use it quite a bit, and it's been one of several great tools that
together keep me from having to keep a legacy Windows machine around. I
appreciate that - a lot!
Cheers,
The Blue Meanie
([EMAIL PROTECTED])
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Gtk-gnutella-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
