Date: Mon, 1 May 2017 12:56:41 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com>, Dimitry Andric <dim@FreeBSD.org> Cc: Gerald Pfeifer <gerald@pfeifer.com>, freebsd-stable@freebsd.org, papowell@astart.com Subject: Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition Message-ID: <88ad5747-46df-d688-7acc-56123c5e3f7b@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
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nKEdxnc5e3a19k82imqoflUBqEH0BpiRl Content-Type: multipart/mixed; boundary="utu27qcBmOGHBuxOR5ahlSO5M5ELn8P4r"; protected-headers="v1" From: Jung-uk Kim <jkim@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com>, Dimitry Andric <dim@FreeBSD.org> Cc: Gerald Pfeifer <gerald@pfeifer.com>, freebsd-stable@freebsd.org, papowell@astart.com Message-ID: <88ad5747-46df-d688-7acc-56123c5e3f7b@FreeBSD.org> Subject: Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition 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> In-Reply-To: <20170430120626.GT1622@kib.kiev.ua> --utu27qcBmOGHBuxOR5ahlSO5M5ELn8P4r Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/30/2017 08:06, Konstantin Belousov wrote: > On Sat, Apr 29, 2017 at 07:55:24PM +0200, Dimitry Andric wrote: >> On 29 Apr 2017, at 19:00, Gerald Pfeifer <gerald@pfeifer.com> wrote: >>> >>> On Thu, 27 Apr 2017, Jung-uk Kim wrote: >>>>>>>>> I found the problem, but I do not know how to resolve this. W= hen you >>>>>>>>> install the GCC compiler from the PKG repository it appears to = create a >>>>>>>>> modified set of include files from the system (default?) includ= e files >>>>>>>>> (/usr/include). However, when the modified /usr/include/sys/ty= pes.h >>>>>>>>> file is created, the typedef for vm_ooffset_t is modified, and= there is >>>>>>>>> no reference to __vm_ooffset_t that the compiler can resolve. >>>>>>>>> >>>>>>>>> < typedef __int64_t vm_ooffset_t; >>>>>>>>> --- >>>>>>>>>> typedef __vm_ooffset_t vm_ooffset_t; >>>>>>>> ... >>>>>>>> You have to rebuild lang/gcc from the ports tree to fix this pro= blem. >>>>>>>> >>>>>>>> https://lists.freebsd.org/pipermail/freebsd-current/2017-Februar= y/064937.html >>>>>>> Does this mean that the GCC port/package needs to be updated? If= so, >>>>>>> should I file a PR report on this issue? >>>>>>> I (temporarily) fixed this problem by hand editting the modified = types.h >>>>>>> file and things seem to work. >>>>>> I already wrote a patch (attached). :-) >>>> If the maintainer (gerald) approves. CC'd. >>> >>> Thanks for bringing this to my attention. >>> >>> Can you please help me understand why this is necessary? >> >> This is because gcc's fixincludes process makes copies of certain syst= em >> headers (in this case, /usr/include/sys/types.h) with slight >> modifications. Then, it places the directory containing the modified >> headers at the front of the include search path. So far so good. >> >> Now, whenever sys/types.h is updated, as happened with the vm_ooffset_= t >> change, the header in gcc's own preferred directory might not match th= e >> definitions which are expected, leading to compilation errors. >> >> >>> If the >>> port/package is builts from scratch, does this trigger the problem? >> >> Yes, basically you need to rebuild all gcc ports from scratch, wheneve= r >> you update any system header that matches gcc's list of files it wants= >> to modify. >> >> But getting those errors in the first place can be very confusing to a= n >> end-user. And having to rebuild all those ports might be a burden. >> >> As some people pointed out, simply moving away or deleting the directo= ry >> with fixed includes appears to work around the problems. So maybe the= >> question is if gcc really needs to modify those headers at all? >> >> I have looked at gcc's build system a bit, but it does not seem very >> easy to disable the fixincludes step. I guess that is simply not >> supported. >> >> 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? >=20 > 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. >=20 > The change blocks any future changes to the type that might occur in th= e > base system, for the code compiled by gcc. End result might be as bad > as mismatched ABI, in the worst case. Good point. > 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 neve= r > applied, so port build results are inconsistent, at least. >=20 > 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 i= t > in the base. >=20 > 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. Agreed. Jung-uk Kim --utu27qcBmOGHBuxOR5ahlSO5M5ELn8P4r-- --nKEdxnc5e3a19k82imqoflUBqEH0BpiRl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAlkHaNEACgkQfJ+WJvzb 8UYLtwf+IOAnQR8b1tY4DbBYmsv57rNdJTFtS6s18cI5fNbYUMyLCHET3uxQ+BhB MAEjopMoCyUiF/YAipGPPt83kcou4td7rb6/0nY63JUPfpoSu+6WQaBLKjiVdNeh NmRBMnsKBXhLYzH6NueVJi2RbptGiWysDzqFubHH2yljspcGtcGYsIYV1CL1k3v+ B3WxpgVPs6PLuxsYAUHtVdvAcaw3H3KnFU+dIGl/M3WU+Umi2+GEsvNrm1XCE01L wVyjqiLsu9JphvUXUQR2xtJg4nbGkSoMNBXJ6pdWMVxe9620yggMbhQgzxR8M57t WQlLfflaMuqpaNY6R3aupNqiDfxPJA== =fgAq -----END PGP SIGNATURE----- --nKEdxnc5e3a19k82imqoflUBqEH0BpiRl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?88ad5747-46df-d688-7acc-56123c5e3f7b>