Re: Minimum gcc and clang supported to generate FreeBSD binaries

Warner Losh <[email protected]>
Newsgroups gmane.os.freebsd.architechture
Message-ID <CANCZdfpgLe3e34ovoUuT3xwJJ0FG32PTJddiLaC0xgMteH-nBA@mail.gmail.com>
On Wed, Jun 19, 2024 at 10:47 PM Konstantin Belousov <[email protected]>
wrote:

> On Wed, Jun 19, 2024 at 06:26:12PM -0700, Bakul Shah wrote:
> > On Jun 19, 2024, at 6:01 PM, Warner Losh <[email protected]> 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 unrelated
> to this desire. pcc doesn't support gnuc symbols at all last I checked. But
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.