Messages in this thread | | | Subject | Re: [PATCH v1] uml: remove support for CONFIG_STATIC_LINK | From | Anton Ivanov <> | Date | Tue, 10 Dec 2019 07:34:35 +0000 |
| |
On 10/12/2019 07:20, Anton Ivanov wrote: > On 09/12/2019 23:15, Richard Weinberger wrote: >> ----- Ursprüngliche Mail ----- >>> Von: "Brendan Higgins" <brendanhiggins@google.com> >>> An: "Jeff Dike" <jdike@addtoit.com>, "richard" <richard@nod.at>, >>> "anton ivanov" <anton.ivanov@cambridgegreys.com> >>> CC: "Johannes Berg" <johannes.berg@intel.com>, "linux-um" >>> <linux-um@lists.infradead.org>, "linux-kernel" >>> <linux-kernel@vger.kernel.org>, davidgow@google.com, "Brendan >>> Higgins" <brendanhiggins@google.com> >>> Gesendet: Dienstag, 10. Dezember 2019 00:02:48 >>> Betreff: [PATCH v1] uml: remove support for CONFIG_STATIC_LINK >> >>> CONFIG_STATIC_LINK appears to have been broken since before v4.20. It >>> doesn't play nice with CONFIG_UML_NET_VECTOR=y: >>> >>> /usr/bin/ld: arch/um/drivers/vector_user.o: in function >>> `user_init_socket_fds': vector_user.c:(.text+0x430): warning: Using >>> 'getaddrinfo' in statically linked applications requires at runtime the >>> shared libraries from the glibc version used for linking >> >> This is nothing serious. >> >>> And it seems to break the ptrace check: >>> >>> Checking that ptrace can change system call numbers...check_ptrace : >>> child exited with exitcode 6, while expecting 0; status 0x67f >>> [1] 126822 abort ./linux mem=256M >> >> Didn't we fix that already? > > Yes we did - I commented on this. > >> >>> (Apparently, a patch was recently discussed that fixes this - around >>> v5.5-rc1[1] - but the fact that this was broken for over a year >>> remains.) >>> >>> According to Anton, PCAP throws even more warnings, and the resulting >>> binary isn't really even static anyway, so there is really no point in >>> keeping this config around[2]. >> >> What? >> Anton, please explain. Why is it not static when build with >> CONFIG_STATIC_LINK? > > > 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.
> >> >> Thanks, >> //richard >> >> _______________________________________________ >> linux-um mailing list >> linux-um@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-um >> > >
-- Anton R. Ivanov Cambridgegreys Limited. Registered in England. Company Number 10273661 https://www.cambridgegreys.com/
| |