On Fri, 18 Feb 2005 15:46:00 +0100, Christian Biere <[EMAIL PROTECTED]> wrote: > The Blue Meanie wrote: > > Sun's make just didn't want to deal > > with the provided Makefiles. > > Maybe you could show us the first error messages from make. The Makefiles > don't look as if they require GNU make here. I don't use GNU make to > build it. > Hmmm. Actually, it looks like it may just have an issue with some spurious blank lines. Let me get back to you on this one.
> > 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. > > What do you mean with broken? > Heh. Well, they ship a libsendfile.so, but from what I've seen in the past, not all of the functions in it are even implemented, let alone implemented correctly. I've never had any code that used their sendfile stuff work right, and that's not limited to just GTKG. This may have changed since I last encountered it (perhaps a patch along the way?), so if I get daring, I may try letting sendfile do its stuff. I'm just not hopeful, and it's 110% Sun's fault. > ./Configure -Oders -Ud_sendfile > to undefine the d_sendfile symbol i.e., to override the detection > result. > Excellent. I've filed this one away for future use. :) > > I get a compile-time warning at line > > 6261 about "implicit function declaration: raise" and "undefined symbol: > > SIGTRAP". > > This should be fixed in CVS since signal.h is included in common.h, thus > all such symbols are available from all files. > Ok. Guess I need to look into working from a CVS version soon, huh? > > (losing the "const") > > Thanks, I've removed it now. > > > TX_FLUSH(tx); > > Dito. It's somewhat strange that GCC doesn't emit a warning for that. > I agree. But Sun's Forte has always been pretty picky about stuff. To the point of being a real hassle sometimes. Like I'm constantly bombarded with warnings about the fact that something was declared as a "const char", and was populated with data that's "const unsigned char". Yes, it actually emits warnings for that. At least it doesn't halt. > The current code > should compile fine with GTK+ 2.0 but as I've installed 2.6 I won't > guarantee that. > Fair enough - I really need to get at least 2.4 installed, so maybe this will motivate me. > > 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". > > I've fixed this now. > Ok. Honestly, it really didn't look like this needed to be "fixed". The nested ? : ? : layout made perfect sense, and was nice and compact. I still pin this on Forte being too picky. > > The last little problem cropped up when I closed GTKG down. It left a core > > due to a segfault during the shutdown procedure. > > It's unlikely to be the last problem. The code from CVS has a lot > of bugs fixed. Anyone who compiles from sources anyway should use > CVS at least currently. Very prophetic. My GTKG died while running overnight last night. I'll look into why when I have another chance. Looks like I may need to switch to the CVS version if I'm going to try to be more helpful. > There should have been a bugfix release by > now but there wasn't because nobody's time for that. > Considering the size of the GTKG codebase, the fact that it offers both a GTK1 and GTK2 ui, and the fact that the network itself is evolving the way it is, I can totally believe this. Like so many projects I use, I'd love to contribute more, but as I'm not a coder so much as a troubleshooter/reverse engineer, I'm forced to limit my contributions to tweaks and cleanups like these. My lack of coding skill is also why I tend to fight the urge to report a bug unless I've worked it through and can at least offer a decent suggestion on where and why it happens, and a fix if at all possible. Nothing's more useless than a zillion "foo crashed on me, can you fix it?" reports, right? I do pride myself on being able to spot a 32-/64-bit mismatch from a mile away, at least. Anyway, thanks for the feedback, and I'll try to get moved up to a current CVS version soon. Before I dive into that, is there a requirement for the various gnu auto* components to use CVS? I think I have them installed, but they're probably *hideously* old versions, since I don't do much CVS work. Just trying to get prepared. And since I'm always paranoid about sounding like a whiner, I'll repeat the kudos to all involved. GTKG is a great app, and one of the primary apps I needed to break ties with the Windows world for good (at least at home). I truly appreciate all the effort that's gone into its development and evolution. And I strive to make sure that any "issues" I may report about building/using it are phrased in as constructive a way as possible. 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
