[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAFd5g46aCzJqpcj3mjCy3O7iSfUz3VBaPzivq-CVZ6fJs+Ybug@mail.gmail.com>
Date: Tue, 10 Dec 2019 11:41:14 -0800
From: Brendan Higgins <brendanhiggins@...gle.com>
To: Anton Ivanov <anton.ivanov@...bridgegreys.com>
Cc: Johannes Berg <johannes@...solutions.net>,
Richard Weinberger <richard@....at>,
Jeff Dike <jdike@...toit.com>,
linux-um <linux-um@...ts.infradead.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
David Gow <davidgow@...gle.com>
Subject: Re: [PATCH v1] uml: remove support for CONFIG_STATIC_LINK
On Tue, Dec 10, 2019 at 12:54 AM Anton Ivanov
<anton.ivanov@...bridgegreys.com> wrote:
>
>
>
> On 10/12/2019 08:28, Johannes Berg wrote:
> > On Tue, 2019-12-10 at 07:34 +0000, Anton Ivanov wrote:
> >
> >>> Further to this - any properly written piece of networking code which
> >>> uses the newer functions for name/service resolution will have the same
> >>> problem. You can be static only if you do everything "manually" the old
> >>> way.
> >>
> >> The offending piece of code is the glibc implementation of getaddrinfo().
> >>
> >> If you use it and link static the resulting binary is not really static.
> >
> > However, this (getaddrinfo) really only applies if you use the vector
> > network driver, if you e.g. use only virtio then this particular problem
> > isn't present.
> >
> > Note sure if we implicitly call getaddrinfo from libpcap, but again,
> > that's just a single driver.
> >
> > IOW, we could just make CONFIG_STATIC_LINK depend on !VECTOR && !PCAP?
>
> +1
>
> We also need to add VDE (wonder if anyone still uses that).
>
> We will need to add XDP when I finish it. If memory servces me right,
> libelf or libbpf has the same lovely features as NSS.
>
> This is not just NSS - it is creeping in with a lot of new libraries.
> Sometimes the libc guys fix that. For example, librt was like that when
> I started working on epoll and vector IO.
>
> Sometimes (as in the NSS case) they don't. So the static build
> containing those will be broken and we are better off making it conflict
> for those options.
No strong opinions from me. I am more than happy to submit a new patch
that adds the negative dependencies.
Powered by blists - more mailing lists