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
