[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <392256369.112046.1575966868218.JavaMail.zimbra@nod.at>
Date: Tue, 10 Dec 2019 09:34:28 +0100 (CET)
From: Richard Weinberger <richard@....at>
To: anton ivanov <anton.ivanov@...bridgegreys.com>
Cc: Brendan Higgins <brendanhiggins@...gle.com>,
Johannes Berg <johannes.berg@...el.com>,
Jeff Dike <jdike@...toit.com>,
linux-um <linux-um@...ts.infradead.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
davidgow <davidgow@...gle.com>
Subject: Re: [PATCH v1] uml: remove support for CONFIG_STATIC_LINK
----- Ursprüngliche Mail -----
> Von: "anton ivanov" <anton.ivanov@...bridgegreys.com>
>> LIBC itself tries to dynamic load stuff internally.
>>
>> It is beyond our control and it claims that it will work only on EXACTLY
>> the same version of libc library as the one used for static link.
>>
>> So you get a not-exactly static binary which is not properly moveable
>> between systems.
>>
>> This is specifically in the name resolution, etc parts of libc which all
>> of: pcap, vector, vde, etc rely on.
>>
>> Another alternative is to turn off static specifically for those.
>>
>> 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.
glibc tries to load NSS and NIS stuff, yes. But what is the problem?
The goal of CONFIG_STATIC_LINK is that you can run UML without dependencies,
this used to work since ever. Lately it broke, but hey, let's fix it.
I have tons of old statically linked UML systems on my disk which I can
just run because they don't depend on specific libs.
Thanks,
//richard
Powered by blists - more mailing lists