From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED.jFK6OqqKW5bkmQ4H/i1UAQ.user.gioia.aioe.org!not-for-mail
From: "Luke A. Guest" <laguest@archeia.com>
Newsgroups: comp.lang.ada
Subject: Re: Ada on Apple's new procesors
Date: Tue, 30 Jun 2020 14:28:06 +0100
Organization: Aioe.org NNTP Server
Message-ID: <rdfemt$17vt$2@gioia.aioe.org>
References: <4d9fa282-830d-42f7-a3bf-ba127cb2ad06o@googlegroups.com>
 <rcsmel$sdb$1@gioia.aioe.org>
 <8332f305-299f-45d7-9f9d-2cad924b24d8o@googlegroups.com>
 <rctfip$1eel$1@gioia.aioe.org>
 <9d941aca-2eb6-4f35-a346-c290c4666bdfo@googlegroups.com>
 <rcu20d$199n$1@gioia.aioe.org>
 <f7150588-5593-4688-bb83-e8ec0fd71550o@googlegroups.com>
 <rd1sce$1c2t$1@gioia.aioe.org>
 <76def2a5-667c-4009-b3b9-f0cf1c13a51bo@googlegroups.com>
 <3b5b2360-684c-4149-8662-98b53319cf94o@googlegroups.com>
 <b35ac73b-6790-4e6b-ba1c-7dfb25af34fdo@googlegroups.com>
 <4dabaf9e-8bd5-4c5f-a665-7e2ec48342aao@googlegroups.com>
NNTP-Posting-Host: jFK6OqqKW5bkmQ4H/i1UAQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.9.0
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2
Xref: reader01.eternal-september.org comp.lang.ada:59262
List-Id: <comp.lang.ada>

On 30/06/2020 13:28, Optikos wrote:

>> I don't see anything new here.
> 
> What is new here is that there appear to be well-reasoned ways (e.g., the Wide legal theory along this thread) that GNAT-LLVM could •force• a developer's app to GPLed against the developer's will by easy-to-enact-in-GNAT-LLVM violations of the RLE's terms that cause the Compilation Process to not achieve the stricter Eligible Compilation Process definition, due to Apple's closed-source manipulations of LLVM IR bitcode.
> 
> Perhaps the work-around is that GNAT-LLVM-based developers of apps should •never• submit LLVM IR bitcode to Apple's App Store's app-intake procedure.  In the past as far back as 2015, submitting bitcode instead of machine code was optional.  It is unclear with the new ARM-based Macs, whether that optionality will continue in the future, or whether that optionality has already been curtailed.

I already linked in a previous message proof that you do have to upload
the output from LLVM as bitcode to the appstore so Apple can optimise
based on intended target device.