Date: Mon, 13 Feb 2023 10:45:56 +0000 From: David Chisnall <theraven@FreeBSD.org> To: Mark Millard <marklmi@yahoo.com>, Shawn Webb <shawn.webb@hardenedbsd.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: CFT: snmalloc as libc malloc Message-ID: <69917cbd-816b-da64-988d-910ddb88438e@FreeBSD.org> In-Reply-To: <0F63E50F-C0DF-48C4-81A0-6EEF46C9C397@yahoo.com> References: <ED93FF21-07BC-4FC0-A114-27424E60C024.ref@yahoo.com> <ED93FF21-07BC-4FC0-A114-27424E60C024@yahoo.com> <20230212210904.nzxfwtzsjf2tu6ky@mutt-hbsd> <AE89E235-DD25-4D4B-BAC1-BA9956F904B0@yahoo.com> <0F63E50F-C0DF-48C4-81A0-6EEF46C9C397@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/02/2023 22:32, Mark Millard wrote:
> I'll note that include/c++/v1/stddef.h uses:
>
> #include_next <stddef.h>
>
> That in turn causes a stddef.h to be found that is
> from later in the search list (not earlier or the
> same file again).
>
> As for the include ordering, this leads to
> . . ./include/c++/v1 needing to be before the
> directory for the matching normal C header(s) that
> C++ is(are) trying to include.
>
> There are implications for recursive include
> handling during #include_next processing (just the
> tail of the search list is used as I understand).
I hit a problem with this related to the msun headers, which was fixed
in the diff by changing the include from libc to:
CFLAGS+= --include-directory-after ${SRCTOP}/lib/msun/src
This may also be necessary for other headers if the way that the libc /
libc++ headers are included has changed.
David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?69917cbd-816b-da64-988d-910ddb88438e>