[fossil-users] Should distributed binary require libnss to connect over http?
Remigiusz Modrzejewski
I've hit a surprising obstacle. I've tried to use Fossil, the binary from the website, on a heavily stripped down Linux system. But trying to clone end with:
fl: can't resolve host name: dev.lrem.net
I traced the problem to be lack of libnss_dns.so.2. But as far as I understand, this library is needed only for https, isn't it? This failed while trying to use plain http. Is this expected?
Pozdrawiam,
Remigiusz Modrzejewski
_______________________________________________
fossil-users mailing list
fossil...@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Remigiusz Modrzejewski
On Jan 29, 2012, at 20:36 , Remigiusz Modrzejewski wrote:
> I've hit a surprising obstacle. I've tried to use Fossil, the binary from the website, on a heavily stripped down Linux system. But trying to clone end with:
>
> fl: can't resolve host name: dev.lrem.net
>
> I traced the problem to be lack of libnss_dns.so.2.
Nah, should read more carefully. The trace actually reads like this:
open("/lib/libnss_dns.so.2", O_RDONLY) = 8
read(8, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\20\0\0\0\0\0\0"..., 512) = 512
close(8) = 0
open("/usr/lib/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
munmap(0xf7746000, 8285) = 0
write(2, "\rfl: can't resolve host name: de"..., 43) = 43
No other indication what's wrong in strace. For ltrace, I get:
ltrace: Couldn't find .dynsym or .dynstr in "/usr/bin/fossil"
But I'm already getting too lazy to continue, sunday evening projects are meant to be pure fun ;) I'll pick up from here later this week.
Kind regards,
Dmitry Chestnykh
> > I've hit a surprising obstacle. I've tried to use Fossil, the
> > binary from the website, on a heavily stripped down Linux system.
> > But trying to clone end with:
> >
> > fl: can't resolve host name: dev.lrem.net
> >
> > I traced the problem to be lack of libnss_dns.so.2.
Yeah, static linking is not actually that static nowadays. When linking,
GCC warns about this.
If fossil runs in chroot/stripped system and needs to resolve hosts, you
need to put the related dynamic libraries into chroot/stripped system.
--
Dmitry Chestnykh
http://www.codingrobots.com
Lluís Batlle i Rossell
> On Sun, 29 Jan 2012 20:49:00 +0100 Remigiusz Modrzejewski wrote:
>
> > > I've hit a surprising obstacle. I've tried to use Fossil, the
> > > binary from the website, on a heavily stripped down Linux system.
> > > But trying to clone end with:
> > >
> > > fl: can't resolve host name: dev.lrem.net
> > >
> > > I traced the problem to be lack of libnss_dns.so.2.
>
> Yeah, static linking is not actually that static nowadays. When linking,
> GCC warns about this.
For what I know, it's only *glibc* that suffers from dynamic-only name resolvers
(for either hosts, services, users, ...).
Regards,
Lluís.
Dmitry Chestnykh
> On Mon, Jan 30, 2012 at 04:27:07AM +0100, Dmitry Chestnykh wrote:
> > On Sun, 29 Jan 2012 20:49:00 +0100 Remigiusz Modrzejewski wrote:
> >
> > > > I've hit a surprising obstacle. I've tried to use Fossil, the
> > > > binary from the website, on a heavily stripped down Linux
> > > > system. But trying to clone end with:
> > > >
> > > > fl: can't resolve host name: dev.lrem.net
> > > >
> > > > I traced the problem to be lack of libnss_dns.so.2.
> >
> > Yeah, static linking is not actually that static nowadays. When
> > linking, GCC warns about this.
>
> For what I know, it's only *glibc* that suffers from dynamic-only
> name resolvers (for either hosts, services, users, ...).
You mean, if you replace glibc with some other libc, it will work?
Sure, but then you'll have more problems if you don't control the
deployment [1].
The authors of Go programming language dropped [2] a major feature --
cross-compiling between OSes -- because it was just impossible to
interface with modern OS without the provided libc, despite the fact
that they had already "kind of" working name resolver.
Solaris no longer allows static linking too [3]. I think OS X too.
You can, of course, build your own OS.
[1] http://www.akkadia.org/drepper/no_static_linking.html
[2] http://codereview.appspot.com/4437053
[3] http://blogs.oracle.com/rie/entry/static_linking_where_did_it
--
Dmitry Chestnykh
http://www.codingrobots.com
Lluís Batlle i Rossell
> On Mon, 30 Jan 2012 09:11:03 +0100 Lluís Batlle i Rossell wrote:
> > On Mon, Jan 30, 2012 at 04:27:07AM +0100, Dmitry Chestnykh wrote:
> > > Yeah, static linking is not actually that static nowadays. When
> > > linking, GCC warns about this.
> >
> > For what I know, it's only *glibc* that suffers from dynamic-only
> > name resolvers (for either hosts, services, users, ...).
>
> You mean, if you replace glibc with some other libc, it will work?
> Sure, but then you'll have more problems if you don't control the
> deployment [1].
Right. uclibc static binaries work perfectly, with name resolving in the static
program. That's linux-only though, I think.
Regards,
Lluís.