Date: Sun, 30 Apr 2017 15:12:27 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Gerald Pfeifer <gerald@pfeifer.com>, freebsd-stable@freebsd.org, Jung-uk Kim <jkim@FreeBSD.org>, papowell@astart.com Subject: Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition Message-ID: <1AB1479F-EB72-4D8C-8112-E7C63D3AC07A@FreeBSD.org> In-Reply-To: <20170430120626.GT1622@kib.kiev.ua> References: <8316fd8e-056d-32a1-1e59-414269476190@astart.com> <95c6f08e-0cf7-f0f3-8b19-29e03b3f4f96@FreeBSD.org> <39149f1c-d939-5c60-a0c3-ab76fa0f750b@astart.com> <f264ebcc-4cd4-4541-f19d-227cde74b3ba@FreeBSD.org> <fb7749f8-193a-2cdc-db8f-9ca046a0b94e@astart.com> <22bfc9eb-f037-cb1e-931f-a995e98093e2@FreeBSD.org> <alpine.LSU.2.21.1704291846170.2928@anthias.pfeifer.com> <163343D9-0396-4468-B666-DD9D8AEE176B@FreeBSD.org> <20170430120626.GT1622@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On 30 Apr 2017, at 14:06, Konstantin Belousov <kostikbel@gmail.com> wrote: > > On Sat, Apr 29, 2017 at 07:55:24PM +0200, Dimitry Andric wrote: ... >> So in that case, if Jung-uk's solution works, it is probably the best >> way forward, and it can even be upstreamed. Jung-uk, how does your >> patch handle an updated header under /usr/include which contains e.g. >> new definitions, which are not in the fixed includes directory? > > Am I right that Jung-uk fix replaces vm_ooffset_t and vm_pindex_t with > explicit int64_t and uint64_t use, as the course of action for gcc > fixincludes step ? If yes, I completely disagree. > > The change blocks any future changes to the type that might occur in the > base system, for the code compiled by gcc. End result might be as bad > as mismatched ABI, in the worst case. > > I share the opinion that fixincludes is not only useless, but really > damaging. Gcc ships workarounds for e.g. issues in X11 headers, which > application depends on the presence of the corresponding headers at the > gcc build time. For clean (poudriere-like) builds these fixes are never > applied, so port build results are inconsistent, at least. > > Nobody so far explained why fixincludes is needed for the modern base > headers. IMO if we have real problems in headers we ship, we must fix it > in the base. > > With all of the above, IMO most sane way to fix problems is to > rename fixincludes directory to some name which is ignored by gcc, > e.g. include-fixed -> include-fixed.saved. This can be done as > post-installation step in the ports. I agree, it would be best to avoid storing any copies of system headers completely. Maybe the port can have an option FIX_INCLUDES, which defaults to off? I am not sure if there is anybody that really wants these 'fixed' headers, though. :) -Dimitry [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlkF4soACgkQsF6jCi4glqNLGwCgkSnnAjlhbDdxePmfPYS32fEZ SgYAnAsubs/QQa1XDkreM0FbWfi9JtQg =wdyW -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1AB1479F-EB72-4D8C-8112-E7C63D3AC07A>