[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20121231120334.05263f66.idunham@lavabit.com>
Date: Mon, 31 Dec 2012 12:03:34 -0800
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: Re: lshw FTBFS: res_querydomain declared but not implemented
On Mon, 31 Dec 2012 13:06:53 -0500
Rich Felker <dalias@...ifal.cx> wrote:
> On Sun, Dec 30, 2012 at 09:59:31PM -0800, Isaac Dunham wrote:
> > I've been trying to build lshw [1] with musl, and I ran into a few problems:
>
> Have you sent any reports/patches upstream yet?
I figured I'd get it to compile and see how it runs first.
<snip>
> > 3: It wants MAX_PATH from some header that doesn't have it: I added <limits.h>
>
> PATH_MAX is in limits.h. MAXPATHLEN is in sys/param.h (bogus header
> full of random miscellaneous junk). I don't think I've ever heard of
> MAX_PATH...
Sorry, I meant PATH_MAX.
> > 4: It wants res_querydomain.
> > This does not show up until link time, since <resolv.h> declares it.
> > However, musl does not acually implement this function.
>
> And it seems to be completely undocumented how it's supposed to
> work...
Call res_query with name as "name.domain". It's described in the linux-dev manpages.
> > Currently, I've got a very hackish implementation that isn't fit to ship:
> > -it doesn't check for name == "machine."
>
> What is special about "machine."?
That was a bad example; I meant "Doesn't check for a terminal '.'"
> > -it does no error checking, on the assumption that res_query can handle that.
>
> Seems fine.
>
> BTW a full name can never be longer than 256 bytes (including null
> termination), so you can do the concatenation on the stack in a
> fixed-size array. You'll need to generate your own error if the
> combined length would exceed the max.
Ah, thanks.
--
Isaac Dunham <idunham@...abit.com>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
