Github messages for voidlinux
 help / color / mirror / Atom feed
From: voidlinux-github@inbox.vuxu.org
To: ml@inbox.vuxu.org
Subject: Re: [PR PATCH] [Updated] gperftools: musl fixes, ppc fixes
Date: Tue, 08 Oct 2019 12:17:57 +0200	[thread overview]
Message-ID: <20191008101757.17MGqK1orHxbgWC1CjFXvLrJX5xqdd6v5Udm-c6EDjg@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-15226@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

There is an updated pull request by q66 against master on the void-packages repository

https://github.com/void-ppc/void-packages gperftools
https://github.com/void-linux/void-packages/pull/15226

gperftools: musl fixes, ppc fixes
This allows some parts of the code that previously didn't build on musl to build. Additionally, it fixes build on musl ppc setups.

A patch file from https://github.com/void-linux/void-packages/pull/15226.patch is attached

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: github-pr-gperftools-15226.patch --]
[-- Type: text/x-diff, Size: 6898 bytes --]

From f10564d1b1e8dac27ebdd3a9ad96209294678c5b Mon Sep 17 00:00:00 2001
From: q66 <daniel@octaforge.org>
Date: Tue, 8 Oct 2019 01:58:36 +0200
Subject: [PATCH] gperftools: musl fixes, ppc fixes

This allows some parts of the code that previously didn't build
on musl to build. Additionally, it fixes build on musl ppc setups.
---
 .../patches/elf-mem-image-musl.patch          | 13 ++++
 srcpkgs/gperftools/patches/ppc-musl.patch     | 76 +++++++++++++++++++
 srcpkgs/gperftools/template                   | 22 +++++-
 3 files changed, 108 insertions(+), 3 deletions(-)
 create mode 100644 srcpkgs/gperftools/patches/elf-mem-image-musl.patch
 create mode 100644 srcpkgs/gperftools/patches/ppc-musl.patch

