[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: APT -- Hurd Building



On Fri, 5 Nov 1999, Brent Fulgham wrote:

> Apt compiles quite well on Hurd.  The problem is that the
> resulting executable does not work under http/ftp access.

Heh, cute then. Sounds like someone needs to fix the IP stack, I don't use
that many oddball things - everything APT uses is described in the
Steven's Networking book.
 
> The problems I have encountered to date center around the
> socket logic used in the "connect" module of apt.  The Hurd
> does not (yet) properly support the various socket option
> arguments (getsockopt).  So I have attempted to work around

The (only) getsockopt I do is critical to support non-blocking connect. If
you remove it or disable it you will basically have an extremely broken
implementation.

> This seems to work (or at least the code passes this point)
> but it still doesn't quite complete the connection -- it
> times out with error.  I have inserted a bunch of printf's
> in the code so I can watch what's happening, but it would

Strace is very (-very-) handy for this, but I suppose you don't have that
on hurd?

> be (probably) more useful to use Apt's own internal debug
> code since I'm sure these same issues were dealt with in
> the initial implementation of Apt.

APT debug code focuses almost exclusively on algorithmic issues, the
socket stuff is 'well understood' and is expected to work correctly, thus
it has no debug stuff.

If you really get desperate you could replace the connect function with an
ordinary blocking connect call and just punt the timeout support - that
should work on hurd fine.

Jason


Reply to: