From nobody Fri Dec 29 19:32:48 2023 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1wWx2hcQz553q1 for ; Fri, 29 Dec 2023 19:33:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1wWx2HQNz3Lms for ; Fri, 29 Dec 2023 19:33:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-55372c1338bso7520742a12.2 for ; Fri, 29 Dec 2023 11:33:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1703878380; x=1704483180; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=w9iw9g5pTbyqV8PrJ4oYd4mCOALP0O3HCEIoN8HbCSU=; b=HYesA2ICnXA0j+1Uk7NWycEqZifEIhM6jK2xhZUQ01JZWoWwoRj8onbNJ/yu+CLIeY 2mWN0RVxDPDn/Ue6nEBu9XvveHcJPGo6dcotGpA7Mlh+CL8t12ojNrV2pouYHyf2k9wh r2t+3gSZQHfi1m+d4xb0H2DYmsoUKJiMV1WnEedGMQOGxoT2yEQskODOt9m1TfLcY5C4 qVEQnl4pWSvoCy/+otr3UI+TI4NZEfKMMZUDk94QKT7xmfk7qmcdoJu8/V6HMtlz+zgw h+iDMyfU/52ZvEb14q3l7nSiz/WECWCNJKyY9lBmuL/Kl0OE3XxXB9alybUFhdM8C7CB SIvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703878380; x=1704483180; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=w9iw9g5pTbyqV8PrJ4oYd4mCOALP0O3HCEIoN8HbCSU=; b=FniQN/abLieBClXifR/Ax8B60s3IGql3QcvrqQoVt/SJ/LwZfXd6dT4AgWwGdl/ILI XY5faByIyafBJLJamhTOfcWbnAv2ZAISpnxWRSPQNbNiZE6pP8fhz1RWwkMsKUlnPg4P atRe4OJOwo1gdf2jKP2UodNxtzMFvqkWpUrSYUFnjX5WntH1Nnpyca9kInPZ8RIRlndk m/AKIBd1xXDVgVG2nmCsC2PGMv8893Sw8dxwx+ttMqeSD78PrftiSjNM+0nt1leUay5v oAs6lQNdZ4E0N9M7YJk9p+rtNycSBkQWmIhT+2snlUDY5AllKE2DIpegQmFZufQLKZsh Gu5Q== X-Gm-Message-State: AOJu0YzaglWacTRI/kjHIqT/yfwy5u8MQdNiLEUcE6Erc3BJS7aEVPFQ UL17HAuaD5x2FqV3+UZM1yiLBmH4Z7ul1d44zbtrG/c9E413sw== X-Google-Smtp-Source: AGHT+IFzkIuYT3mEdIcjKEW0EwIbMGBh+twqWQm//xcPpuVHaUOTu+AYG+8Ev2HSBaRqcvIuL59o3FLYLEd0jbm01C0= X-Received: by 2002:a17:907:2cf4:b0:a1f:a0ac:ab3a with SMTP id hz20-20020a1709072cf400b00a1fa0acab3amr5977250ejc.129.1703878379807; Fri, 29 Dec 2023 11:32:59 -0800 (PST) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 References: <202312270143.3BR1hMQf085312@gitrepo.freebsd.org> <24134FF7-8C03-490D-A476-4EFF4EAD8132@FreeBSD.org> <0452FE2C-00E9-4E06-880B-6F7B56751728@FreeBSD.org> In-Reply-To: <0452FE2C-00E9-4E06-880B-6F7B56751728@FreeBSD.org> From: Warner Losh Date: Fri, 29 Dec 2023 12:32:48 -0700 Message-ID: Subject: Re: git: a8b70cf26030 - main - netpfil: Use accessor functions and named constants for all tcphdr flags To: Dimitry Andric Cc: Antoine Brodin , Gleb Smirnoff , Richard Scheffenegger , src-committers , "" , "" Content-Type: multipart/alternative; boundary="00000000000091b2ef060dab19d3" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T1wWx2HQNz3Lms --00000000000091b2ef060dab19d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 29, 2023, 4:39=E2=80=AFAM Dimitry Andric wrot= e: > On 29 Dec 2023, at 11:17, Dimitry Andric wrote: > > > > On 29 Dec 2023, at 08:35, Antoine Brodin wrote: > >> > >> On Thu, Dec 28, 2023 at 10:37=E2=80=AFPM Gleb Smirnoff > wrote: > >>> > >>> Antoine, > >>> > >>> On Thu, Dec 28, 2023 at 08:48:36PM +0000, Antoine Brodin wrote: > >>> A> > netpfil: Use accessor functions and named constants for all > tcphdr flags > >>> A> > > >>> ... > >>> A> This breaks some ports: > >>> A> /usr/include/netinet/tcp.h:82:8: error: unknown type name 'inline' > >>> > >>> Definitely some ports that use some strange compilers :) > >>> > >>> Can you please give at least port names? > >> > >> Some examples: > >> > >> > https://pkg-status.freebsd.org/gohan04/data/mainamd64PR275986-default-foo= /2023-12-28_20h35m41s/logs/errors/nspr-4.35.log > >> > https://pkg-status.freebsd.org/gohan04/data/mainamd64PR275986-default-foo= /2023-12-28_20h35m41s/logs/errors/opusfile-0.12_1.log > > > > The culprit is likely the "-ansi" option. Just get rid of that, it is > not really useful: > > > > cc -o prmapopt.o -c -fvisibility=3Dhidden -O2 -pipe > -fstack-protector-strong -fno-strict-aliasing -ansi -Wall -fPIC -UDEBUG > -DPACKAGE_NAME=3D\"\" -DPACKAGE_TARNAME=3D\"\" -DPACKAGE_VERSION=3D\"\" > -DPACKAGE_STRING=3D\"\" -DPACKAGE_BUGREPORT=3D\"\" -DPACKAGE_URL=3D\"\" > -DNDEBUG=3D1 -DHAVE_VISIBILITY_HIDDEN_ATTRIBUTE=3D1 -DHAVE_VISIBILITY_PRA= GMA=3D1 > -DXP_UNIX=3D1 -DFREEBSD=3D1 -DHAVE_BSD_FLOCK=3D1 -DHAVE_SOCKLEN_T=3D1 > -DHAVE_POINTER_LOCALTIME_R=3D1 -DHAVE_DLADDR=3D1 -DHAVE_LCHOWN=3D1 > -DHAVE_SETPRIORITY=3D1 -DHAVE_STRERROR=3D1 -DHAVE_SYSCALL=3D1 > -DHAVE_SECURE_GETENV=3D1 -D_REENTRANT=3D1 -D_THREAD_SAFE=3D1 -DFORCE_PR_L= OG > -D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM -D_NSPR_BUILD_ > -I../../../dist/include/nspr -I../../../pr/include > -I../../../pr/include/private prmapopt.c > > In file included from prmapopt.c:46: > > In file included from prmapopt.c:46: > > /usr/include/netinet/tcp.h:82:8: error: unknown type name 'inline' > > 82 | static inline uint16_t > > | ^ > > Hm, I may have spoken too soon here. If this port has always compiled > successfully with -ansi, then indeed it may not be that handy to directly > use the 'inline' keyword in system headers. I think most other system > headers use '__inline', which is supported by both gcc and clang, even in > ANSI mode. And if the compiler somehow does not support __inline, > sys/cdefs.h can make sure all those keywords get removed. > Yes. You have to use __inline in system headers. Warner -Dimitry > > --00000000000091b2ef060dab19d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Dec 29, 2023, 4:39=E2=80=AFAM Dimitry Andric &= lt;dim@freebsd.org> wrote:
On 29 Dec 2023, at 11:17, Dimitry Andric = <dim@FreeBSD.org> wrote:
>
> On 29 Dec 2023, at 08:35, Antoine Brodin <antoine@FreeBSD.org> w= rote:
>>
>> On Thu, Dec 28, 2023 at 10:37=E2=80=AFPM Gleb Smirnoff <glebiu= s@freebsd.org> wrote:
>>>
>>> Antoine,
>>>
>>> On Thu, Dec 28, 2023 at 08:48:36PM +0000, Antoine Brodin wrote= :
>>> A> >=C2=A0 =C2=A0 =C2=A0netpfil: Use accessor functions = and named constants for all tcphdr flags
>>> A> >
>>> ...
>>> A> This breaks some ports:
>>> A> /usr/include/netinet/tcp.h:82:8: error: unknown type nam= e 'inline'
>>>
>>> Definitely some ports that use some strange compilers :)
>>>
>>> Can you please give at least port names?
>>
>> Some examples:
>>
>> https://pkg-status.freebsd.org/goha= n04/data/mainamd64PR275986-default-foo/2023-12-28_20h35m41s/logs/errors/nsp= r-4.35.log
>> https://pkg-status.freebsd.or= g/gohan04/data/mainamd64PR275986-default-foo/2023-12-28_20h35m41s/logs/erro= rs/opusfile-0.12_1.log
>
> The culprit is likely the "-ansi" option. Just get rid of th= at, it is not really useful:
>
> cc -o prmapopt.o -c -fvisibility=3Dhidden -O2 -pipe -fstack-protector-= strong -fno-strict-aliasing -ansi -Wall -fPIC -UDEBUG -DPACKAGE_NAME=3D\&qu= ot;\" -DPACKAGE_TARNAME=3D\"\" -DPACKAGE_VERSION=3D\"\&= quot; -DPACKAGE_STRING=3D\"\" -DPACKAGE_BUGREPORT=3D\"\"= ; -DPACKAGE_URL=3D\"\" -DNDEBUG=3D1 -DHAVE_VISIBILITY_HIDDEN_ATTR= IBUTE=3D1 -DHAVE_VISIBILITY_PRAGMA=3D1 -DXP_UNIX=3D1 -DFREEBSD=3D1 -DHAVE_B= SD_FLOCK=3D1 -DHAVE_SOCKLEN_T=3D1 -DHAVE_POINTER_LOCALTIME_R=3D1 -DHAVE_DLA= DDR=3D1 -DHAVE_LCHOWN=3D1 -DHAVE_SETPRIORITY=3D1 -DHAVE_STRERROR=3D1 -DHAVE= _SYSCALL=3D1 -DHAVE_SECURE_GETENV=3D1 -D_REENTRANT=3D1 -D_THREAD_SAFE=3D1 -= DFORCE_PR_LOG -D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM -D_NSPR_BUILD_ -I../.= ./../dist/include/nspr -I../../../pr/include -I../../../pr/include/private = prmapopt.c
> In file included from prmapopt.c:46:
> In file included from prmapopt.c:46:
> /usr/include/netinet/tcp.h:82:8: error: unknown type name 'inline&= #39;
>=C2=A0 =C2=A082 | static inline uint16_t
>=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 ^

Hm, I may have spoken too soon here. If this port has always compiled succe= ssfully with -ansi, then indeed it may not be that handy to directly use th= e 'inline' keyword in system headers. I think most other system hea= ders use '__inline', which is supported by both gcc and clang, even= in ANSI mode. And if the compiler somehow does not support __inline, sys/c= defs.h can make sure all those keywords get removed.
=

Yes. You have to use __= inline in system headers.

Warner=C2=A0