Re: [PATCH v1] uml: remove support for CONFIG_STATIC_LINK

[Anton Ivanov]

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@xxxxxxxxxx>
> > > An: "Jeff Dike" <jdike@xxxxxxxxxxx>, "richard" <richard@xxxxxx>, 
> > > "anton ivanov" <anton.ivanov@xxxxxxxxxxxxxxxxxx>
> > > CC: "Johannes Berg" <johannes.berg@xxxxxxxxx>, "linux-um" 
> > > <linux-um@xxxxxxxxxxxxxxxxxxx>, "linux-kernel"
> > > <linux-kernel@xxxxxxxxxxxxxxx>, davidgow@xxxxxxxxxx, "Brendan 
> > > Higgins" <brendanhiggins@xxxxxxxxxx>
> > > 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@xxxxxxxxxxxxxxxxxxx
> > http://lists.infradead.org/mailman/listinfo/linux-um


--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/