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

James Cowgill <[email protected]> Sat, 27 Aug 2016 15:05:46 +0100
Newsgroups	gmane.linux.debian.ports.mips
Message-ID	<[email protected]>
Hi,

On 27/08/16 12:12, Aurelien Jarno wrote:
> On 2016-08-27 10:16, Michael Biebl wrote:
>> 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.

I just tried 1.2.4-2 on mips as well and NetworkManager also segfaults
there - so the bug already existed but wasn't caught until now.

Adding _IO_stdin_used to the list of global symbols in
src/NetworkManager.ver (like the fix used in lua) seems to fix
everything. That should make the symbol visible to glibc again.

James
signature.asc (application/pgp-signature, 801 B)