Re: [PATCH v1] uml: remove support for CONFIG_STATIC_LINK

From: Anton Ivanov
Date: Tue Dec 10 2019 - 02:21:04 EST

On 09/12/2019 23:15, Richard Weinberger wrote:
----- UrsprÃngliche Mail -----
Von: "Brendan Higgins" <brendanhiggins@xxxxxxxxxx>
An: "Jeff Dike" <jdike@xxxxxxxxxxx>, "richard" <richard@xxxxxx>, "anton ivanov" <anton.ivanov@xxxxxxxxxxxxxxxxxx>
CC: "Johannes Berg" <johannes.berg@xxxxxxxxx>, "linux-um" <linux-um@xxxxxxxxxxxxxxxxxxx>, "linux-kernel"
<linux-kernel@xxxxxxxxxxxxxxx>, davidgow@xxxxxxxxxx, "Brendan Higgins" <brendanhiggins@xxxxxxxxxx>
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

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].

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.


linux-um mailing list

Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661