Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Jun 2024 00:10:23 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        Bakul Shah <bakul@iitbombay.org>,  "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject:   Re: Minimum gcc and clang supported to generate FreeBSD binaries
Message-ID:  <CANCZdfpgLe3e34ovoUuT3xwJJ0FG32PTJddiLaC0xgMteH-nBA@mail.gmail.com>
In-Reply-To: <ZnO0Rs1f0CQ_Y3Yh@kib.kiev.ua>
References:  <CANCZdfqBdsoNf8tVwX6MH=Dd24e114b_Pn5hA5UjxtSBX-h%2BGA@mail.gmail.com> <197A5386-1096-4754-BA82-996140B56EAF@iitbombay.org> <ZnO0Rs1f0CQ_Y3Yh@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000047540e061b4c2cee
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 19, 2024 at 10:47=E2=80=AFPM Konstantin Belousov <kostikbel@gma=
il.com>
wrote:

> On Wed, Jun 19, 2024 at 06:26:12PM -0700, Bakul Shah wrote:
> > On Jun 19, 2024, at 6:01=E2=80=AFPM, Warner Losh <imp@bsdimp.com> wrote=
:
> > >
> > > Ah, but what do you say about tcc and pcc which are't gcc? Well, tcc
> lies, and says it supports gcc (version 9 I think, but it's been a while
> since I checked). tcc can't work today because we have qsort.h using
> versioned symbols unconditionally, and it doesn't support versioned
> symbols.... And patches to do that have been stalled for reasons unrelate=
d
> to this desire. pcc doesn't support gnuc symbols at all last I checked. B=
ut
> it has real issues building some things in the tree, so I'll not gate
> things by it unless somebody steps up to actually do the work to make it
> work. The pcc upstream has been weird lately too.
>

pcc supports up through gcc 4.3 __attributes__ fyi.


> > Why are versioned symbols required for qsort.h?
> Look at the qsort_r() stuff in stdlib.h to maintain backward compat
> with previous definition of qsort_r() comparator.
>
> I think that for the purposes of keeping some support for tcc or whatever
> not-quite-gcc compiler, we should just avoid doing the backward-compat
> dance,
> if such compiler is detected.
>

https://reviews.freebsd.org/D45651 is a good, minimal patch to do that. A
more extensive
patch would not define the symver macro for tcc (so any uses we'd catch
right away) and
change the ifndef __TCC__ to ifdef symver.

Warner

--00000000000047540e061b4c2cee
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jun 19, 2024 at 10:47=E2=80=
=AFPM Konstantin Belousov &lt;<a href=3D"mailto:kostikbel@gmail.com">kostik=
bel@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">On Wed, Jun 19, 2024 at 06:26:12PM -0700, Bakul Shah wrote:<br=
>
&gt; On Jun 19, 2024, at 6:01=E2=80=AFPM, Warner Losh &lt;<a href=3D"mailto=
:imp@bsdimp.com" target=3D"_blank">imp@bsdimp.com</a>&gt; wrote:<br>
&gt; &gt; <br>
&gt; &gt; Ah, but what do you say about tcc and pcc which are&#39;t gcc? We=
ll, tcc lies, and says it supports gcc (version 9 I think, but it&#39;s bee=
n a while since I checked). tcc can&#39;t work today because we have qsort.=
h using versioned symbols unconditionally, and it doesn&#39;t support versi=
oned symbols.... And patches to do that have been stalled for reasons unrel=
ated to this desire. pcc doesn&#39;t support gnuc symbols at all last I che=
cked. But it has real issues building some things in the tree, so I&#39;ll =
not gate things by it unless somebody steps up to actually do the work to m=
ake it work. The pcc upstream has been weird lately too.<br></blockquote><d=
iv><br></div><div>pcc supports up through gcc 4.3 __attributes__ fyi. <br><=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; Why are versioned symbols required for qsort.h?<br>
Look at the qsort_r() stuff in stdlib.h to maintain backward compat<br>
with previous definition of qsort_r() comparator.<br>
<br>
I think that for the purposes of keeping some support for tcc or whatever<b=
r>
not-quite-gcc compiler, we should just avoid doing the backward-compat danc=
e,<br>
if such compiler is detected.<br></blockquote><div><br></div><div><a href=
=3D"https://reviews.freebsd.org/D45651">https://reviews.freebsd.org/D45651<=
/a> is a good, minimal patch to do that. A more extensive</div><div>patch w=
ould not define the symver macro for tcc (so any uses we&#39;d catch right =
away) and</div><div>change the ifndef __TCC__ to ifdef symver.<br></div><di=
v><br></div><div>Warner<br></div></div></div>

--00000000000047540e061b4c2cee--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpgLe3e34ovoUuT3xwJJ0FG32PTJddiLaC0xgMteH-nBA>