From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 4ijSH5xaHGAhCgAAWB0awg (envelope-from ) for ; Thu, 04 Feb 2021 15:35:40 -0500 Received: by simark.ca (Postfix, from userid 112) id 768DB1EFCB; Thu, 4 Feb 2021 15:35:40 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,MSGID_FROM_MTA_HEADER,RDNS_NONE, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 18F8E1E945 for ; Thu, 4 Feb 2021 15:35:40 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8B840393C863; Thu, 4 Feb 2021 20:35:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8B840393C863 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1612470939; bh=SeSP73oeGPyPPc6UwrX+zx6vtCfKUg5zAmSLzN0iCAc=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=HWZ132bSXGQvTfjDAYqgf0oB2E+ItxXe2NG2qr9zCHSwREPV1QcxTaDDZ7XlWK52o Yheu67+uSg+6wIwUgfleQ4T2DdHFJpURhtohFt59RWTTypcQry2e/deQCyJFTSzDS2 CpAsY5Oqxt3k1i0vV1nZ79Y2wi2KV7ifYa2kFWEE= Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) by sourceware.org (Postfix) with ESMTPS id 82F55385701E for ; Thu, 4 Feb 2021 20:35:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 82F55385701E Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 114KTbjT118183; Thu, 4 Feb 2021 20:35:34 GMT Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 36cydm731q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 04 Feb 2021 20:35:33 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 114KUUka117069; Thu, 4 Feb 2021 20:35:33 GMT Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2176.outbound.protection.outlook.com [104.47.59.176]) by userp3020.oracle.com with ESMTP id 36dh7vpr9c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 04 Feb 2021 20:35:33 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=byNiw9eC1uFoogLsI6NOWlFs3/BYl+9LWgLPcG+YtfYskHmb/K5/s1tJ0dZUAR4+MW9VNhiIQ+8hG4TCUMZsXvdTkZ5o+hyeAoF5Onw5K5GfWCQ9R+3ZJSa00fqEJBlFo+959I4no9LRhOWF9N1kIFA9Kr9pXpJw4pVLnzKTKJwcR04qw3DT+7FMtza5PTemEOXOWcISYNIfxLCYdG8Wr+HFKP6dK4x7lq4qtLy+C2tiVzxq0V/RVD6Rw2JHINHeAbMd2RUyqlvENhDpwkjwrGWq9XiLMFaRwz0UmAK5llrEmRQUqlMHkYhJKqC+RVd7bcOSVnNTC2zPpUdAnYLBqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SeSP73oeGPyPPc6UwrX+zx6vtCfKUg5zAmSLzN0iCAc=; b=CYPUD4rOgpARnX8Yg7QiYr5ld62YmEBK4s0fdumMjgAAFaO0hdmAM1Ogsaxs1th+L0zdRZW2DKpgcPhv13TefUAdDio58Nmsn9b53ik/f64F+mmFQRKYupVrw3vESXCXrHZZXgOgY0cMWBLYOn8p80ds4amRLqt8NIuerh3clU3GYyjJgjmkoe6WE9vmIuWNM4G3+lUk//tTAkL1fvavz0y28H57rtLxNK04qnl9dnqnpJNOjzZA8SFpgh9jankKSD4MoHxogxWRIFBYqNLnDbczrpBD5kUFcK4ueGxw/1zDuFaQU6C+0mkogTFNMEMnT7kbZ9wEz9RHusm4dyPHYA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none Received: from SA2PR10MB4715.namprd10.prod.outlook.com (2603:10b6:806:fb::10) by SA2PR10MB4410.namprd10.prod.outlook.com (2603:10b6:806:fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.19; Thu, 4 Feb 2021 20:35:29 +0000 Received: from SA2PR10MB4715.namprd10.prod.outlook.com ([fe80::7c52:48f6:5d6b:5643]) by SA2PR10MB4715.namprd10.prod.outlook.com ([fe80::7c52:48f6:5d6b:5643%7]) with mapi id 15.20.3805.028; Thu, 4 Feb 2021 20:35:29 +0000 To: Stephen Casner Subject: new gdb build failures on MacOS X (... fallout from libintl fixups, see users/nalcock/included-gettext) References: <874kird819.fsf@esperi.org.uk> Emacs: Lovecraft was an optimist. Date: Thu, 04 Feb 2021 20:35:23 +0000 In-Reply-To: (Stephen Casner's message of "Thu, 4 Feb 2021 12:00:27 -0800 (PST)") Message-ID: <87k0rna7w4.fsf_-_@esperi.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3.50 (gnu/linux) Content-Type: text/plain X-Originating-IP: [2001:8b0:1101:10::2] X-ClientProxiedBy: LO2P265CA0271.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a1::19) To SA2PR10MB4715.namprd10.prod.outlook.com (2603:10b6:806:fb::10) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from loom (2001:8b0:1101:10::2) by LO2P265CA0271.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a1::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.17 via Frontend Transport; Thu, 4 Feb 2021 20:35:28 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 878fbf59-f9dc-44c2-ee0b-08d8c94c690a X-MS-TrafficTypeDiagnostic: SA2PR10MB4410: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rgIz7BRnW+aiFSatC2RdWMPN0u7AMt5RHUJJ1E64WwzFzf42LQwTNqqSxwYAedMoSFc3e4ajI6a8PqzIoPX/u49eMmYzv35aS2SW35aTy+q6Yfwg0yGl3mXs1Q8wvUKlOWq9lOaKAfmRAsvqnCHZOTlgYw4q9KxZjDEKzE7587/WD7P5pCofSpPgeFABP5wPI5E8mwY1E6TMxk+hN4R0lqPF8i6+tvqV3yoPGGtaFvlDMGZvWWaDt945y+5XonQdr1B6W05cAalEHu1M7reXMY9towruU9m/ktY37NpYfUXWxnPsU5yCYeOSebtDFPUVFy9HaJ1ph6ZTRQmFGv/HHlDG7fDHRFnUO1M2lF+BB4labSCGxGW5o//yokv1WUGmv52FjO3zbxdC/LcF4/jsuQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR10MB4715.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(366004)(376002)(396003)(39860400002)(52116002)(36756003)(5660300002)(6666004)(4326008)(83380400001)(6486002)(6496006)(66556008)(478600001)(186003)(44832011)(54906003)(8676002)(8936002)(86362001)(6916009)(66476007)(2906002)(16526019)(66946007)(316002)(9686003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?16VzM/kRdy1kdzTJCQDOqwLJQdUezE3UTkqROL8qQ9NYPd5RvYI/fgs980eM?= =?us-ascii?Q?X1AL/pD3Ai8nYny0iEz3x8KXH6owdA4G5TvV1kHXHQbbZ+r5cHBUoQQdQaUu?= =?us-ascii?Q?i5soWvigBfwgtU0H/WFc5ecw96OnyqFheMglSd2Go+/5HtFIA4p1Zip2A/D3?= =?us-ascii?Q?Jd+Z1JZAFOnubEFV5SPhzVilKNailpI/x4P7jNVUM8eUC+G8meRSmF09724B?= =?us-ascii?Q?HCACFaHFPLPqvgdf7Z2r8JC3cdyuLwbZUR5cifTCFrBlShCCBWpBDnb1U3nh?= =?us-ascii?Q?l3lyZ25aWzunuyLjbpnzuHiTRJ2q2DIb9saLF70uMEpu+vpxc3cCQ/TiQNzQ?= =?us-ascii?Q?opp4Gq84ime8FPM5817QU11EbNPliNcJ4hKS/F7xDz6loQlNeSGIe7RHL4J4?= =?us-ascii?Q?zAsTNelQvHcUctDdF4A6KEx/TU3VruGQuGC9wcr7maG7VPwM+ussr92zXcDA?= =?us-ascii?Q?/cUpb7OLtvllLK1zI75PM4Xvx7qilkxE259M32iy1zlOwk3w8fmTYGUEhq9t?= =?us-ascii?Q?9P4gU6YPEGQG2HuXXPWsozMixw8jWLqfmaUSQAbFrGByHCXHVFWotMyRaiup?= =?us-ascii?Q?4M+9I8hPdGIwvSKNEoqGBVM99KdqcFIKr1ijuyVNULfgrEMz6YmG0D21alyx?= =?us-ascii?Q?dwGpkqiPyCgSOHK9+yyR1bHityiYpwD9Ltk+GFcaQ9vcSCD6eEj+fwLKS9cE?= =?us-ascii?Q?2qqMzuVxs9u43W64DWVt6GGp+X7YH4xuVKWpRU6WGAnLx1eTDcQf5FN3aw77?= =?us-ascii?Q?GYh6YDd6qcur/82po7erYre7wzD28tbVbFNMgSodG+C9qAMrQrSEaZEDOJJu?= =?us-ascii?Q?6Q688PTV5ATefKIltvZ1aTg0KS+B+3HfdgmIzx3nYBI6sZAoY6pdAKLwXFOl?= =?us-ascii?Q?UcljGVhxdQnfmXzcj85TA7SCvliUiD7Goa1t2kyBQU+8pZxEHS/idCLT0MC0?= =?us-ascii?Q?IVlK3fcz8imbvfg6QVZSEpkwBn7ys+/YHob0Yk609TfRf5oy/uqrNCpMeZKZ?= =?us-ascii?Q?Bv6rOCrV0cGY242A28O7a1ejQq3XSCXb3ObVHQERBGgCKG6gXnpDohIQsRt8?= =?us-ascii?Q?vOWMtUuI5RHp/Bi0slE0Z41tnGNvxw=3D=3D?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 878fbf59-f9dc-44c2-ee0b-08d8c94c690a X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4715.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Feb 2021 20:35:29.3202 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: dlptdPFBcWSfZNYhNqLbUcViHCSMBK2PjrVe4vdYll+Zv1wkKv8ixsLfcYuQVnx9f3dtX6FCizzcZcBu8Wc4ZQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4410 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9885 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0 suspectscore=0 spamscore=0 mlxlogscore=999 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102040126 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9885 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 clxscore=1011 spamscore=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102040126 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Nick Alcock via Gdb-patches Reply-To: Nick Alcock Cc: gdb-patches Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" [gcc-patches Cc:ed for the elfcore failure, not so much for the iconv stuff yet, since I'm revamping a lot of that stuff in bfd/opcodes/etc and that should probably get looked at before the gdb side, I guess. See the git branch referenced below.] On 4 Feb 2021, Stephen Casner told this: > On Thu, 4 Feb 2021, Nick Alcock wrote: > >> I've updated the users/nalcock/included-gettext branch on >> binutils-gdb.git with a new approach which is rather less gross than the >> horrible stuff I was doing before. >> >> It still seems to work for me: could you check to see if it still works >> for you? > > This version introduces two new undefined symbols in the gdb link: Oh dammit. > Undefined symbols for architecture x86_64: > "_elfcore_write_prstatus", referenced from: > gcore_collect_regset_section_cb(char const*, int, int, regset const*, char const*, void*) in gcore.o > "_elfcore_write_register_note", referenced from: > gcore_collect_regset_section_cb(char const*, int, int, regset const*, char const*, void*) in gcore.o I think this may not be my fault but rather is unrelated fallout from commit 82a1fd3a4935fe665cf08bc6820942c4a091184c, which just landed. As of this commit, elfcore_write_register_note et al are unconditionally cited from gdb/gcore.c, but obviously these are only going to exist for ELF platforms, which MacOS X is not. > the gdb link fails with these undefined symbols: > > "_iconv", referenced from: > __nl_find_msg in libintl.a(dcigettext.o) > "_iconv_close", referenced from: > __nl_free_domain_conv in libintl.a(loadmsgcat.o) > "_iconv_open", referenced from: > __nl_init_domain_conv in libintl.a(loadmsgcat.o) Now *this* is probably, er... well, I'm not sure it's my fault because I didn't touch gdb, only gdbserver and intl/ itself (in a way that shouldn't have affected the way gdb uses it), but it's certainly suboptimal. gdb is linked with $(INTL), which is derived from @LIBINTL@, which comes from intl/config.intl: I would have expected this to include -liconv if needed > To satisfy those I need to hack the gdb/Makefile to append > /usr/lib/libiconv.dylib (the system libiconv, which is old) after two > instances of -liconv. If I replace -liconv rather than appending then > I get three different undefined symbols: Hmm, so -liconv isn't loading /usr/lib/libiconv.dylib? The -L stuff I tore out of libopcodes and bfd (which might be relevant) is -L`pwd`/../libiberty/pic -L`pwd`/../intl -liberty -lintl, which also does not explicitly cite libiconv. (The libiberty stuff is brought back in a bit further up, and the intl stuff should be retained via $(LTLIBINTL) as well.) > "_libiconv", referenced from: Oh wonderful. _iconv *and* _libiconv? > So the gdb link requires two different iconv libraries presumably > because different parts of the build choose different references. Looks like it. A full log of the compilation of gdb/ at least (and preferably the whole build) might give more info about which bits are using what. > I run into the same problem building gcc, and use the same hack. I've Oh well. That can't be related to what I'm doing, then -- I haven't touched the GCC tree. > been trying to figure out how to fix this properly but so far I have > not gained enough familiarity with the configure and Makefile morass > to find the answer. There is a --with-libiconv-prefix option for gdb, > but when I include that it causes -I./../intl to be removed from the > compile commands for bfd Yeah, intl/ also has --with-libiconv-prefix, which is probably triggering this -- though that just sets --prefix for the intl/ tree, which I wouldn't really expect to cause this (but I've never tried that option, so I'm not sure).