Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5084152ybl; Mon, 9 Dec 2019 23:36:51 -0800 (PST) X-Google-Smtp-Source: APXvYqzgStUImcq0ZDXMj86aariT8TDZci2u9QOGcpT2lnBaATAYP/2PxaVj+oi3KmBbfx9l/j6k X-Received: by 2002:a9d:6745:: with SMTP id w5mr23767050otm.221.1575963410925; Mon, 09 Dec 2019 23:36:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575963410; cv=none; d=google.com; s=arc-20160816; b=qxcbI88EmVi4Uof41hOw+mj2ysLjEJfeD50Ix1764E0tJsEWkKIxoRRp30yXjkTGQb 6P/w0Xv6gUyc9iLUmo4M9Dj6oi5Q8ieRV6D4nVnh3f+dqKi5AANQAtY8KyW9m+lLlYet UpCjgD25//RZ6HNHoNr9zMRKSqHhLQMNfFI3m1GJpDzgczCtMp6vYPGaWhoiYkli45Qo ffjhlfcosQg8NE+o3gIcilouFmAbJp1VSeyxRwQzSkyJim82jDaNuX4pcsvSLZRoQXtY M9a+xQgXPYn0BSBHuM2LIDQg6XRlWu5JpE974liku0o6phvbg5JN4+BMxcSHCcKWJIRf d/XQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:references:cc:to:from:subject; bh=dcdX4D2kWxnfAhNU2RfTofmxlvBmtrba8as9t1+HP+U=; b=nfv1DTh6JWSPBnu2s7KNCAJhqGk4uNOZYnaQteVsHKgt6eAofuBDEuomXDXGpHrk5c mKyA4XxLvFPJ6Row3q0/JwUcjsf6GRZwfdzpbLDW1+ZdZWWUYOKqE4X+ShJ5UQspd2ig iJ66eDu2Ex6XW3D8G1qCRNv68L2pNn9/s/koCE3AsGhBvzRpMtq0WX8+ZY94ipRthNvc osp7da6eaixyuM8v9h8Gm3AHfwI8+RwCOaQEmLXvSVItqjiW9x8h5tFE9no1fNo4m6+A C5ZXe+PKM/yokIDjpreGc878B/kCPibTDwQyXkjI+MnVTuahYqGE1kO8WKPRR2cCZiAi l03g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c131si1451705oib.267.2019.12.09.23.36.36; Mon, 09 Dec 2019 23:36:50 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727306AbfLJHel (ORCPT + 99 others); Tue, 10 Dec 2019 02:34:41 -0500 Received: from ivanoab7.miniserver.com ([37.128.132.42]:50058 "EHLO www.kot-begemot.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727004AbfLJHel (ORCPT ); Tue, 10 Dec 2019 02:34:41 -0500 Received: from tun252.jain.kot-begemot.co.uk ([192.168.18.6] helo=jain.kot-begemot.co.uk) by www.kot-begemot.co.uk with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iea2X-0001QL-Pm; Tue, 10 Dec 2019 07:34:39 +0000 Received: from sleer.kot-begemot.co.uk ([192.168.3.72]) by jain.kot-begemot.co.uk with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iea2V-000397-E7; Tue, 10 Dec 2019 07:34:37 +0000 Subject: Re: [PATCH v1] uml: remove support for CONFIG_STATIC_LINK From: Anton Ivanov To: Richard Weinberger , Brendan Higgins Cc: Johannes Berg , Jeff Dike , linux-um , linux-kernel , davidgow@google.com References: <20191209230248.227508-1-brendanhiggins@google.com> <1406826345.111805.1575933346955.JavaMail.zimbra@nod.at> <2eecf4dc-eb96-859a-a015-1a4f388b57a2@cambridgegreys.com> Organization: Cambridge Greys Message-ID: <346757c8-c111-f6cf-21d2-b0bffd41b8a8@cambridgegreys.com> Date: Tue, 10 Dec 2019 07:34:35 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <2eecf4dc-eb96-859a-a015-1a4f388b57a2@cambridgegreys.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -1.0 X-Spam-Score: -1.0 X-Clacks-Overhead: GNU Terry Pratchett Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/12/2019 07:20, Anton Ivanov wrote: > On 09/12/2019 23:15, Richard Weinberger wrote: >> ----- Ursprüngliche Mail ----- >>> Von: "Brendan Higgins" >>> An: "Jeff Dike" , "richard" , >>> "anton ivanov" >>> CC: "Johannes Berg" , "linux-um" >>> , "linux-kernel" >>> , davidgow@google.com, "Brendan >>> Higgins" >>> 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/