gtk-gnutella-devel Digest, Vol 32, Issue 3

[gtk-gnutella-devel-request]

Send gtk-gnutella-devel mailing list submissions to
        gtk-gnutella-devel@...

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
or, via email, send a message with subject or body 'help' to
        gtk-gnutella-devel-request@...

You can reach the person managing the list at
        gtk-gnutella-devel-owner@...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of gtk-gnutella-devel digest..."


Today's Topics:

   1. Re:  Unable to connect (Matthew Lye)
   2. Re:  Unable to connect (Hauke Hachmann)
   3. Re:  Unable to connect (Raphael Manfredi)
   4. Re:  Unable to connect (Raphael Manfredi)
   5.  iconv avec ennui. (Matthew Lye)
   6. Re:  iconv avec ennui. (Raphael Manfredi)
   7. Re:  iconv avec ennui. (Raphael Manfredi)


----------------------------------------------------------------------

Message: 1
Date: Thu, 17 Sep 2009 13:27:31 -0400
From: Matthew Lye <mlye@...>
Subject: Re: [gtk-gnutella-devel] Unable to connect
To: gtk-gnutella-devel@..., Hauke Hachmann
        <haxe@...>
Message-ID: <26FCE636-9096-40AA-B29F-1100DE11A7FE@...>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes


On 17-Sep-09, at 11:23 AM, Hauke Hachmann wrote:

> On Thursday 17 September 2009, Matthew Lye wrote:
>> Which gtkg version are you using?
>
> Ah, sorry, I forgot to mention. At the moment, I am using r16974  
> (which
> is the newest from SVN), but I think that my problems were already
> present at least with r16970, probably even earlier. OTOH, I know that
> it still worked one week ago, so the error cannot be very old.

I'm testing as a leaf and not having the same problem.  Are the  
connections merely timing out?  Does the problem persist after you  
empty your caches?


I can think of two ways that the recent changes could be introducing  
problems.  I was unable to determine whether the older BearShare  
variants which accept connections nonetheless offer "FP-Auth-
Challenge" headers.  If they do, and you have been operating in a  
BearShare island, this might indeed have introduced problems.

Alternately, it seems at a glance that when the number of known hosts  
is low, GTKG should start attempting to connect to servents suggested  
by servents caches as bad or unstable, rather than ask a web cache for  
help.  This might be a problem if the same logic was extended to the  
alien servents, especially those which were Foxy hubs.

I would suggest disconnecting, emptying all your caches, and shutting  
down GTKG as a first step.  Wait a minute or two for any Foxy  
pestering to die down, and then relaunch and see if it will contact  
the web caches for servent addresses.  If it does, you should start  
having connections.  Let me know if that works.





------------------------------

Message: 2
Date: Thu, 17 Sep 2009 19:35:31 +0200
From: Hauke Hachmann <haxe@...>
Subject: Re: [gtk-gnutella-devel] Unable to connect
To: gtk-gnutella-devel@...
Message-ID: <200909171935.31775.haxe@...>
Content-Type: Text/Plain;  charset="iso-8859-1"

On Thursday 17 September 2009, Raphael Manfredi wrote:
> Is gtk-gnutella at least attempting to connect or is it just sitting
>  there, idle?

