Package: protobuf
Version: 3.5.2-1
Tags: ftbfs upstream
Usertags: x32
Severity: important
Justification: Fails to build from source (previously built
successfully for x32)
X-Debbugs-CC: debian-am...@lists.debian.org

Dear maintainer,

ruby-google-protobuf does not link under the x32 ABI, and seems to
block other components of protobuf:
https://buildd.debian.org/status/package.php?p=protobuf&suite=sid

protobuf assumes that glibc 2.2.5 memcpy symbols will be available #if
defined(__x86-64__); however, x32 also defines this, but was not
supported prior to 2.16.

The current build log displays the issue:
https://buildd.debian.org/status/fetch.php?pkg=protobuf&arch=x32&ver=3.6.1.3-2&stamp=1555545463&raw=0

gcc -shared -o protobuf_c.so defs.o encode_decode.o map.o message.o
protobuf.o repeated_field.o storage.o upb.o wrap_memcpy.o -L.
-L/usr/lib/x86_64-linux-gnux32 -L. -Wl,-z,relro -Wl,-z,now
-fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-wrap,memcpy
-Wl,-z,relro -Wl,-z,now -Wl,--compress-debug-sections=zlib
-lruby-2.5  -lpthread -lgmp -ldl -lcrypt -lm   -lc
/usr/bin/ld: protobuf_c.so: no symbol version section for versioned
symbol `memcpy@GLIBC_2.2.5'
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:260: protobuf_c.so] Error 1
make[2]: Leaving directory
'/<<PKGBUILDDIR>>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnux32/rubygems-integration/2.5.0/gems/google-protobuf-3.6.1/ext/google/protobuf_c'
ERROR:  Error installing /tmp/d20190417-571-uvvnmj/google-protobuf-3.6.1.gem:
ERROR: Failed to build gem native extension.

I believe this may be due to a fix to preserve compatibility for
CentOS 6 and Debian 7:
https://github.com/protocolbuffers/protobuf/issues/2783
https://github.com/protocolbuffers/protobuf/pull/2831/commits/a7e05be8ec2e0873efa2e69c23ec8d3f67d52e2d

This makes sense as the issue started after moving to 3.5 (which also
broke support for alpha - both are stuck at 3.0.0-9.2, for different
reasons).

The Ruby protobuf extension demands memcpy symbols from glibc 2.2.5
(from 2002), the first to support x86-64/Linux. From the relevant
source file:
https://chromium.googlesource.com/external/github.com/google/protobuf/+/HEAD/ruby/ext/google/protobuf_c/wrap_memcpy.c

// On x86-64 Linux with glibc, we link against the 2.2.5 version of memcpy so
// that we avoid depending on the 2.14 version of the symbol. This way,
// distributions that are using pre-2.14 versions of glibc can successfully use
// the gem we distribute
(https://github.com/protocolbuffers/protobuf/issues/2783).
//
// This wrapper is enabled by passing the linker flags -Wl,-wrap,memcpy in
// extconf.rb.

x32 was first supported from glibc 2.16 (from 2012):
https://sourceware.org/glibc/wiki/x32
I'm guessing it doesn't have those symbols (and can't be affected by
the problem with pre-2.14).

--

Per https://wiki.debian.org/X32Port#Detecting_X32
One solution seems to be to change the file upstream:
#if defined(__x86_64__) && defined(__GNU_LIBRARY__)
to:
#if defined(__x86_64__) && !defined(__ILP32__) && defined(__GNU_LIBRARY__)

because x32 has __ILP32__ while regular x86-64 has __LP64__ instead.

Alternatively it might be suitable to patch extconf.rb on x32, or drop
the wrapper entirely on Debian (Centos 6 is still in maintenance
support through November 30th, 2020).

--

This bug may also apply to gRPC which has a substantially similar
wrapper, enabled via patch:
https://github.com/grpc/grpc/blob/debian/sid/src/core/lib/support/wrap_memcpy.c
https://sources.debian.org/patches/grpc/1.16.1-1/add-wrap-memcpy-flags.diff/

Any failure is currently hidden as it is BD-Uninstallable due to a
lack of a recent protobuf-compiler:
https://buildd.debian.org/status/package.php?p=grpc&suite=sid
but it may be revealed if this is fixed without a corresponding change.

gRPC also appears to lacks this define restricting the above fix to glibc:
https://chromium.googlesource.com/external/github.com/google/protobuf/+/ea5ef14aa01701f686c52de4e724f66101c8e163%5E%21/

Best regards,
-- 
Laurence "GreenReaper" Parry
https://www.greenreaper.co.uk/

Reply via email to