From mboxrd@z Thu Jan 1 00:00:00 1970 From: Filipe Brandenburger Subject: Re: Build failure on armhf Date: Wed, 30 Dec 2015 09:06:46 -0800 Message-ID: References: <20151212135721.GA18797@debian> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aEKD3-0005Wb-K6 for guix-devel@gnu.org; Wed, 30 Dec 2015 12:06:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aEKD2-0007tR-HO for guix-devel@gnu.org; Wed, 30 Dec 2015 12:06:49 -0500 Received: from mail-yk0-x22e.google.com ([2607:f8b0:4002:c07::22e]:33593) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aEKD2-0007tC-C1 for guix-devel@gnu.org; Wed, 30 Dec 2015 12:06:48 -0500 Received: by mail-yk0-x22e.google.com with SMTP id k129so137739887yke.0 for ; Wed, 30 Dec 2015 09:06:46 -0800 (PST) In-Reply-To: <20151212135721.GA18797@debian> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Andreas Enge Cc: guix-devel@gnu.org, linux-numa@vger.kernel.org Hi Andreas, On Sat, Dec 12, 2015 at 5:57 AM, Andreas Enge wrote: > numactl fails to build on armhf: > http://hydra.gnu.org/build/866208/log/raw > with the following error message: > syscall.c:113:2: error: #error "Add syscalls for your architecture or update kernel headers" > #error "Add syscalls for your architecture or update kernel headers" > > Is this a known limitation? So syscall.c defines the syscall numbers for syscalls such as set_mempolicy, migrate_pages, etc. The syscalls numbers are different on different Linux platforms, so it's only currently defined for a handful of platforms. As the error message says, if you find that error, maybe you should consider adding the syscall numbers for your platform there? > If yes, could it maybe be detected during the > call to "configure"? The detection is fairly complex, it mainly depends on compiler macros being defined for your platform. Furthermore, adding platform detection code to configure would probably create duplication, in that both configure.ac and syscalls.c would need to be updated to add support for a new platform. What is the problem you are trying to solve? Cheers, Filipe