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 <ger...@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. When you >>>>>>>>> install the GCC compiler from the PKG repository it appears to create >>>>>>>>> a >>>>>>>>> modified set of include files from the system (default?) include files >>>>>>>>> (/usr/include). However, when the modified /usr/include/sys/types.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 problem. >>>>>>>> >>>>>>>> https://lists.freebsd.org/pipermail/freebsd-current/2017-February/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 system >> 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 the >> 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, whenever >> 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 an >> end-user. And having to rebuild all those ports might be a burden. >> >> As some people pointed out, simply moving away or deleting the directory >> 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? > > 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.
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 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. Agreed. Jung-uk Kim
signature.asc
Description: OpenPGP digital signature
