From: Anton Ivanov <anton.ivanov@cambridgegreys.com> To: Richard Weinberger <richard@nod.at>, Brendan Higgins <brendanhiggins@google.com> Cc: Johannes Berg <johannes.berg@intel.com>, Jeff Dike <jdike@addtoit.com>, linux-um <linux-um@lists.infradead.org>, linux-kernel <linux-kernel@vger.kernel.org>, davidgow@google.com Subject: Re: [PATCH v1] uml: remove support for CONFIG_STATIC_LINK Date: Tue, 10 Dec 2019 07:34:35 +0000 [thread overview] Message-ID: <346757c8-c111-f6cf-21d2-b0bffd41b8a8@cambridgegreys.com> (raw) In-Reply-To: <2eecf4dc-eb96-859a-a015-1a4f388b57a2@cambridgegreys.com> On 10/12/2019 07:20, Anton Ivanov wrote: > On 09/12/2019 23:15, Richard Weinberger wrote: >> ----- Ursprüngliche Mail ----- >>> Von: "Brendan Higgins" <brendanhiggins@google.com> >>> An: "Jeff Dike" <jdike@addtoit.com>, "richard" <richard@nod.at>, >>> "anton ivanov" <anton.ivanov@cambridgegreys.com> >>> CC: "Johannes Berg" <johannes.berg@intel.com>, "linux-um" >>> <linux-um@lists.infradead.org>, "linux-kernel" >>> <linux-kernel@vger.kernel.org>, davidgow@google.com, "Brendan >>> Higgins" <brendanhiggins@google.com> >>> 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/
WARNING: multiple messages have this Message-ID (diff)
From: Anton Ivanov <anton.ivanov@cambridgegreys.com> To: Richard Weinberger <richard@nod.at>, Brendan Higgins <brendanhiggins@google.com> Cc: davidgow@google.com, Jeff Dike <jdike@addtoit.com>, linux-um <linux-um@lists.infradead.org>, linux-kernel <linux-kernel@vger.kernel.org>, Johannes Berg <johannes.berg@intel.com> Subject: Re: [PATCH v1] uml: remove support for CONFIG_STATIC_LINK Date: Tue, 10 Dec 2019 07:34:35 +0000 [thread overview] Message-ID: <346757c8-c111-f6cf-21d2-b0bffd41b8a8@cambridgegreys.com> (raw) In-Reply-To: <2eecf4dc-eb96-859a-a015-1a4f388b57a2@cambridgegreys.com> On 10/12/2019 07:20, Anton Ivanov wrote: > On 09/12/2019 23:15, Richard Weinberger wrote: >> ----- Ursprüngliche Mail ----- >>> Von: "Brendan Higgins" <brendanhiggins@google.com> >>> An: "Jeff Dike" <jdike@addtoit.com>, "richard" <richard@nod.at>, >>> "anton ivanov" <anton.ivanov@cambridgegreys.com> >>> CC: "Johannes Berg" <johannes.berg@intel.com>, "linux-um" >>> <linux-um@lists.infradead.org>, "linux-kernel" >>> <linux-kernel@vger.kernel.org>, davidgow@google.com, "Brendan >>> Higgins" <brendanhiggins@google.com> >>> 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/ _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um
next prev parent reply other threads:[~2019-12-10 7:34 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-09 23:02 [PATCH v1] uml: remove support for CONFIG_STATIC_LINK Brendan Higgins 2019-12-09 23:02 ` Brendan Higgins 2019-12-09 23:15 ` Richard Weinberger 2019-12-09 23:15 ` Richard Weinberger 2019-12-10 7:20 ` Anton Ivanov 2019-12-10 7:20 ` Anton Ivanov 2019-12-10 7:34 ` Anton Ivanov [this message] 2019-12-10 7:34 ` Anton Ivanov 2019-12-10 8:28 ` Johannes Berg 2019-12-10 8:28 ` Johannes Berg 2019-12-10 8:54 ` Anton Ivanov 2019-12-10 8:54 ` Anton Ivanov 2019-12-10 19:41 ` Brendan Higgins 2019-12-10 19:41 ` Brendan Higgins 2019-12-10 8:34 ` Richard Weinberger 2019-12-10 8:34 ` Richard Weinberger [not found] ` <DM6PR10MB3225EB0C204572F8D39C0ED5E2550@DM6PR10MB3225.namprd10.prod.outlook.com> 2019-12-12 5:23 ` James McMechan 2019-12-12 7:14 ` Anton Ivanov 2019-12-12 7:14 ` Anton Ivanov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=346757c8-c111-f6cf-21d2-b0bffd41b8a8@cambridgegreys.com \ --to=anton.ivanov@cambridgegreys.com \ --cc=brendanhiggins@google.com \ --cc=davidgow@google.com \ --cc=jdike@addtoit.com \ --cc=johannes.berg@intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-um@lists.infradead.org \ --cc=richard@nod.at \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.