Christian Biere said:
> Alex Bennee wrote:
>> I was getting core-dumps in both Gtk1 and 2 versions on startup. The
>> back trace looked odd and I couldn't catch it until I noticed this
>> warning from gcc:
>> <snip>
> Well, I never got this warning and I think we can agree that the code
> worked fine for quite a while with this bug in place. I assume you are
> using GCC 3.4? Or which compiler gave you this warning?

Agreed, this is why I was so confused.

[EMAIL PROTECTED] src]$ cc --version
cc (GCC) 3.4.1 (Mandrakelinux (Cooker) 3.4.1-0.3mdk)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

My machine it work is running a stable Mandrake 10.0 and gcc 3.3.2 and
compiles/runs the CVS tree with no problems.
>> So I did this:
>> -       G_LIST_FOREACH(list_nodes, (GFunc) update_row, &now);
>> +    g_list_foreach(list_nodes, (GFunc) update_row, &now);
>
> Yes, this should work but I want to keep using a macro instead and
> fixed the macro definition therefore. Could you please confirm that the
> attached patch fixes the problem as well?

I'll give it a spin when I get home and let you know.

>> Reviewing the compile logs I see this error
>> is all over the place. Has something gone strange with my build setup
>> or have the warnings just got lost in the forest of output that is a
>> compile these days?
>
> I don't quite see what you refer to with forest. If you use the
> compiler flags as in the example above I don't quite see why you would
> get *any* warnings at all

Sorry, I mean it missed it when compiling from scratch as 147 files
generates a lot of output and the final link had scrolled the warnings of
the top of my screen.
I wonder if there is an easy way of summerising the number of warnings in
the build at the end?
> <snip>
> If people don't report (important) compiler warnings, we cannot fix the
> underlying problem. I would assume we are not aware of the problems
> resp. warning if there are any. BTW, I think your report fixes the
> latest bug report, so thanks a lot. I wouldn't have found the problem
> until I have GCC 3.4 installed although it must have been somewhere
> there. Nonetheless, I'm not exactly sure why this construct worked
> before and fails to work now. IIRC, it even worked with other compilers
> than GCC

Well I've not had any crashes on my work machine (although I don't run it
that often here) all I can assume is gcc 3.4 generates subtly different
code than previously. Generally I don't see any core dumps from gtkg which
is why I investigated it when I tried to update last night.
FYI my current diff also has this:

===================================================================
RCS file: /cvsroot/gtk-gnutella/gtk-gnutella-current/src/hcache.h,v
retrieving revision 1.6
diff -u -b -r1.6 hcache.h
--- hcache.h    8 Jun 2004 10:32:56 -0000       1.6
+++ hcache.h    15 Jun 2004 16:30:59 -0000
@@ -60,7 +60,8 @@

 gboolean hcache_node_is_bad(guint32 ip);

-void hcache_clear(host_type_t type);
+//void hcache_clear(host_type_t type);
+void hcache_clear(hcache_type_t type);
 void hcache_prune(hcache_type_t type) ;

As it wasn't building. But I wasn't sure if that was just a problem with
anoncvs being behind the actual tree.
Cheers,

-- 
Alex
http://www.bennee.com/~alex/




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Gtk-gnutella-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

Reply via email to