From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Merging feature/android Date: Sun, 5 Mar 2023 01:32:26 -0800 Organization: UCLA Computer Science Department Message-ID: <154a7bcc-f42d-21f1-1780-2dc3bb5443eb@cs.ucla.edu> References: <87edq7ztks.fsf.ref@yahoo.com> <87v8jjxxo9.fsf@yahoo.com> <835ybje2u5.fsf@gnu.org> <87fsanxoah.fsf@yahoo.com> <83zg8vckx5.fsf@gnu.org> <87bklay7wg.fsf@yahoo.com> <83ilficn4k.fsf@gnu.org> <87zg8uw9b9.fsf@yahoo.com> <837cvycjse.fsf@gnu.org> <87ttz2w4c3.fsf@yahoo.com> <83356mcbxw.fsf@gnu.org> <87pm9qvu9w.fsf@yahoo.com> <83y1odc37g.fsf@gnu.org> <87cz5pwf9c.fsf@yahoo.com> <83edq5asb3.fsf@gnu.org> <875ybhvt4w.fsf@yahoo.com> <83356kbxnh.fsf@gnu.org> <87lekcvho4.fsf@yahoo.com> <83r0u4adgd.fsf@gnu.org> <87a60suknn.fsf@yahoo.com> <563e9da9-c45e-a4d2-6dda-074ac035c256@cs.ucla.edu> <871qm3vqez.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5703"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 05 10:33:15 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pYkjy-0001Gy-Hr for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Mar 2023 10:33:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pYkjL-0003Pi-AY; Sun, 05 Mar 2023 04:32:35 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pYkjK-0003P8-Fw for emacs-devel@gnu.org; Sun, 05 Mar 2023 04:32:34 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pYkjI-0001bZ-H9 for emacs-devel@gnu.org; Sun, 05 Mar 2023 04:32:34 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id AA29916004A; Sun, 5 Mar 2023 01:32:27 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id uXFOBikQPSjz; Sun, 5 Mar 2023 01:32:26 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B18A7160086; Sun, 5 Mar 2023 01:32:26 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu B18A7160086 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1678008746; bh=j99XSwZ+coUw8bduRukA4E65ogPNQBFMhkF7XsCBIGw=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type: Content-Transfer-Encoding; b=HzGmNwMSJIomrstUWEz8Jsw742v9BcYUKNu/LXPNh2LRhFL4In1h7gJxbZoxR2x8G 00iaDZ3HFTCF5rqCiKtwIMxi/fTVIRZQqwESVd3FPk3C5lhVvzQO/dbJeSyn1wOuJ5 MpebLvgrkj2ZCuM0Sx7v0vX2MLoCO+0TPN7SQmI0= X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 57KqUjbzMSmk; Sun, 5 Mar 2023 01:32:26 -0800 (PST) Original-Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 8962E16004A; Sun, 5 Mar 2023 01:32:26 -0800 (PST) Content-Language: en-US In-Reply-To: <871qm3vqez.fsf@yahoo.com> Received-SPF: pass client-ip=131.179.128.68; envelope-from=eggert@cs.ucla.edu; helo=zimbra.cs.ucla.edu X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.089, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:303969 Archived-At: On 2023-03-04 19:16, Po Lu wrote: > Paul Eggert writes: > >> Actually dynamic module support should build with Sun C 5.15 (i.e., >> Oracle Solaris Studio 12.6), because Sun C supports GNU C's >> __attribute__ ((cleanup)) extension. I think icc also supports that >> extension. Not that I've ever used modules on those platforms. > > Well, I do recall /opt/SUNwspro/bin/cc choking on emacs-module.c at some > point in the past. That's likely an earlier version of Sun C that does not support __attribute__ ((cleanup)). I doubt whether it's worth worrying about these older Sun C versions. People can get an up-to-date compiler, or (better yet) use GCC. It's not worth our time to port to obsolete Sun C. > the correct solution is to check whether or not the compiler > supports such an extension, and disable dynamic module support should it > not. Which is why we use configure in the first place, instead of > performing ``checks'' with `GNUC_PREREQ'. Emacs uses HAS_ATTRIBUTE, which should use Clang's __has_attribute, which should work with a recent-enough Android NDK (as these are based on Clang). If you're using an older Android NDK based on GCC, yes that does use GNUC_PREREQ, but again this should work unless the older Android NDKs are squirrelly about GCC version numbers (are they?). It's true that the Autoconf Way is to write a little program to test for __attribute__((cleanup)) directly, and that may be a good way to go. However, I would suggest first understanding why the current approach does not work. (But please see below; perhaps we don't need to worry about this at all.) > r21 and r25 are free of this illness, but they don't support old > versions of Android that Emacs does, such as Android 4.4 or 2.2. > > (And the other day someone asked me for a build of Emacs that runs on > Android 4.1, so these versions are evidently being used.) Although I'm sure that ancient Android versions are still used somewhere, I suggest that we not worry about porting to Android versions so old that Google itself no longer supports them. This is the general guideline we've used for most other ports, and it should be a good guideline for Android too. We have limited development resources and it's generally not worth our time to port to an OS if it's not even worth the OS maintainer's time to support the OS. Plus, Emacs is likely to have known security holes if we try to port it to no-longer-supported Android, and that would be bad for our users and bad publicity for Emacs. Android is one of the biggest malware targets out there. > The attribute leads to a compiler error generating while generating > debug information If this Android NDK is so old that Google no longer supports it, I wouldn't worry about it. If not, perhaps we'll need to build Emacs without the debug-info option that is making that buggy compiler crash.