diff --git a/srcpkgs/gperftools/patches/elf-mem-image-musl.patch b/srcpkgs/gperftools/patches/elf-mem-image-musl.patch
new file mode 100644
index 00000000000..541cde28b2b
--- /dev/null
+++ b/srcpkgs/gperftools/patches/elf-mem-image-musl.patch
@@ -0,0 +1,13 @@
+This relies on link.h, which is present in musl as well as glibc.
+
+--- src/base/elf_mem_image.h
++++ src/base/elf_mem_image.h
+@@ -43,7 +43,7 @@
+ 
+ // Maybe one day we can rewrite this file not to require the elf
+ // symbol extensions in glibc, but for right now we need them.
+-#if defined(__ELF__) && defined(__GLIBC__) && !defined(__native_client__)
++#if defined(__ELF__) && !defined(__native_client__)
+ 
+ #define HAVE_ELF_MEM_IMAGE 1
+ 
diff --git a/srcpkgs/gperftools/patches/ppc-musl.patch b/srcpkgs/gperftools/patches/ppc-musl.patch
new file mode 100644
index 00000000000..d7a3645d6d7
--- /dev/null
+++ b/srcpkgs/gperftools/patches/ppc-musl.patch
@@ -0,0 +1,76 @@
+Compatibility fixes for musl.
+
+--- m4/pc_from_ucontext.m4
++++ m4/pc_from_ucontext.m4
+@@ -31,6 +31,7 @@ AC_DEFUN([AC_PC_FROM_UCONTEXT],
+    pc_fields="$pc_fields uc_mcontext.gregs[[R15]]"     # Linux (arm old [untested])
+    pc_fields="$pc_fields uc_mcontext.arm_pc"           # Linux (arm arch 5)
+    pc_fields="$pc_fields uc_mcontext.gp_regs[[PT_NIP]]"  # Suse SLES 11 (ppc64)
++   pc_fields="$pc_fields uc_mcontext.gregs[[PT_NIP]]"
+    pc_fields="$pc_fields uc_mcontext.mc_eip"           # FreeBSD (i386)
+    pc_fields="$pc_fields uc_mcontext.mc_rip"           # FreeBSD (x86_64 [untested])
+    pc_fields="$pc_fields uc_mcontext.__gregs[[_REG_EIP]]"  # NetBSD (i386)
+@@ -55,7 +56,8 @@ AC_DEFUN([AC_PC_FROM_UCONTEXT],
+                         pc_field_found=true)
+        elif test "x$ac_cv_header_sys_ucontext_h" = xyes; then
+          AC_TRY_COMPILE([#define _GNU_SOURCE 1
+-                         #include <sys/ucontext.h>],
++                         #include <sys/ucontext.h>
++                         #include <asm/ptrace.h>],
+                         [ucontext_t u; return u.$pc_field == 0;],
+                         AC_DEFINE_UNQUOTED(PC_FROM_UCONTEXT, $pc_field,
+                                            How to access the PC from a struct ucontext)
+@@ -63,7 +65,8 @@ AC_DEFUN([AC_PC_FROM_UCONTEXT],
+                         pc_field_found=true)
+        elif test "x$ac_cv_header_ucontext_h" = xyes; then
+          AC_TRY_COMPILE([#define _GNU_SOURCE 1
+-                         #include <ucontext.h>],
++                         #include <ucontext.h>
++                         #include <asm/ptrace.h>],
+                         [ucontext_t u; return u.$pc_field == 0;],
+                         AC_DEFINE_UNQUOTED(PC_FROM_UCONTEXT, $pc_field,
+                                            How to access the PC from a struct ucontext)
+--- src/getpc.h
++++ src/getpc.h
+@@ -65,6 +65,9 @@
+ typedef ucontext ucontext_t;
+ #endif
+ 
++#if defined(__powerpc__) && !defined(PT_NIP)
++#define PT_NIP 32
++#endif
+ 
+ // Take the example where function Foo() calls function Bar().  For
+ // many architectures, Bar() is responsible for setting up and tearing
+--- src/stacktrace_powerpc-linux-inl.h
++++ src/stacktrace_powerpc-linux-inl.h
+@@ -186,7 +186,7 @@ static int GET_STACK_TRACE_OR_FRAMES {
+           ucontext_t uc;
+         // We don't care about the rest, since the IP value is at 'uc' field.
+         } *sigframe = reinterpret_cast<signal_frame_64*>(current);
+-        result[n] = (void*) sigframe->uc.uc_mcontext.gp_regs[PT_NIP];
++        result[n] = (void*) sigframe->uc.uc_mcontext.gp_regs[32];
+       }
+ #else
+       if (sigtramp32_vdso && (sigtramp32_vdso == current->return_addr)) {
+@@ -196,7 +196,7 @@ static int GET_STACK_TRACE_OR_FRAMES {
+           mcontext_t mctx;
+           // We don't care about the rest, since IP value is at 'mctx' field.
+         } *sigframe = reinterpret_cast<signal_frame_32*>(current);
+-        result[n] = (void*) sigframe->mctx.gregs[PT_NIP];
++        result[n] = (void*) sigframe->mctx.gregs[32];
+       } else if (sigtramp32_rt_vdso && (sigtramp32_rt_vdso == current->return_addr)) {
+         struct rt_signal_frame_32 {
+           char dummy[64 + 16];
+@@ -204,7 +204,11 @@ static int GET_STACK_TRACE_OR_FRAMES {
+           ucontext_t uc;
+           // We don't care about the rest, since IP value is at 'uc' field.A
+         } *sigframe = reinterpret_cast<rt_signal_frame_32*>(current);
++#if defined(__GLIBC__)
+         result[n] = (void*) sigframe->uc.uc_mcontext.uc_regs->gregs[PT_NIP];
++#else
++        result[n] = (void*) sigframe->uc.uc_mcontext.gregs[32];
++#endif
+       }
+ #endif
+ 
diff --git a/srcpkgs/gperftools/template b/srcpkgs/gperftools/template
index 0cb00c5fb97..bded7024477 100644
--- a/srcpkgs/gperftools/template
+++ b/srcpkgs/gperftools/template
@@ -1,8 +1,9 @@
 # Template file for 'gperftools'
 pkgname=gperftools
 version=2.7
-revision=2
+revision=3
 build_style=gnu-configure
+hostmakedepends="automake libtool"
 makedepends="libunwind-devel"
 checkdepends="perl"
 short_desc="Multi-threaded malloc() and performance analysis tools"
@@ -12,11 +13,22 @@ homepage="https://github.com/gperftools/gperftools"
 distfiles="https://github.com/${pkgname}/${pkgname}/releases/download/${pkgname}-${version}/${pkgname}-${version}.tar.gz"
 checksum=1ee8c8699a0eff6b6a203e59b43330536b22bbcbe6448f54c7091e5efb0763c9
 
+if [ "$XBPS_TARGET_LIBC" = "musl" ]; then
+	# needed by some newly enabled code
+	CXXFLAGS+=" -D__WORDSIZE=$XBPS_TARGET_WORDSIZE"
+	# needed on musl other than x86_64
+	if [ "$XBPS_TARGET_MACHINE" != "x86_64-musl" ]; then
+		makedepends+=" libucontext-devel"
+		LDFLAGS+=" -lucontext"
+	fi
+fi
+
 case "$XBPS_TARGET_MACHINE" in
 	arm*-musl|aarch64-musl)
+		# having libunwind in makedepends still causes failures...
 		makedepends="libucontext-devel"
-		LDFLAGS=" -lucontext"
-		configure_args="--disable-libunwind"
+		configure_args+=" --disable-libunwind"
+		;;
 esac
 
 post_extract() {
@@ -24,6 +36,10 @@ post_extract() {
 		src/base/linux_syscall_support.h src/malloc_hook_mmap_linux.h
 }
 
+pre_configure() {
+	autoreconf -fi
+}
+
 post_install() {
 	vlicense COPYING
 	rm -rf ${DESTDIR}/usr/share/doc

  parent reply	other threads:[~2019-10-08 10:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-08  0:20 [PR PATCH] " voidlinux-github
2019-10-08  1:55 ` [PR PATCH] [Updated] " voidlinux-github
2019-10-08  1:55 ` voidlinux-github
2019-10-08  9:53 ` voidlinux-github
2019-10-08 10:01 ` [PR PATCH] [Updated] " voidlinux-github
2019-10-08 10:01 ` voidlinux-github
2019-10-08 10:02 ` voidlinux-github
2019-10-08 10:17 ` [PR PATCH] [Updated] " voidlinux-github
2019-10-08 10:17 ` voidlinux-github [this message]
2019-10-08 19:30 ` [PR PATCH] [Merged]: " voidlinux-github

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191008101757.17MGqK1orHxbgWC1CjFXvLrJX5xqdd6v5Udm-c6EDjg@z \
    --to=voidlinux-github@inbox.vuxu.org \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).