It constantly tries to connect to lots of hosts. Most of them show the
usual vendor strings (mostly LimeWire, some Frosty). All proceed to the
stage "Hello sent". Some connections end with a 503 (either "we're
leaves" or "no leaf slots"). But the vast majority of connections simply
end with a timeout after the hello phase.

I let gtk-gnutella run for several hours without getting a single
Gnutella connection established. I tried both my usual installation and
a fresh one with a virgin .gtk-gnutella directory.

Needless to say that my other internet activities (http, smtp, pop3,
imap) work perfectly fine, so it's clearly not a lower-level connectivity
problem.

Hauke



------------------------------

Message: 3
Date: Thu, 17 Sep 2009 18:03:49 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Unable to connect
To: gtk-gnutella-devel@...
Message-ID: <h8ttm5$1b9$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Hauke Hachmann <haxe@...> from ml.softs.gtk-gnutella.devel:
:I let gtk-gnutella run for several hours without getting a single
:Gnutella connection established. I tried both my usual installation and
:a fresh one with a virgin .gtk-gnutella directory.

Hmm, that would indeed cause you to bootstrap by contacting host caches.
If these host cache give you back addresses of hosts that you cannot connect
to, then Gnutella may be experiencing a bootstrapping problem as a whole.

The only solution I see at this stage is for you to come to #gtk-gnutella
and ask for a kind soul there to seed you with a known IP:port.

Raphael



------------------------------

Message: 4
Date: Thu, 17 Sep 2009 19:54:53 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Unable to connect
To: gtk-gnutella-devel@...
Message-ID: <h8u46d$gg2$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Raphael_Manfredi@... (Raphael Manfredi):
:Quoting Hauke Hachmann <haxe@...> from ml.softs.gtk-gnutella.devel:
::I let gtk-gnutella run for several hours without getting a single
::Gnutella connection established. I tried both my usual installation and
::a fresh one with a virgin .gtk-gnutella directory.
:
:Hmm, that would indeed cause you to bootstrap by contacting host caches.
:If these host cache give you back addresses of hosts that you cannot connect
:to, then Gnutella may be experiencing a bootstrapping problem as a whole.

No, problem solved.
It was a stupid line inversion when I applied a patch too hastly.

Everything should be fine in r16975.

Raphael



------------------------------

Message: 5
Date: Thu, 24 Sep 2009 13:32:47 -0400
From: Matthew Lye <mlye@...>
Subject: [gtk-gnutella-devel] iconv avec ennui.
To: gtk-gnutella-devel@...
Message-ID: <D359F57D-C149-428C-9295-770CF91E236C@...>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

Hello all,

Since the recent changes in ./src/sdbm, I have been encountering a  
compile-time error originating with ./src/lib/utf8.o 's links to the  
iconv library.  My system is a ppc7450 iMac running OS X 10.5.8, which  
has Darwin 9.8.0.

> cc -o dbu  dbu.o util.o   -O2 -g  -L. -lsdbm -L../lib -lshared -lglib
> collect2: ld terminated with signal 6 [Abort trap]
> Undefined symbols
>   "_libiconv_open", referenced from:
>       _utf8_cd_get in libshared.a(utf8.o)
>       _locale_init in libshared.a(utf8.o)
>       _locale_init in libshared.a(utf8.o)
>       _locale_init in libshared.a(utf8.o)
>       _locale_init in libshared.a(utf8.o)
>       _locale_init in libshared.a(utf8.o)
>   "_libiconv", referenced from:
>       _complete_iconv in libshared.a(utf8.o)
>       _complete_iconv in libshared.a(utf8.o)
>       _complete_iconv in libshared.a(utf8.o)
> terminate called after throwing an instance of 'char const*'
> terminate called recursively
> make[4]: *** [dbu] Error 1
> make[3]: *** [subdirs] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [subdirs] Error 1
> make: *** [all] Error 2

This failure is identical each time, except that the undefined symbols  
will be "_iconv" "_inconv_open" when I try to link to a static version  
of libiconv.  The symbol *is* defined in the relevant library in all  
cases.

I believe that this problem has its roots in the Darwin OS's  
implementation of /usr/lib/libiconv.* and/or /usr/include/iconv.h  
being incompatible with the newer GNU versions, and that it involves  
macros and C++;  there are lots of message board posts reporting iconv  
errors when people try to port projects to Darwin.  I know that I've  
encountered problems with iconv before and that they were solved.  
What I don't recall is exactly who managed to solve it or how it was  
done.  I've been unable to find a solid discussion or solution posted  
anywhere;  it's possible that the situation makes a lot more sense to  
someone who understands C++, which I do not.

Things I have tried:
- eliminating I_ICONV guard.  (I_ICONV is defined, anyways.)
- specifying full pathnames of all libraries
- specifying explicit pathname of iconv.h
- linking specifically to static version of libiconv, both native and  
GNU.
- changing the name of the GNU iconv library and header

Any ideas or suggestions?




------------------------------

Message: 6
Date: Thu, 24 Sep 2009 18:20:09 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] iconv avec ennui.
To: gtk-gnutella-devel@...
Message-ID: <h9gd8p$l4f$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel:
:Since the recent changes in ./src/sdbm, I have been encountering a  
:compile-time error originating with ./src/lib/utf8.o 's links to the  
:iconv library.  My system is a ppc7450 iMac running OS X 10.5.8, which  
:has Darwin 9.8.0.
:
:> cc -o dbu  dbu.o util.o   -O2 -g  -L. -lsdbm -L../lib -lshared -lglib
:> collect2: ld terminated with signal 6 [Abort trap]
:> Undefined symbols
:>   "_libiconv_open", referenced from:
:>       _utf8_cd_get in libshared.a(utf8.o)

The utf8.o file should not be loaded when linking dbu, since none of the
UTF-8 routines are used by dbu nor by sdbm...

:I believe that this problem has its roots in the Darwin OS's  
:implementation of /usr/lib/libiconv.* and/or /usr/include/iconv.h  
:being incompatible with the newer GNU versions, and that it involves  
:macros and C++;  there are lots of message board posts reporting iconv  
:errors when people try to port projects to Darwin.

Again, we're talking about a library here, and the normal linker behaviour
should be to not load a file from the library unless one of the symbols
defined by the file is needed.

I've checked locally the symbols in my linked dbu, and I'm astonished
to see that symbols like cq_cancel() are defined.

:Any ideas or suggestions?

You are pinpointing a lack of granularity in the "shared" library files that
causes too much unnecessary stuff to be loaded due to transitive dependencies.

Fixing this will probably require splitting the "shared" library in more
than one so that we can only the files for the required symbols, which are:

assertion_failure
common_stats
compat_pread
compat_pwrite
fd_close
file_open
h_strconcat
h_strdup
halloc_init
hash_list_free
hash_list_iter_previous
hash_list_iter_release
hash_list_iterator_tail
hash_list_moveto_head
hash_list_new
hash_list_prepend
hash_list_tail
hfree
hrealloc
vmm_alloc
vmm_free
vmm_init
walloc
walloc0
wfree
wrealloc

>From that list, I can almost see where the problem lies: the fact that we
need h_strdup() means that the whole misc.o file needs to be loaded, which
in turn causes many other library files to be required given the diverse
routines defined there.

A first solution is therefore to start moving h_strconcat() and h_strdup()
out of misc.c, and then things should be much more under control.

Raphael



------------------------------

Message: 7
Date: Fri, 25 Sep 2009 15:27:05 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] iconv avec ennui.
To: gtk-gnutella-devel@...
Message-ID: <h9ing9$roa$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel:
:Since the recent changes in ./src/sdbm, I have been encountering a  
:compile-time error originating with ./src/lib/utf8.o 's links to the  
:iconv library.  My system is a ppc7450 iMac running OS X 10.5.8, which  
:has Darwin 9.8.0.

Let me know if things work out with r16991.
I no longer see any utf8 symbols in the linked "dbu" here.

Also I've fixed the linking line to work with glib 2.x.

Raphael



------------------------------

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel


End of gtk-gnutella-devel Digest, Vol 32, Issue 3
*************************************************