Skip site navigation (1)Skip section navigation (2)
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>