From nobody Sat May 27 10:18:03 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QSyRf0HTHz4WqLr for ; Sat, 27 May 2023 10:18:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QSyRd53F2z3pJH for ; Sat, 27 May 2023 10:18:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685182699; bh=eZ9ct+6cCQXMrNZPQO5IatrIiuOa7nwBJ+BeXy9mCMk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=s+GANFufl+ngMBnbacYfSEbfLRnPOddCsUuAd4AUQrElFNyu6YdNMdJ27LAqra5yWfDzePQJCRpvv3UFvEFPqqFQP2fwn9QYUC10vveRVjn3b4b33xzQ02Mbm2B/yNOnflHDF4fcPbGLM0VjCAQ8Imr05vJGYREKJRPApGY4T06ueYBWDBW2UenHqppeLcAjAL0tPGYEELKeqlWUamMAjSZUJd/wR27H++a4905NqecU7oezE++SPKLGcx+s+qEDOePmbP/8IBpTLKRHTxr2Jr2rLXjo7NaSBibsugx+BuMzqF7XMhNW1ypVW7hMkHa7a1FsGpAfp8/IyxiWxX+gCw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685182699; bh=BwvP/g0BXtbUubvEjVVoDQlZ7oQiPyN4PZUNoiEKu56=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=msUPi4TfbBm1vkUaweLjiU/2Po84hIugNUI6Q5enMdKoitx1D9OVqPJlYoS9gw+OBhXezyUuiUsyK572zun2WigVnlM1ihRUdVe7rEbalL5gBnM+94jE/uIKuT8PKpSO3D8qpcsK+HiCRLN7zxHjXTXJFJUm6IcVmSAZbl9OIFJsBrDEWSM3DpN6IlOVM0//ev+ZAhv0cudNXJoo6CeDWWn5lIxPXqOO32eLRd60v8XpcmqfRaYtn+wgVEZPb56B+fSSrtg+4qJYbcGiIMVTJoYuU38aEj9lLaY5+z77oSKsJMJuYXs6rK8RTTxgG0VPw0fgYLzfczxOi266Mws+bQ== X-YMail-OSG: wZl_jv8VM1nyCpFW953NI3RbV9bELFdEFHCU3yMxsZgwuVeYSAM_kwtUQIN4CJq O5M5DVW0fqbA6rwtQokPTCbxMu8.JN4Cg2_vqimMhcAjdTUYd_FTTj2ooaCTN1zDZQP7N.8XDHqp DW_jFX.MgjfTEz36lzw0JiXyua3r2zJjZs_Pe8jHqR37QmhmN661matvWD_MRzXdtFBIc2H6_UI8 DXtFYfi6cPRhr0CpvifXQYdoeRwIcot1Lq9XwYedNfd2rL_8uF_t3avcsosBLPS2VVz4Sp.wVaFr E2Vbtb7nVhLlqPnkNZqhv6ogSRXKfh8QCTqQEIBssHQXfP0rqeOoFE6PtqEGtr.BQ60Y23Wa4u1X P6bMgsvoktiSrRqET830OFIZMgFYmvxa5PD7BKmyQM3a8xSs.XpKGgfCdl4q_a5ckYlxboeQR_pG 4GBrchB_qTDM3plMZTx6vZxE_9tmoHGoP.R4tPP95eOgnJMzSZi3eK33jYQ4LNBad9iJqMtXg.bR rnmHbjHXoAPNPO3WSBZUTmfEoqYgitjdDbYAkDCQesYRcPnrwvr0ZNflIch2piMlR9TsXI3GTyfN csVGbnZH60Z_nFcFlAB92T3u0EovDpWlkQUsDwaXxPneSUyciExfMicb5W383tgpX0uNYAhWhhz. 8le.w.HspSf6NUclmxXnkSU78mhMDxsqYgVUTAJZu8o5UYU8gqkjShxPD00O5.26PYRJwt1FiKCK RjygrYzT_JCDTNWXP5f8TgTZrCtE8BWTeWLHdRXGLcYRmyVAnt1_1iZS54J2Sx1hc3XgsmAfbfYR LYA.obmXpPbYvu.BWStHC9GPbzKRIAPvmuIUlPshnIAxdJlGsBmaROkzZxFbP3qnhEKYogPfd40t lU1oAkzTCWBgymspf5w1YOEY8Mgw4RwbQV07jZpppiCXNlouJ98WZJoI4iiKUzST_9y_xLpJTKVM 3gG2Q6fcivUPfW91Lp.V2CI9Fx.VtYcikC07QeO6JuBWSYT_GkSXErNr.krh_WZBSnSQdqAxQOC1 zwetdElwrfoguc9IB5FQlg8lDonNizsj2fSdRxLXcd7nL.djxXD6gu2RPHIp8JTtWl6UtbWcugKe yX.QtZ.G9amGNjdQsbFIw_0Buey8sDeqIffZ1S3u1vfXDEBK100wZ_pZ0u15BFaCghTFjDAsqpPB mL7JDo8ErIAuOPJX0LOxOT4GJ._luKgHkuUQe13oUz7CoUjze96LdPvtrW0nf.6q9aZHTV_LQT.T 5epPjY5gdo1gtuiwyrTn8xf59j6eHgc2e4v0nDvcAFV2bZzsWz3qtoPZXjjktHkyPW0tbViLmzuc 8Dy.SLysLE2.ath45PHUAaclsP7Y6o8rf5AxioT09kzeEaYvPhHNRz8VIJN01bSFW7.THKmN9biT GSDJm9z2j0R7O2vOYPYDDpRb7s48LmUTPWyFya22aYatPtCkWLvx6nvJUivuSmzrG1pfw6wvi_W. IyBu7sKI00UCYGbIKV_1YvMlJ4b4ThoU3MeIHUDC0heBH0Ij0RKEKHUFqWKRC8zF.5.iHehwbLMh E7qXtE2u9ihvb5uelzDUx0KRg_eroZkcoIEdCACTBp65fHO.josJ5PAfD1UGsBQD0YNeZVZAVwFf G3OKXIl9S9zNvJ44UW._sBHXQhcwunH3BUXq3XJxc3WDnqhKFTrR5PkOI1xvpuonQhFzxu9P_vY0 Pq6wfV9NWDfqx_dmU3uMaEswY8me410dDFGEVACigqnxN6isZSkSn35ePeARTo1chQacawAPIc4e tlTiGxqXWE50SOMtjrfsoBo3iy8T8ERiHksab0Vc.lIx2KEAZJWjlZSsbF3V_DALtx68haSQLxU7 AA6.MWTptaHAsXBXvjX7yAcQHdpEthvJoaypeakc.53QeXr7.lk9d55g0qTvgQEwYf_oYA3C3Iel YpLkGwpfT3xAY03A24.kA6OoJLFCDcUKHN0yv0iV1Rqey6pUJ2cr01rGQsg57yG0nEe0cZg7EnUx 2DRkCWS1O_vgGi1owvxUbEIYBuEg9FaHlfv89T8B.HohMsAHKgNTO2rpIds4bnqHc.ci5xg3xWNw IovWLQGN0AzxR0GlIyxkfMAG0h00skRs.emG.nMmDVfRNgxPSoZFyuBvmYVy7XLc9ju_z3cvbXTv wltYqKnv7KINxooQ.G.TVdYk500wSqB0XmSr7fWodvt38p6IshG9X0PSoyB_s48CnzCwalQVWF3o XDFZoJpCR7DjGr5bB3xBxtSkctsn9BpE3ucS5dBTNcifXICixMcfewoliOwuC5OSF67CW8eFnZj. 7JgM- X-Sonic-MF: X-Sonic-ID: 5c6f1146-5b79-4bb2-b85f-d73987832c34 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 27 May 2023 10:18:19 +0000 Received: by hermes--production-gq1-6db989bfb-xtcqt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f485317a5f96dece7fca8cf4dfdb5b65; Sat, 27 May 2023 10:18:14 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: devel/arm-none-eabi-newlib headers inconsistencies (not functional) or am I misusing something? From: Mark Millard In-Reply-To: <784313c52e2f42eb63f3755a5c093fdc@mail.yourbox.net> Date: Sat, 27 May 2023 03:18:03 -0700 Cc: freebsd-arm@freebsd.org, kevans@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9E888138-D3D0-4A6C-92B9-31705D470089@yahoo.com> References: <11a941a3a1c9e001559ccc6183af131d@mail.yourbox.net> <784313c52e2f42eb63f3755a5c093fdc@mail.yourbox.net> To: =?utf-8?B?Sm9zw6kgUMOpcmV6?= X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4QSyRd53F2z3pJH X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On May 27, 2023, at 02:13, Jos=C3=A9 P=C3=A9rez wrote: > El 2023-05-26 18:53, Jos=C3=A9 P=C3=A9rez escribi=C3=B3: >> Hi, >> a source as simple as this does not compile with >> devel/arm-none-eabi-newlib installed >> #include >> int main(int argc, char *argv[]) { >> return 0; >> } >=20 > I elaborate a little more with the hope to understand how to wire = things > up the proper way. >=20 > devel/arm-none-eabi-newlib is not a dependency of = devel/arm-none-eabi-gcc > (but it should?). devel/arm-none-eabi-gcc is used by other ports without having devel/arm-none-eabi-newlib installed. Examples include: sysutils/atf-rk3399 sysutils/u-boot-a13-olinuxino . . . sysutils/u-boot-master . . . sysutils/u-boot-orangepi-plus-2e . . . sysutils/u-boot-rpi2 . . . devel/arm-none-eabi-gcc can be built and used for various purposes without ever having built or installed devel/arm-none-eabi-newlib . But devel/arm-none-eabi-newlib has a build dependency on devel/arm-none-eabi-gcc . (Which means that devel/arm-none-eabi-gcc can not depend on devel/arm-none-eabi-newlib .) > When only devel/arm-none-eabi-gcc is installed > (which btw correctly installs arm-none-eabi-binutils as a dependency) > the compiler is unusable: The compiler is usable and I use it, just not for what you are trying to do. > % arm-none-eabi-gcc break_arm.c You need command line options to tell arm-none-eabi-gcc to use the devel/arm-none-eabi-newlib materials. It is not the default/automatic.=20 > /usr/local/bin/arm-none-eabi-ld: cannot find crt0.o: No such file or = directory > /lib/libc.so.7: file not recognized: file format not recognized > collect2: error: ld returned 1 exit status >=20 > Do you think this missing port dependency No dependency is missing. Command line options are missing that would be required for what you are trying to do. > should be fixed or is it ok > to leave it as it is now? Leave it as it is. > Looking at the missing types more closely, arm-none-eabi-gcc header > search path defaults as follows: > /usr/local/lib/gcc/arm-none-eabi/11.3.0/include > /usr/local/lib/gcc/arm-none-eabi/11.3.0/include-fixed > /usr/local/arm-none-eabi/include > /usr/include You need to tell the compiler to use non-default paths. devel/arm-none-eabi-newlib has its files in: /usr/local/arm-none-eabi/ Not in: /usr/local/lib/gcc/arm-none-eabi You reported that it found=20 /usr/local/lib/gcc/arm-none-eabi/11.3.0/include-fixed/stdio.h instead of: /usr/local/arm-none-eabi/11.3.0/include-fixed/stdio.h That is because tegh default search paths are wrong for your purpose. You need /usr/local/lib/gcc/arm-none-eabi to be first (or the only entry). > devel/arm-none-eabi-gcc populates the former two and > devel/arm-none-eabi-newlib populates the third. True. But the files under: /usr/local/lib/gcc/arm-none-eabi/11.3.0/include and /usr/local/lib/gcc/arm-none-eabi/11.3.0/include-fixed are found and used instead of what is under: /usr/local/lib/gcc/arm-none-eabi when there is a file name match. You reported the it found and used the wrong stdio.h in your original message: /usr/local/lib/gcc/arm-none-eabi/11.3.0/include-fixed/stdio.h You need /usr/local/lib/gcc/arm-none-eabi to be first in the search path used. That requires command line options to be supplied. > Both ports relay on a number of types defined in /usr/include If /usr/local/lib/gcc/arm-none-eabi is first in the search path, then it will find all the files it needs from there, no matter what the later search path entries may be. None of the FreeBSD headers should be used for your purpose, only headers from under /usr/local/lib/gcc/arm-none-eabi . A similar point goes for the types of files used in linking. > and those files are opaqued out by files by the same name, but > significantly different content, and are the wrong files for it to use for your purpose. You need it to find and use the files under /usr/local/lib/gcc/arm-none-eabi instead. > located in directories appearing > earlier in the search path. >=20 > __off_t, __ssize_t, __off64_t, __mbstate_t and __va_list are > defined in the system default header: > /usr/include/sys/_types.h:94:typedef __int64_t __ssize_t; = /* byte count or error */ > /usr/include/sys/_types.h:97:typedef __int32_t __ssize_t; = /* byte count or error */ > /usr/include/sys/_types.h:133:typedef __int64_t __off_t; = /* file offset */ > /usr/include/sys/_types.h:134:typedef __int64_t __off64_t; = /* file offset (alias) */ > /usr/include/sys/_types.h:203:} __mbstate_t; > /usr/include/sys/_types.h:211:typedef __builtin_va_list = __va_list; /* internally known to gcc */ >=20 > Which is never included because = /usr/local/arm-none-eabi/include/sys/_types.h > exists and appears earlier in the search path. >=20 > Note that newlib's /usr/local/arm-none-eabi/include/sys/_types.h seems > to be partially aware of the problem and does something, but it's not = a > full fix: > 15:#ifndef __off_t_defined > 16:typedef long _off_t; > 17:#endif >=20 > Note how it checks for __off_defined (two underscores at the beginning = of > the type name) and defines _off_t (one underscore only). >=20 > The file also does similar fixes for a bunch of other types including > __ssize_t, __off64_t and __mbstate_t that pop up while trying to > compile my test .c file: i.e. > it checks for __foo_t and, if not found, defines _foo_t but not = __foo_t >=20 > Shall I patch newlib's sys/type.h to define also __foo_t, not only = _foo_t > or is there a bettere way to handle this? >=20 >=20 > There is an exception: __va_list is not mentioned in newlib's headers > but only system default sys/_types.h, so I suspect this is not an = isolated > case, and maybe a different approach shall be used? I.e. manually = bring in > all that is typedef'd in system defaults sys/_types.h and make sure = there is > a corresponding entry in newlib's version of the same file? = Furthermore, > how shall the missing types be defined? The types are defined = differently > by the system default and newlib. >=20 > E.g. __off_t (two underscores) in system default is: > /usr/include/sys/_types.h:133:typedef __int64_t __off_t; = /* file offset */ > and _off_t (one underscore) in newlibs lingo is: > /usr/local/arm-none-eabi/include/sys/_types.h:16-typedef long _off_t; >=20 > which might or might not be the same thing. >=20 > In any case, this solution smells bad to me, that's why I ask before I = do anything. >=20 Your proposed change will break all the other uses of devel/arm-none-eabi-gcc . You need to leave it as is. =3D=3D=3D Mark Millard marklmi at yahoo.com