From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4b5X0D5Yrsz32vw for ; Mon, 26 May 2025 10:23:08 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) client-signature RSA-PSS (4096 bits)) (Client CN "mail01.haj.ipfire.org", Issuer "R10" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4b5X091xzbz2xng for ; Mon, 26 May 2025 10:23:05 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4b5X084pWrz34c; Mon, 26 May 2025 10:23:04 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1748254984; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bKVLHqhSKoObrrHR6VPFf+gAbVfvdqV+XC+CCbPm3No=; b=p7d77SMk5Itt3zeU/eslgpdl8WJh9pWsu8jyeg0eRXRnHVk3XfPM6H9VyEvn+/IzOqXH3p DALIDXz704Qz+0Aw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1748254984; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bKVLHqhSKoObrrHR6VPFf+gAbVfvdqV+XC+CCbPm3No=; b=N7eQ7IC51YxT50YM7ZLoY/nEm6/7PxXEsQ+bEmG9QVKTB6MKUYDl5vVdTLIpyddvtAerVU Miyoz8ASKoZEtE9zogY4BjZyJdRUZ56NaeLYZ87sF1Su7P3ZDtF1e5X/6tfHQXFWpBSUp6 EevfcnkIKfyLnHWpOSw05lkeJWgMmloPUJqm4U6pIzZfYacOM3TDkVNiIB4ofAZr+XR5Vb VMDr1WSvNXsRpZG9XYDtB1t8LuqFH26MQsWNoj+AZktRwrRIRQ0lcwf+MKMxaPA91WMyGZ HSIv/++RRhOQDSK35u3qbJoOrggvOl12HQlRUQOvGo9QbuP2/q/XbjHtyCQCKQ== Content-Type: text/plain; charset=us-ascii Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: ruby build now failing in aarch64 From: Michael Tremer In-Reply-To: Date: Mon, 26 May 2025 11:23:00 +0100 Cc: "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: <293A0544-7EF0-45AF-9A7A-410540AB1509@ipfire.org> References: <9b7b4ae7-9383-4f51-9e23-23979fbc4cd6@ipfire.org> To: Adolf Belka Hello, I have no idea why we are running into this problem. Others have too, = but there seems to be other circumstances. I pushed a patch the other day that fixes the problem for us: = https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3De6791a9e4a32= 10201188daa981d3b2d2c092846e This is a workaround and hopefully we can soon drop this. -Michael > On 15 May 2025, at 17:18, Adolf Belka wrote: >=20 > Hi All, >=20 > On 15/05/2025 16:30, Adolf Belka wrote: >> Hi All, >> The fix to udev to not fail if the linker emits warnings solved the = udev build on aarch64 for me. >> However now it has got to building ruby and that has now failed. >> The error message is >> In file included from vm_core.h:118, >> from eval_intern.h:5, >> from debug.c:16: >> vm_callinfo.h: In function 'vm_ci_dump': >> internal.h:89:72: error: 'RUBY_FUNCTION_NAME_STRING' undeclared = (first use in this function) >> 89 | #define rp(obj) rb_obj_info_dump_loc((VALUE)(obj), __FILE__, = __LINE__, RUBY_FUNCTION_NAME_STRING) >> | = ^~~~~~~~~~~~~~~~~~~~~~~~~ >> vm_callinfo.h:183:9: note: in expansion of macro 'rp' >> 183 | rp(ci); >> | ^~ >> internal.h:89:72: note: each undeclared identifier is reported only = once for each function it appears in >> 89 | #define rp(obj) rb_obj_info_dump_loc((VALUE)(obj), __FILE__, = __LINE__, RUBY_FUNCTION_NAME_STRING) >> | = ^~~~~~~~~~~~~~~~~~~~~~~~~ >> vm_callinfo.h:183:9: note: in expansion of macro 'rp' >> 183 | rp(ci); >> | ^~ >> vm_callinfo.h: In function 'vm_ci_new_': >> internal.h:89:72: error: 'RUBY_FUNCTION_NAME_STRING' undeclared = (first use in this function) >> 89 | #define rp(obj) rb_obj_info_dump_loc((VALUE)(obj), __FILE__, = __LINE__, RUBY_FUNCTION_NAME_STRING) >> | = ^~~~~~~~~~~~~~~~~~~~~~~~~ >> vm_callinfo.h:221:16: note: in expansion of macro 'rp' >> 221 | if (debug) rp(ci); >> | ^~ >> and the RUBY_FUNCTION_NAME_STRING undeclared I found a comment that = it could be related to gcc15 but it seemed to be for windows systems. >> The version of ruby we have is 3.4.1 but 3.4.4 has been just issued = with a fix >> Bug #21286: Windows - MSYS2 just updated to GCC 15.1.0, builds = failing - Ruby - Ruby Issue Tracking System >> The bug report does have comments that it is strongly impacting = windows systems but it is also affecting other OS's. >> I will try doing a build with the latest ruby and see if that solves = the aarch64 build. >=20 > Unfortunately building ruby-3.4.4 did not fix the above problem. The = same errors still occurred. >=20 > Regards, > Adolf. >=20 >> Regards, >> Adolf.