Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Oct 1995 12:46:00 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        peter@haywire.dialix.com (Peter Wemm)
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: Netscape puzzle
Message-ID:  <199510251946.MAA19300@phaeton.artisoft.com>
In-Reply-To: <46l1tu$km$1@haywire.DIALix.COM> from "Peter Wemm" at Oct 25, 95 06:01:34 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> >> > We are all aware of the bind/sendmail static data initialization shared
> >> > library changes, right?
> >> 
> >> Refreh my memory.
> 
> >They changed the initializations to something that would allow copy on
> >write shared library data to be used as well.
> 
> >Basically, it's getting rid of local data for crappy shared library
> >implementations.
> 
> Uhh... Am I missing something?  This thread is about netscape, yes?
> Netscape is linked *static*, and has it's own self-contained resolver.
> Shared libraries dont even come into the picture, because BSDI (1.1)
> doesn't *have* them...

Yeah.  You're missing that it introduced a general bind incompatability
that you must code around to make it work, and perhaps the NetScape
people didn't code around it.

You can hack it by modifying the default contents for the statically
initialized data (basically, blowing instructions in the binary), or
by hacking the bind check call.

> Our implementation of the resolver is not an issue with netscape,
> because our resolver is not loaded into netscape.  Sendmail had the
> problem, yes.

The implementation of the resolver to which the NetScape binary is
statically linked is the issue.

> If you mean the RES_INIT and res_init() patch, that's already in
> sendmail, but isn't a 'netscape puzzle' issue...  From memory
> somebody's already mentioned that there is an issue of the resolver
> code inside the statically linked netscape/bsdi executable using
> select for a timeout, while netscape is using setitimer which is
> disturbing the method that the resolver is using to detect a timeout
> on the select. (or something like that.. :-)

I mentioned it -- the system call restart issue on the select is
only one possibility.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510251946.MAA19300>