On Thu, Apr 12 2018, Klemens Nanni <kn@openbsd.org> wrote:
> On Sat, Apr 07, 2018 at 08:26:10AM +0200, Markus Hennecke wrote:
>> With the attached fix the redis port builds, but is unable to complete the
>> regression tests (see https://github.com/antirez/redis/issues/4640).
> What's the status on armv7 without this fix?
Tons of undefined references to functions from libunwind (included in
libc++abi, hence the fix proposed by Markus):
--8<--
[...]
../deps/hiredis/libhiredis.a(hiredis.o):(.ARM.exidx+0xd8): undefined reference to `__aeabi_unwind_cpp_pr1'
../deps/hiredis/libhiredis.a(hiredis.o):(.ARM.exidx+0xe0): more undefined references to `__aeabi_unwind_cpp_pr1' follow
../deps/hiredis/libhiredis.a(hiredis.o):(.ARM.exidx+0x118): undefined reference to `__aeabi_unwind_cpp_pr0'
../deps/hiredis/libhiredis.a(hiredis.o):(.ARM.exidx+0x120): undefined reference to `__aeabi_unwind_cpp_pr1'
../deps/hiredis/libhiredis.a(hiredis.o):(.ARM.exidx+0x128): undefined reference to `__aeabi_unwind_cpp_pr1'
../deps/hiredis/libhiredis.a(hiredis.o):(.ARM.exidx+0x130): undefined reference to `__aeabi_unwind_cpp_pr1'
../deps/hiredis/libhiredis.a(read.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr1'
../deps/hiredis/libhiredis.a(read.o):(.ARM.exidx+0x8): undefined reference to `__aeabi_unwind_cpp_pr1'
../deps/hiredis/libhiredis.a(read.o):(.ARM.exidx+0x10): more undefined references to `__aeabi_unwind_cpp_pr1' follow
../deps/hiredis/libhiredis.a(read.o):(.ARM.exidx+0x18): undefined reference to `__aeabi_unwind_cpp_pr0'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[1]: *** [Makefile:204: redis-server] Error 1
gmake[1]: Leaving directory '/usr/obj/pobj/redis-4.0.8/redis-4.0.8/src'
gmake: *** [Makefile:6: all] Error 2
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2740 '/usr/obj/pobj/redis-4.0.8/.build_done')
*** Error 1 in /usr/ports/databases/redis (/usr/ports/infrastructure/mk/bsd.port.mk:2417 'all')
cubox /usr/obj/pobj/redis-4.0.8/redis-4.0.8$
-->8--
Those functions are referenced because of the use of -funwind-tables on
arm platforms, see src/Makefile:
--8<--
# To get ARM stack traces if Redis crashes we need a special C flag.
ifneq (,$(findstring armv,$(uname_M)))
CFLAGS+=-funwind-tables
endif
-->8--
Maybe clang ought to link with libunwind if -funwind-tables is used, but
we don't provide a separate libunwind library. Maybe Mark (cc'd) has
thoughts to share here.
I can confirm that Markus' diff fixes the build. Another solution would
be to remove the use of -funwind-tables (patch proposal at the end of
this mail, no bump needed). IIUC it's been deemed useful because of
backtrace support in the bundled jemalloc (which we forcibly remove).
> Have you tried the newer
> 4.0.9 version?
*I* haven't, but the snippet above is still in the master branch
upstream, so I wouldn't expect an improvement.
> I don't have access to that platform but the diff looks ok port-wise.
>
> There's another redis diff from me pending on ports@. but I'd also like
> to update the port to 4.0.9, maybe we can combine this with your fix?
Personally I prefer when different issues are addressed by separate
commits.
Index: patch-src_Makefile
===================================================================
RCS file: /d/cvs/ports/databases/redis/patches/patch-src_Makefile,v
retrieving revision 1.27
diff -u -p -p -u -r1.27 patch-src_Makefile
--- patch-src_Makefile 9 Aug 2017 09:16:09 -0000 1.27
+++ patch-src_Makefile 14 Apr 2018 00:27:57 -0000
@@ -21,6 +21,15 @@ Index: src/Makefile
INSTALL=install
# Default allocator defaults to Jemalloc if it's not an ARM
+@@ -40,7 +41,7 @@ endif
+
+ # To get ARM stack traces if Redis crashes we need a special C flag.
+ ifneq (,$(findstring armv,$(uname_M)))
+- CFLAGS+=-funwind-tables
++# CFLAGS+=-funwind-tables
+ endif
+
+ # Backwards compatibility for selecting an allocator
@@ -66,7 +67,7 @@ endif
FINAL_CFLAGS=$(STD) $(WARN) $(OPT) $(DEBUG) $(CFLAGS) $(REDIS_CFLAGS)
FINAL_LDFLAGS=$(LDFLAGS) $(REDIS_LDFLAGS) $(DEBUG)
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
No comments:
Post a Comment