Hi,
On 2021-11-15 17:34:33 -0500, Tom Lane wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > ... The interesting thing about 16.1 is that you can invoke it
> > as xlclang to get the new clang frontend and, I think, possibly use
> > more clang/gcc-ish compiler switches[2].
> > [2] https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1?topic=new-clang-based-front-end
>
> Ho, that's an earful ;-). Though I wonder whether that frontend
> hides the AIX-specific linking issues you mentioned. (Also, although
> I see /opt/IBM/xlc/16.1.0/ on gcc119, there's no xlclang there.
> So whether we have useful access to it right now is unclear.)
It's actually available there, but in /opt/IBM/xlC/16.1.0/bin/xlclang++ (note
the upper case C).
It doesn't really hide the linking issues afaict. I think they're basically an
ABI rather than a linker invocation issue. It's not that hard to address them
though, it's basically making mkldexport.sh a tiny bit more general and
integrating it into src/backend/postgres' build.
We don't have to generate export files for shared libraries anymore though,
afaict, because there's 'expall', which suffices for our purposes. dlopen()
doesn't require an import file.
> This plays into something that was nagging at me while I wrote my
> upthread screed about not giving up on non-gcc/clang compilers:
> are those compilers outcompeting all the proprietary ones, to the
> extent that the latter will be dead soon anyway?
I think that's a pretty clear trend. The ones that aren't dying seem to be
incrementally onto more and more rebasing onto llvm tooling.
It doesn't help that most of those compilers are primarily for OSs that, uh,
aren't exactly growing. Which limits their potential usability significantly.
Greetings,
Andres Freund