Re: Guiding principle for dropping LLVM versions? - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Guiding principle for dropping LLVM versions?
Date
Msg-id CA+hUKGKSNEzzeFcH7hw_LgF1DEi5HtVogVSza2wfh3xnndpN9A@mail.gmail.com
Whole thread Raw
In response to Re: Guiding principle for dropping LLVM versions?  (Xing Guo <higuoxing@gmail.com>)
List pgsql-hackers
On Sun, Oct 22, 2023 at 3:46 PM Xing Guo <higuoxing@gmail.com> wrote:
> Can we also check if the clang's version is compatible with llvm's version in llvm.m4? I have multiple llvm
toolchainsinstalled on my system and I have to specify the $CLANG and $LLVM_CONFIG variables each time I build the
serveragainst a toolchain that is not present in $PATH. If one of the variables is missing, the build system will pick
upa default one whose version might not be compatible with the other. E.g., If we use clang-16 and llvm-config-15,
therewill be issues when creating indexes for bitcodes at the end of installation. 

Hmm.  Problems that occur to me:

1.  We need to decide if our rule is that clang must be <= llvm, or
==.  I think this question has been left unanswered in the past when
it has come up.  So far I think <= would be enough to avoid the error
you showed but can we find where this policy (ie especially
commitments for future releases) is written down in LLVM literature?
2.  Apple's clang lies about its version (I don't know the story
behind that, but my wild guess is that someone from marketing wanted
the compiler's version numbers to align with xcode's version numbers?
they're off by 1 or something like that).

Another idea could be to produce some bitcode with clang, and then
check if a relevant LLVM tool can deal with it.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Why is hot_standby_feedback off by default?
Next
From: Andres Freund
Date:
Subject: Re: Guiding principle for dropping LLVM versions?