[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49B965C9.5090209@weinigel.se>
Date: Thu, 12 Mar 2009 20:43:05 +0100
From: Christer Weinigel <christer@...nigel.se>
To: Jamie Lokier <jamie@...reable.org>
CC: Neil Horman <nhorman@...driver.com>,
David Miller <davem@...emloft.net>, shemminger@...tta.com,
s.hauer@...gutronix.de, yanok@...raft.com,
linux-arm-kernel@...ts.arm.linux.org.uk, netdev@...r.kernel.org,
wd@...x.de, dzu@...x.de
Subject: Re: [PATCH] dnet: Dave DNET ethernet controller driver
Jamie Lokier wrote:
> In other words, glibc doesn't work on some embedded targets even if
> you have plenty of room: they don't support dynamic libs.
It might be possible to build glibc to always use hosts+DNS for name
lookup, but since I almost always use uclibc on embedded systems I
haven't really tried to do it. If I use glibc, it's on a NFS root and
those systems are large enough anyway.
>> uclibc also seems to have issues with networking and statically linked
>> binaries, but I just haven't had time to figure out why yet.
>
> I've never had an issue with uclibc and networking.
I'm not sure what is happening, but a statically linked uclibc binary
that does TCP networking will work happily with one userspace but not
another. It would seem to me that a statically linked binary should
only depend on the kernel ABI and not on anything userspace (except the
text files in /etc like resolv.conf), but that does not seem to match
reality. If I use Unix sockets instead it works fine, so belive it is
something related to TCP. But well, this is all very fuzzy because I
haven't had time to look more closely at it yet.
/Christer
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists