From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic310-11.consmr.mail.ir2.yahoo.com (sonic310-11.consmr.mail.ir2.yahoo.com [77.238.177.32]) by sourceware.org (Postfix) with ESMTPS id 2D7913858C3A for ; Sun, 23 Jan 2022 16:57:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2D7913858C3A X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642957060; bh=rcrNPUSINU39iA/DtKzqMVTWYkmMDRgGBbt6tY7AP86=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=CfzpsodXHbos/D2eMBa1LQ9XG4MwZvO+lWmQ5IYNop10SMwlLBK91I2xgQCq91oXVgaN8exG2Qza2j/LRDn1yJWdLdKpvPwnUd/xxDPV4Phq7YSNC965GL6fXYDgSfJBMaTqr+RGS1jQOTZN+pSJQQCQxxzl8LYdttRP89E2P7a6u4W2fu2O1ufsivUYim5QvhMXTGgliALMx7RoN93zEv6z8bjikMZ32LAmz2MNp1z14MxwLxmhCH7PEZwtl3vaLIQeeBRY0PlTcC5jp7fYRNO7DJpysc/cNWvBClM0bdSq650XUHOPUB9BcdrgLqcHRg61ye57zVb+D8+X9XjOQw== X-YMail-OSG: 7wbvmTwVM1lDx1EQgZBObR0CsiJqlYT48GRL7q3qiUVsB45RpKGMt_574PyEzES vKYAwjKxEBhTRArywN6ixz_b2r7SvAIoSQvQtzyGoRDaq2QZ5NHhzQjgXjItH8eUt_YXzzN2L5S8 W1E_GAUwVu4bCmkumYWIOwIubD25JoyuI9QH.gtRcDHKoZd_uI1qFU20b1j9T5CJpZqxgWKWNO3Z ORuRsfIVn0ygyL.irtXcH7s0U_7H753FK9VUzmlcffLVPLP744JwCjuTdHCULebhUVY7UFN3I_kF m6rKRnuWSqQ4i32NksnZ1YHi4OuKLDXemf.bO5E3MtUPMM_BPvsMQcKkMIJKB.GvvSWSvnyLG0JC n_Q6e9_j.kb4Jn_qhUzAod1Dvv_7k5Bizhlef56.KYcq913iUMR7HclcdN9NJCo7BAWh4Y7bvrFm YVQOmgdsnEF.mHwLu1N9oxJjEXLJ1QFb9BA0paA_u8dhJNclBAwDgPr65wGgAa0ay8.3EtjycZBz AmH7yWTqUjohl3b7_.XkX_Tvzxg367y.NQyegJx2Cuv_0yh65LOQD4a6ywP.MGb89gotSu0wcHCX zHM4Xnqj7VJBCe3inbSDqZLWrzKLFAT8uL06lCOf87fHP7TAV7FNj8U4DjOEvMRAHpq0Sl5eXsA. Y0_sWqvTAsY7y3.Ktho7GY.Vf2ZeS3xa3wKL3AwSkqK0rRiB3pC0VT_hbdooqZgVY0UNhJckq2kt JaZl8Re6zQ59yqzKGgUZGdTQAckpin31Yck4HS_UbVA39y9ofYs2cC7Bs8S_bopsOreZl00Nzjc9 mDxaSGVjYidCdW7ADW2M37A1JFmshnWJrxeCsaQ6DaLp.O8j3pigz1F8Yj39jGbCl02saUGft6AJ kJ5AascA8eG28RPKkzJV4zsTuxMHNyML9XATRphC0Udlc5ChHywZb.itmuWQn_BW06D__4uiaV2y 5IUa9qHglMmeBO0m0_fXNwI..jQv0k3Q6.iVRCdrf2Z_D3EKS9XNRGz6Im7hf7KLUwk55gwRmNeH mCnLnzv5erFlpA_aezg7jTRK.Hw_KbC1ShEm47_lQw3J.I7v09TM58BSJY9fY2vAhzjcBYX4DYtK BTPQiCtgZUKKSw4LQtNYHZC.Vs9xX2cycLQSujh7tf6BAWFunu46qLDA4B2VbarkFGCev5c3JXzn tSLcxpHQlTSiPNCkPjotbu8Dayyf2UJxebmLvW7sjGmU6b0EWfKwX9bfdR1CZU3ok7.9lCCROtiy 1_WOlW03DqdC731x0DuAszZrzeX3sngYnNU4wYf86QEK6jofz7Ax22dYJ_qeGDLWKTXT7YWl9vpr 6Phb1LqVpRBCBdfKMrJgb49ZZuv1aHAx91huNOyOrANReC3B51RTKcl2JRMHAv82f7ajjOxaEi_V UeTa9eIwUuXnLab01iLw.XbCi7t7f53vAynP3JWo1MJHVJX5tKiRK03Lllbinvpy_jUMgBnuqeUH dJs_f5asMG.Q9piPIWMd0kN.gpBgzyTT4SYi1U86qg8a4TgFXLumMVvxqLxZFaCK66q5EHlAV1w_ llwLoa8PKtrSEufqRJnZAwYTrnwVabGL0HsRYcGmnglYuAF.t9FYOqYJWCQo_Kwf7cI1IvZ0qEZ1 zuQfXx8hKVEXa_lMlJhP48zu1QZmMSt9WCBZWrQQayebEFb2I7gFDZnhZWBPT4r.bWezni4M8Xs2 jUNZbmhSPdH9g7xRX07TPGn9VasdrFHs1ALtT2opFxetllk0RiGCOXz54Zobe6yVgKTDJ0OOHIRT LvYRaEJX3UiIbTprY0E_Es6Vcj7DvSy1sEJRpulhacz_aTja2NbYJc06OCYVdTb0vWzOCDskpX2n aMa5UGsYZa9p7MhhfRk9kC_1dbJVpZfIkA4PjD_.fsz5M9trAfVIQtEARHeKSFJRHxzs9Sg5nm4Q PyaDdSwsifThhrp.UsmQonMXzjgl5PqIOghXn92niKirH2zo9eRLPbU98J_2DfJD3Qb3n5Drnav. wAQprol9t6oIGQ1dXYVZgfDETOvwZR_NiBoxJcVsObRrbr9NVCe9CURFZTkccRauih7BQiJ7awnD sfJBDaR82Ggdoa0011wzgD5kP09psJCqFbWaKeYscsMsSi.gWYk_rtXEle9663SSvqsQkD0b3fdy Sw1z9BVIL.CYV_tIVjI3uS4.0He2QIyYFSqxn0HZApLWOMax4la1k0HpQmIL6NKZAfCjz3uFaWlm gUF4Usb.Bb3hS1sIJOmHpauSAUZbAwTp2gQGEUGJqwsILB86JPJ5q2KtAxsgtCipaxLIFGIeNYpy enZz8zJIoFjXh X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ir2.yahoo.com with HTTP; Sun, 23 Jan 2022 16:57:40 +0000 Received: by kubenode514.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fdea31aa0eee8d50dd7aeb2da3d982d1; Sun, 23 Jan 2022 16:57:37 +0000 (UTC) Message-ID: Date: Sun, 23 Jan 2022 17:57:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Question about autoreconf to regenerate configuration files Content-Language: en-GB To: joel@rtems.org Cc: Mike Frysinger , Newlib , Matthew Joyce References: <26fff1a3-7743-e0ce-f7a6-70b39a030118@embedded-brains.de> <41deefa7-d1ae-18f2-6a8e-25e002d85ed6@yahoo.de> <2bc01390-3a5b-fd2d-822c-c4cd9a96f744@yahoo.de> From: "R. Diez" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.19615 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2022 16:57:43 -0000 > [...] > We do thia one tree style. Combining the repositories has drawbacks. Mixing things at least increases chances for confusion. What are the advantages of using the "combined tree" versus separate directories? With a "combined tree", do you still need to build GCC in 2 phases, or can you do it in one pass? My first thought is that a "combined tree" may allow for more parallelism when building, but my makefile already builds all components in parallel too. The components of the toolchain I am building are: Binutils GMP MPFR MPC GCC Newlib GDB Binutils, GMP, MPFR and MPC probably need to be completely built before the GCC cross-compiler, so the "combined tree" is not going to paralellise that. GDB needs MPFR and GMP, but does not need the GCC cross-compiler, for it is a host-based tool. Therefore, at first sight, it looks like a "combined tree" may only increase parallelism when building GCC with an integrated Newlib, as opposed to building Newlib completely before building GCC. But I wonder if the "combined tree" build system serialises those steps (building GCC and building its Newlib) anyway. In any case, there may be an advantage of combining the GCC and Newlib source trees, but I cannot see yet how that could benefit the other components. > [...] > We move or symlink the newlib/ directory under the top GCC directory. Just the newlib/ directory? That means that top-level files in the Newlib Git repository, like 'configure' next to newlib/ and libgloss/ , are not used at all for your builds. Consider top-level file README, which starts like this: "This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation." This file does not seem to come from Newlib. Why do we need it in Newlib? The "combined tree" instructions on this page: https://gcc.gnu.org/wiki/Building_Cross_Toolchains_with_gcc state the following: "with the GCC files overriding the binutils/gdb/newlib files when there's a conflict." But the way you are symlinking just "newlib/" does not create any conflicts, does it? By the way, are you aware of any public full example (a script or makefile) somewhere which I could use as a reference for creating and building with a combined tree? > Mike Frysinger wrote: > [...] > there is only one set of top-level files. they get manually synced from > gcc to the other projects by devs who notice & need the fixes. OK, I gather that copying those files across from GCC is the standard practice. But why do we need to keep doing that in Newlib? According to the (outdated) cross toolchain build instructions, when combining the tree the GCC versions should prevail. It is not like anybody would take Newlib without GCC and use those top-level files (the 'configure' script) to build say just Newlib and Binutils, is it? >> My guess is that GCC's build system is calling 'configure', >> 'make' etc. inside newlib/, and it does not really matter >> if the versions are a little different. >> Or is a lot of the build system really shared? > Joel Sherrill wrote: > Based on how we always build, I'd say it is just invocation. > Mike Frysinger wrote: > the contract at build time is `./configure`, and even if newlib had its script > generated with an old version of autoconf, it doesn't really change the API. > the top-level Makefile knows to `cd newlib && ./configure ...` and that will > work regardless of the autoconf version. There seems to be consensus that the Autoconf version in Newlib does not matter, and that the "combined tree" building system interface is just invoking 'configure' and 'make' under newlib/. Why do we need to fix the Autoconf version to 2.69 then? We could use the newer 2.71 for Newlib. How about the Automake version? The Automake version is not checked like the Autoconf version is, isn't it? The checked-in "Makefile.in" files were generated with Automake 1.15.1 from 2017-06-19, and the latest is 1.16.5 from 2021-10-03. If we want to strictly keep in sync with GCC, shouldn't we check the exact Automake version too? > Mike Frysinger wrote: > the multilib multiplexing logic with libraries makes things a bit messier too. Does the multilib multiplexing logic affect the interface between the combined tree build system and Newlib? Or does it require something special inside newlib/ that would conflict with newer Autotools versions? Thanks for the information, rdiez -- rdiez