[uClibc]libresolv and freeswan: Can't compile

[Brian Stafford]

On Mon,  3 December 16:59 arne @ loopback . org wrote:
> On Mon, Dec 03, 2001 at 02:47:43PM +0000, Brian Stafford wrote:
> 
> > Just a thought - why not get the source for bind 8 or 9 and build the
> resolver
> > libraries from that?  Bind 9 also includes the lightweight resolver package
> 
> > which is an advanced stub resolver, this might be more appropriate for the
> > uClibc audience.
> >
> > If nothing else, it might be a better starting point than the glibc code.
> 
> It seems like a good starting point. Just got the source from bind 9.2 went
> to the lib/bind/resolv Dir (which seems to be the one you mention) and tried
> to compile it with the uClib/gcc-wrapper, and it works. (i can compile it).
> 
> But my main problem will how to integrate this into uCLibc, as i looked a
> bit deeper around i can truly say that this is much more than i can handle
> with my limited C experience (not that i would like to) :(.
> I might play around with it, but to make it a real patch for uClib , that is
> out of my range (at least for now)...
> 
> I do not have a clear starting point nor a real direction how to make this.

I didn't really mean that it should be integrated into uClibc, rather as an 
alternative.  When compiling, supply the argument -I /path/to/bind/include and 
when linking -L /path/to/bind/lib and -lbind (or whatever).  That way the 
compiler will use the netdb.h from bind and the linker will find the bind 
libraries before the equivalents from uClibc.  No need to hack up uClibc.  
Even if/when uClibc has full native support for the functions in bind, it may 
not be desirable to use them.

For example, uClibc is aimed at producing small binaries, so it might never 
make sense for it to support anything more than a stub resolver (i.e. one 
which *always* consults the DNS server), whereas the bind library provides the 
full suite of functionality.  However in both cases, the include files and 
functions will have the same names.  This is why compilers and linkers search 
for headers and libraries as they do.

--
Brian Stafford