From nobody Sat May 27 09:13:22 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 4QSx0p2fV1z4Wlx3 for ; Sat, 27 May 2023 09:13:30 +0000 (UTC) (envelope-from fbl@aoek.com) Received: from mail.yourbox.net (mail.yourbox.net [IPv6:2001:41d0:1:767d::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.yourbox.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QSx0n1MLFz3hpS; Sat, 27 May 2023 09:13:29 +0000 (UTC) (envelope-from fbl@aoek.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aoek.com header.s=mailbox header.b=YQByZjA5; spf=pass (mx1.freebsd.org: domain of fbl@aoek.com designates 2001:41d0:1:767d::1 as permitted sender) smtp.mailfrom=fbl@aoek.com; dmarc=pass (policy=reject) header.from=aoek.com Received: from mail.yourbox.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail.yourbox.net (8.17.1/8.17.1) with ESMTP id 34R9DRxa046141; Sat, 27 May 2023 11:13:27 +0200 (CEST) (envelope-from fbl@aoek.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aoek.com; s=mailbox; t=1685178807; bh=re0D/zt32RFq5UwsvS9yeZB9VzgjgSjYTe/0rQxUDzs=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=YQByZjA5LLWM/rGR3CZhqiFqfusD04g5i5bpruIwh5I3o8S8aBmlxt0VICQOR4d6t Ay7sjugjydrRh60coZzgwtJP4cciAdybqhzysqbI3rF3Fxd7+UBlvnZ2zTqZNqSxCn zF3ivMU1Bj3FCCPr+ePCIMfsPQfoLTEowi37k0/377tUaDuMNH2cWKYSH+ST1LVAZB 77ny32aXDg35t1eJd0k9m9O8Rzv+tXqh7EgDYo3HCDyFkeRaiXV9whdHl9xfEmCMxK pMlxcOX/3a0oHl7hxpAIGRr1wjBlmuUggWsDXkbNmYmNGzlszcPtkhRyM+dW9F73OT VSBeNzXck7xPg== 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 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sat, 27 May 2023 11:13:22 +0200 From: =?UTF-8?Q?Jos=C3=A9_P=C3=A9rez?= To: freebsd-arm@freebsd.org Cc: kevans@freebsd.org Subject: Re: devel/arm-none-eabi-newlib headers inconsistencies (not functional) or am I misusing something? In-Reply-To: <11a941a3a1c9e001559ccc6183af131d@mail.yourbox.net> References: <11a941a3a1c9e001559ccc6183af131d@mail.yourbox.net> Message-ID: <784313c52e2f42eb63f3755a5c093fdc@mail.yourbox.net> X-Sender: fbl@aoek.com User-Agent: Roundcube Webmail/1.2.0 X-Spamd-Result: default: False [-2.35 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.937]; R_MIXED_CHARSET(0.59)[subject]; DMARC_POLICY_ALLOW(-0.50)[aoek.com,reject]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[aoek.com:s=mailbox]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[aoek.com:+]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QSx0n1MLFz3hpS X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N El 2023-05-26 18:53, José Pérez escribió: > 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; > } I elaborate a little more with the hope to understand how to wire things up the proper way. devel/arm-none-eabi-newlib is not a dependency of devel/arm-none-eabi-gcc (but it should?). When only devel/arm-none-eabi-gcc is installed (which btw correctly installs arm-none-eabi-binutils as a dependency) the compiler is unusable: % arm-none-eabi-gcc break_arm.c /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 Do you think this missing port dependency should be fixed or is it ok to leave it as it is now? 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 devel/arm-none-eabi-gcc populates the former two and devel/arm-none-eabi-newlib populates the third. Both ports relay on a number of types defined in /usr/include and those files are opaqued out by files by the same name, but significantly different content, located in directories appearing earlier in the search path. __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 */ Which is never included because /usr/local/arm-none-eabi/include/sys/_types.h exists and appears earlier in the search path. 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 Note how it checks for __off_defined (two underscores at the beginning of the type name) and defines _off_t (one underscore only). 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 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? 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. 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; which might or might not be the same thing. In any case, this solution smells bad to me, that's why I ask before I do anything. BR, -- José Pérez