Re: [RFC v1 2/2] uml: remove support for CONFIG_STATIC_LINK

[Brendan Higgins]

On Thu, Dec 5, 2019 at 11:41 PM Anton Ivanov
<anton.ivanov@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx>
[...]
> 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.