X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=bBGNrGT395Ghn8ElHB6SEp8cXaBj1B7IHdEqRChp6C4=; b=NIxlFNcK4Bd+d/nV0AVHa2pbFejd364OwA8iwQB99l9MoDuf1CzPHcD/LXPoQhYNB3 EziSJPyPzljUUSWeztbL9fuetl3s7ns1lN/CCxwD99eUrYhgDJ/khPXqQdPn/O74+3qj IuZUW4Ip6QAfbR92K0GdlTDBwHcuNwJ9fja/ZbLT6VGCn8pgvr22HLHTuBV1a5gP7Zvv /W6aGfVUWv9uLJ1vczRZjBu3AdfjAyP9qlMgNSGcGD2Tx5/Ri7v04WfujlGzMFByAZXG L2mqHDaKbWUfAJtJUiid0NKhcOqgISPgrMkmiUNM5v05oG2clIVy4qDxmXOEpxcwNJ1H yhHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bBGNrGT395Ghn8ElHB6SEp8cXaBj1B7IHdEqRChp6C4=; b=foY5GaDnRLwMCCglp/F1IahdmWGP6SIUDWjC1+qa8KmkHaEirS5eIg1iOsaK9CyRvX qf2/yThJqdzsMyvwNiyE00d28zp/cO0w5ZztJb2C9mPqAMOyrvQkEMlz1JdMNFJNJ0oh dxKI1zGglrrJH3qEe4Shjzsyn7OuDj6BIA+9SrptmCkwMAI4/BradzHvFejiq3bDZOsu pyWpOMJJ+Su95vMmjnAQnYopMfFcQ/Sgb1sASplhZkvFZgZdUoqXp8VGt3zEQ7TnXljr ruVPPQruSH+6H++8IX0S2lfydzQVeQK99AwsTQ3qlJSg2VWceI44dxl+QbwsMoYNByYP /Lng== X-Gm-Message-State: AO0yUKX1A9M0KJ+lSehKdo/N1NdeF0YOjb6HBPVLtW+PvKhOQoA5xINh TfMwWxfbfNMxh0S0klxEkURo/+TWppZMnw== X-Google-Smtp-Source: AK7set8t+3xlRyXWHHpAM+qUbs8fJrvNArL/WSd5Izs/k7jrdgrOOe8dLK1kGVMrQ+9ICXEAUYkijw== X-Received: by 2002:a17:906:d1d0:b0:878:6df7:ce74 with SMTP id bs16-20020a170906d1d000b008786df7ce74mr9863320ejb.23.1674929396739; Sat, 28 Jan 2023 10:09:56 -0800 (PST) Message-ID: Date: Sat, 28 Jan 2023 19:09:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: DXE3 with std::vector Content-Language: en-US To: djgpp AT delorie DOT com References: <83mt63azwi DOT fsf AT gnu DOT org> <835ycravjo DOT fsf AT gnu DOT org> <83zga39fil DOT fsf AT gnu DOT org> <83v8kr9bye DOT fsf AT gnu DOT org> <83lelmakwk DOT fsf AT gnu DOT org> <83h6waaium DOT fsf AT gnu DOT org> <83fsbuahj9 DOT fsf AT gnu DOT org> <673bbaa0-5a0d-25be-1f1b-724856ee4f0b AT gmail DOT com> <835ycqa809 DOT fsf AT gnu DOT org> From: "J.W. Jagersma (jwjagersma AT gmail DOT com) [via djgpp AT delorie DOT com]" In-Reply-To: <835ycqa809.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On 2023-01-28 18:23, Eli Zaretskii (eliz AT gnu DOT org) [via djgpp AT delorie DOT com] wrote: >> Date: Sat, 28 Jan 2023 18:01:44 +0100 >> From: "J.W. Jagersma (jwjagersma AT gmail DOT com) [via djgpp AT delorie DOT com]" >> >>> >>> I don't really like this "solution", it just makes it the user's problem. >>> >>> How likely is it that someone uses the latest version of dxe3gen, but is >>> somehow stuck with such an ancient (nearly 25 years old) version of gcc? At >>> some point you'll just have to say, for gcc < X, use dxe3gen Y. >>> >>> For DXE_LD_LIBRARY_PATH, that can be added easily as -L dir, and won't break >>> anything. But not having this set should not be an error. >>> >>> For DJDIR, there is only one valid place it can point to, and gcc already knows >>> where to find it. I don't think a native gcc even works without DJDIR set. So >>> it doesn't make sense to also parse it in dxe3gen. >> >> Also, with removing DXE_LD_LIBRARY_PATH, the concern was that it could break >> existing makefiles. But now the accepted solution is... to break existing >> makefiles? That logic is hard to follow. > > If you can propose a patch that caters to your use case without > breaking the "traditional" one, please do, and let's take it from > there. > > GCC 2.95 is not a blocking problem, from my POV. But I don't want to > lose support for DJDIR and DXE_LD_LIBRARY_PATH, because someone could > have set them in their build procedures for some reason, and have them > point to some strange places that neither me nor you can imagine. > > Are there any fundamental problems that would preclude invoking GCC > instead of ld (so that your case is supported), but still have the -L > switch added to the GCC command line, whose argument is derived from > DXE_LD_LIBRARY_PATH or from DJDIR if those are set? IOW, can we have > the code work as you wanted when these two variables aren't set, but > add the additional -L switch when they are? Sure, that should be possible. Starting from the patch I submitted earlier, simply adding DXE_LD_LIBRARY_PATH via -L will achieve that. For DJDIR, again, having it set to anything other than the djgpp install location is *always* user error. Many things rely on this, and to me it doesn't seem very useful to support invalid configurations in dxe3gen.