Messages in this thread | | | From | Brendan Higgins <> | Date | Fri, 6 Dec 2019 14:49:55 -0800 | Subject | Re: [RFC v1 2/2] uml: remove support for CONFIG_STATIC_LINK |
| |
On Thu, Dec 5, 2019 at 11:41 PM Anton Ivanov <anton.ivanov@cambridgegreys.com> wrote: > > On 06/12/2019 02:01, Brendan Higgins wrote: > > 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 > > > > 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 > > > > Given the importance of ptrace in UML, CONFIG_STATIC_LINK seems totally > > broken right now; remove it in order to fix allyesconfig for ARCH=um. > > > > Signed-off-by: Brendan Higgins <brendanhiggins@google.com> [...] > The ptrace check was discussed on the list this week - it is the enable > constructors commit in 5.3-rc1. > > A patch reverting it was submitted by Johannes yesterday. > > I did not try disabling/enabling static link - good catch. > > Otherwise, I agree - static link should probably go. > > Adding PCAP throws even more warnings and the AF_XDP work I have in > progress generates a whole page of them. Considering that the resulting > executable is not really static there is no point keeping the option.
Sounds good. I will send this out again as a non-RFC patch.
| |