AW: Building PosgresSQL with LLVM fails on Solaris 11.4

Hi Andres

Many thanks for your help and the fix.

> Is this on x86-64 or sparc?
It is SPARC

> Oh, one thing that might be going wrong is that you just set the C compiler to
> be gcc, but not C++ - what happens if you addtionally set CXX to g++?

// That seems to get set correctly:
# grep ^'CXX=' config.log
CXX='g++'

// I used the patch command to patch the src/backend/port/Makefile with your attached file and tried again with the Sun Studio compiler. There is now a different error at this stage:
…
/opt/developerstudio12.6/bin/cc -m64 -xarch=native -Xa -v -O -I../../../src/include -c -o pg_shmem.o pg_shmem.c
echo | /usr/bin/clang -Wno-ignored-attributes -fno-strict-aliasing -fwrapv -O2 -I../../../src/include -flto=thin -emit-llvm -c -xc -o tas.bc tas.s
tas.s:1:1: error: expected identifier or '('
!-------------------------------------------------------------------------
^
1 error generated.
gmake[3]: *** [Makefile:42: tas.bc] Error 1
gmake[3]: Leaving directory '/opt/cnd/opt28_13.3_gmake_all_llvm_fix/src/backend/port'
gmake[2]: *** [common.mk:39: port-recursive] Error 2
gmake[2]: Leaving directory '/opt/cnd/opt28_13.3_gmake_all_llvm_fix/src/backend'
gmake[1]: *** [Makefile:42: all-backend-recurse] Error 2
gmake[1]: Leaving directory '/opt/cnd/opt28_13.3_gmake_all_llvm_fix/src'
gmake: *** [GNUmakefile:11: all-src-recurse] Error 2

// Have attached the config.log, gmake all full log, and patched Makefile.

Best regards
Sasha

Von: Andres Freund <andres(at)anarazel(dot)de>
Datum: Freitag, 1. Dezember 2023 um 20:49
An: Sacha Hottinger <itdo(at)cndag(dot)onmicrosoft(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org <pgsql-hackers(at)postgresql(dot)org>
Betreff: Re: Building PosgresSQL with LLVM fails on Solaris 11.4
Hi,

On 2023-12-01 17:02:25 +0000, Sacha Hottinger wrote:
> Compiling PostgreSQL 13.13 with option –with-llvm fails with Developer Studio 12.6 as well as with gcc 13.2.0.
> I have installed the developer/llvm/clang" + "developer/llvm/clang-build pkgs (13.0.1).

Uh, huh. I did not expect that anybody would ever really do that on
solaris. Not that the breakage was intentional, that's a separate issue.

Is this on x86-64 or sparc?

I'm somewhat confused that you report this to happen with gcc as well. We
don't use .s files there. Oh, I guess you see a different error
there:

> o With gcc (psql 13.13):
>
> #./configure CC='/usr/bin/gcc -m64' --with-system-tzdata=/usr/share/lib/zoneinfo --with-llvm
>
> # time gmake all
> ...
> -Wl,--as-needed -Wl,-R'/usr/local/pgsql/lib' -lLLVM-13
> Undefined first referenced
> symbol in file
> TTSOpsHeapTuple llvmjit_deform.o
> pfree llvmjit.o
> …
> MemoryContextAllocZero llvmjit.o
> pkglib_path llvmjit.o
> ExecEvalStepOp llvmjit_expr.o
> errhidestmt llvmjit.o
> ld: warning: symbol referencing errors

This is odd. I think this is when building llvmjit.so - unfortunately there's
not enough details to figure out what's wrong here.

Oh, one thing that might be going wrong is that you just set the C compiler to
be gcc, but not C++ - what happens if you addtionally set CXX to g++?

I did not think about .o files generated from .s when writing the make
infrastructure for JITing. At first I thought the easiest solution would be
to just add a rule to build .bc from .s - but that doesn't work in the
sunstudio case, because it relies on preprocessor logic that's specific to sun
studio - which clang can't parse. Gah.

Thus the attached hack - I think that should work. It'd mostly be interesting
to see if this is the only roadblock or if there's more.

To be honest, the only case where .s files matter today is building with sun
studio, and that's a compiler we're planning to remove support for. So I'm not
sure it's worth fixing, if it adds complexity.

Greetings,

Andres Freund

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager.