[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFd5g45_PaL_rSbhrUD1RJ1ZWasptG+z7TO9_B4-Qafs90L2KA@mail.gmail.com>
Date: Fri, 6 Dec 2019 14:49:55 -0800
From: Brendan Higgins <brendanhiggins@...gle.com>
To: Anton Ivanov <anton.ivanov@...bridgegreys.com>
Cc: Jeff Dike <jdike@...toit.com>, Richard Weinberger <richard@....at>,
johannes.berg@...el.com, linux-um@...ts.infradead.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
David Gow <davidgow@...gle.com>
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@...bridgegreys.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@...gle.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.
Powered by blists - more mailing lists