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

[Anton Ivanov]

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.

> 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/