Re: [Pkg-utopia-maintainers] Bug#835550: network-manager: FTBFS on mips* and powerpc - NetworkManager segfaults

Aurelien Jarno <[email protected]> Sat, 27 Aug 2016 13:12:00 +0200
Newsgroups	gmane.linux.debian.ports.mips
Message-ID	<[email protected]>
On 2016-08-27 10:16, Michael Biebl wrote:
> Hi
> 
> Am 27.08.2016 um 01:52 schrieb James Cowgill:
> > network-manager FTBFS on all mips arches and on powerpc with this error:
> 
> 
> >> make[9]: Leaving directory '/«PKGBUILDDIR»/src/settings/plugins/ibft/tests'
> >> LD_BIND_NOW=1 LD_PRELOAD=./../.libs/libnm-settings-plugin-ibft.so ../../../../../src/NetworkManager --version >/dev/null
> >> /bin/bash: line 1: 10923 Segmentation fault      LD_BIND_NOW=1 LD_PRELOAD=./../.libs/libnm-settings-plugin-ibft.so ../../../../../src/NetworkManager --version > /dev/null
> 
> Yeah, I've already seen that and I'm quite puzzled by it.
> 
> > > I tried to build it on mips64el and simply trying to run 'NetworkManager
> > --version' prints out the correct version, then a load of garbage before
> > finally segfaulting.
> > 
> > I haven't done extensive testing, but this bug smells very similar to
> > bug #816059 in lua and is related to using version scripts on certain
> > architectures.
> 
> The version script (in libnm) was already used in 1.2.4-1, which didn't
> FTBFS. I wonder if this is a toolchhain issue on those architectures and
> not a bug in NM.
> 
> I've CCed Aurelien and our mips porters list. It would be great if they
> can help with this.

I haven't looked in details yet, but it looks indeed like the same
issue both by the symptoms and the affected architectures.

The issue happens for architectures which have an upstream glibc port
before glibc 2.1 was released, which corresponds to alpha, i386, m68k,
mips*, powerc and sparc32. The IO functions were significantly reworked
in glibc 2.1, in a way that changes the ABI. To support both ABI,
symbols versioning is used on the functions, but it appeared it was not
enough, so executables built against glibc >= 2.1 gained an additional
symbol, _IO_stdin_used. The presence or the absence of this symbol
control which version of the IO functions to use. This is on the
*executable only*, not on the libraries.

It happens that this symbol is sometimes stripped away from the binaries
for various reason, and it indeed doesn't seem to be present on the
NetworkManager executable on i386. In the lua case it was due to
using symbol versioning on an executable (something not that usual), but
there might be other reasons. In that case it doesn't seem to be due to
symbol versioning.

Note that mixing both versions of the IO functions had limited
consequences up to recently. However GCC >= 5 does more agressive
optimizations than previous versions and the consequences started to be
bigger on some architectures when the libc is built against it.

I'll try to have a look in the next days, but if someone wants to have a
look, the way to go is to understand why the NetworkManager executable
doesn't have the _IO_stdin_used symbol. This can be done even on i386 as
even if the symptoms are not the same it is also affected one way or
another by the issue.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
[email protected]                 http://www.aurel32.net
signature.asc (application/pgp-signature, 819 B)