From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] [WIP] Port feature/native-comp to Windows. Date: Sun, 10 May 2020 14:50:52 -0300 Message-ID: References: <5eb5b953.1c69fb81.a67ce.a764@mx.google.com> <83lfm1hc91.fsf@gnu.org> <83wo5lds87.fsf@gnu.org> <83lflzd8es.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="77725"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, Andrea Corallo To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 10 19:51:55 2020 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 1jXq7H-000K9f-Pf for ged-emacs-devel@m.gmane-mx.org; Sun, 10 May 2020 19:51:55 +0200 Original-Received: from localhost ([::1]:52398 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXq7G-0000aQ-C8 for ged-emacs-devel@m.gmane-mx.org; Sun, 10 May 2020 13:51:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40890) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXq6X-0008P0-Ss for emacs-devel@gnu.org; Sun, 10 May 2020 13:51:09 -0400 Original-Received: from mail-ot1-x331.google.com ([2607:f8b0:4864:20::331]:46791) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jXq6U-0004Az-4G; Sun, 10 May 2020 13:51:09 -0400 Original-Received: by mail-ot1-x331.google.com with SMTP id z25so5689792otq.13; Sun, 10 May 2020 10:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2XjaGzjwvxMnzJKctqYZ5fURFvDBAK2XH92iz3PF77w=; b=gCr5Nf0ZpCeOfebktOFhpzfGqH6mFFi7ZHSBsAbMJjfCQhJwe27ObFnsQ8XFuAAvT3 1JzFUZGP0w/ZFcSoATLXD8NUx3zOu92BovedCjUYlm2WOXtpn+H8ydmek1I2yd7xC1ym OBLNjBLO1ZU8kmKFZHmaHIUFVdQwM5pGnv8FRb3HDnV+1QQg4x8tnbB8ovkkj+mWTyjv GRdWKrSmX+OkqakbBaY1mCSPnJa8NVlLj+bkwCwgdscjZsLSnPpCfmAVQay+c36+y6Ha +2pN6MJYdDloablWrEVk5hvuWtcTXnokN+toIBCt6zm5oqwCt+9d0WgyXbX/q4k+HKWl 3zBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2XjaGzjwvxMnzJKctqYZ5fURFvDBAK2XH92iz3PF77w=; b=e5G32baB+cG7YHxJYVKR1q2nzg0mtfZ9wRzSnF7ZiSqRCuUTm4QT3jtoutajtP/uH9 Qc4fAvZ6l8wEEZft4VXd97kdSyQstF/kkvzQmYbFm5qS0zukVmXzVkdIXjwHL6uNiT7Z mRhNXHLcGs/Hj1afQmx1nhmR1Bj7G3quuUGf3yyU1/NkCmvms0m8KGWQTZSYnWicOGcm KVm6bgcZKrUKbB5NlT7Gjs4/QHhFV/FPr5JXF0o+CzPDLZUU9NPxJ9Pc7vx240FXj66c kQS5N9KuGBfbNTQQ7HGE3+lCqFp4vBTygc/q8E/SIwP1Zy7bVVUyjeTeaEA/yUgFNU0k AtzQ== X-Gm-Message-State: AGi0PubJE35Y8BRMAk97+fT1JEy5iwA257MCvqmJpH96sIdXntZo/Zvi 701FRB5ih6VTDXPdr74KmfCTD2ULOzbAIYAo9zSJJbfuOpP9bw== X-Google-Smtp-Source: APiQypLb3u53g/+mtpKEB3FqGV/AUPToP8UNOly8QRwODssd6KGYzwMfLUEM7+hqcEfTz3FAQyw63ZvsD2caP7LL7Uk= X-Received: by 2002:a9d:5f09:: with SMTP id f9mr9892385oti.202.1589133064128; Sun, 10 May 2020 10:51:04 -0700 (PDT) In-Reply-To: <83lflzd8es.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::331; envelope-from=nicolasbertolo@gmail.com; helo=mail-ot1-x331.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:249685 Archived-At: > What information do we need, exactly? We need: - The name of the setjmp function. - Whether it needs a second parameter, in that case: - It can be a gcc builtin, a function call or a NULL constant. - If it is a function call or a builtin it may need a parameter. This is a NULL constant in all cases I have seen. > What is the definition of " where the gcc installation lives"? What > files does libgccjit need from that place, and how does it look for > those files? libgccjit implements generates an assembler file. This is done without any calls to any external program. Then it calls a gcc entry point to finish the process. This calls the same functions that the `gcc` program uses to identify where it was installed. In particular, it uses constants defined at libgccjit build time (the compiler version, the directories where it was installed, etc.). It uses that information plus some environment variables: GCC_EXEC_PREFIX, LIBRARY_PATH, maybe others, to find where the gcc support files are installed: the support binaries, libgcc. This is what I meant by "where the gcc installation lives". This logic runs inside the Emacs process that is performing the compilation process, but it is the same code that would run in a `gcc -print-*` IIUC. > IIUC what is needed, it should be relatively easy to glean this > information from the output of "gcc -print-file-name=" and its ilk. libgccjit runs the exact same code as gcc would. So this would not help. Moreover, how would Emacs find gcc? We would need to add it to PATH. > Using the above-mentioned -print-* options to GCC should accomplish > the same tasks, because they ask GCC to reveal the places where it > finds its auxiliary binaries and support libraries. Isn't it enough > to find out the absolute file names of each such file/program, and > tell libgccjit to use that absolute file name, instead of using -B? I do not think that is possible. libgccjit likes to find the files it needs as if it was a gcc instance. > I'd like to avoid that: it's a nuisance to have to copy files that > way, and users could legitimately have more than one GCC version > installed and available at the same time. AFAIU, we need to use the same GCC version, that is what libgccjit looks for. Also, the only things it needs are the assembler, linker and support libraries. Using support libraries from different GCC versions may cause weird bugs. It is not a good idea IMHO. > That assumes that Emacs is configured and built on the same system > where it is used. That assumption is mostly false for Windows, where > many users simply download and install precompiled binaries, or build > on one system and then use on several different ones. We should try > to find a way of getting this information at run time, not at > configure time. And it shouldn't be hard: we can use at run time the > same GCC options as the configure script would do. This should be > done once, and the result stored in some FOO-directory variable for > use when Lisp should be compiled. This would mean that users would have to download the appropriate GCC version if they want to use native lisp compilation, ensure that Emacs finds it, etc. By copying the support files into the installation dir we ensure that Emacs finds the correct files and it works out of the box for users that download a ZIP file.