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; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=C5ndmvBs6g/G1Sz4/umBYLVkWZ0IaKR4BKNxsnKDcTA=; b=Ujej2Mkt9CyK quE1hbm4blWaOf0bd5Mv2SM7GoQl8WVECjx1cwpbKyAoKB5H2V73rRuf6YxNIt782vNCyt7Zbpkya LHTWAVfc1Q76ML2VgYQWiX+tcPAelC4G6k/R2cFmGDoS/vGBh8DUSeFh25HGwEl/RBoWzRUhEA9x3 SmSKjsBI1qZeF5ffHQMrQ559EK5O8VI0jt7JvZ0Jbnkam3Zy4gDl0BldJd1aPlSHffhGghWc6jza7 QezHGB0+9UoPe5XRDY5afcvd5a0Jj9bEDQsaENJ0ThItPplFUHGq3uaZ4tvsMpPuhelV9+YHV/qAj Bm8qQjYr4qdG3Zyy4m2XzA==; Date: Sat, 28 Jan 2023 19:23:02 +0200 Message-Id: <835ycqa809.fsf@gnu.org> From: "Eli Zaretskii (eliz AT gnu DOT org) [via djgpp AT delorie DOT com]" To: djgpp AT delorie DOT com In-Reply-To: (djgpp AT delorie DOT com) Subject: Re: DXE3 with std::vector References: <83sffvbux1 DOT fsf AT gnu DOT org> <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> 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 > 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?