Message-ID: <d34bada3-ad38-43cf-840b-cf44be48830b@gmail.com>
Date: Thu, 21 Dec 2023 10:31:37 +0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: =?UTF-8?Q?Re=3A_BUG_=2318254=3A_could_not_load_library_llvmjit=2Eso?=
 =?UTF-8?Q?=EF=BC=8CUndefined_symbol_=22=5FZN4llvm12MemoryBuffer7getFileERKN?=
 =?UTF-8?Q?S=5F5TwineEbbbSt?=
Content-Language: en-US
To: Thomas Munro <thomas.munro@gmail.com>, pgsql-bugs@lists.postgresql.org
References: <18254-e303b33b2317c861@postgresql.org>
 <CA+hUKGLx0VgqwCz9YG0++-JBzUHmn1XXiDPjmkb1zHVxiE-kMA@mail.gmail.com>
From: Xiaoming <yangxiaoming2019@gmail.com>
In-Reply-To: 
 <CA+hUKGLx0VgqwCz9YG0++-JBzUHmn1XXiDPjmkb1zHVxiE-kMA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/d34bada3-ad38-43cf-840b-cf44be48830b%40gmail.com>
Precedence: bulk

I got the reason, why not found the symbol.

On my FreeBSD system, I have 2 version clang++, the system path 
`/usr/bin/clang++` and the `pkg` version `/usr/local/bin/clang++16`.

When I just only set the environment `LLVM_CONFIG=llvm-config16`, run 
`./configure --prefix=/usr/local --with-openssl --with-lz4
--with-wal-blocksize=64 --with-blocksize=32 --with-llvm` out put this 
configure result:
```text
configure: using compiler=FreeBSD clang version 16.0.6 
(https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152)
configure: using CFLAGS=-Wall -Wmissing-prototypes -Wpointer-arith 
-Wdeclaration-after-statement -Werror=vla 
-Werror=unguarded-availability-new -Wendif-labels 
-Wmissing-format-attribute -Wcast-function-type -Wformat-security 
-fno-strict-aliasing -fwrapv -fexcess-precision=standard 
-Wno-unused-command-line-argument -Wno-compound-token-split-by-macro 
-Wno-cast-function-type-strict -I/usr/local/include/python3.11/
configure: using CPPFLAGS= -I/usr/local/include
configure: using LDFLAGS= -L/usr/local/llvm16/lib -L/usr/local/lib  
-Wl,--as-needed
configure: using CXX=/usr/bin/clang++
configure: using CXXFLAGS=-Wall -Wpointer-arith 
-Werror=unguarded-availability-new -Wendif-labels 
-Wmissing-format-attribute -Wcast-function-type -Wformat-security 
-fno-strict-aliasing -fwrapv -fexcess-precision=standard -O2
configure: using CLANG=/usr/bin/clang
configure: using BITCODE_CFLAGS= -fno-strict-aliasing -fwrapv 
-fexcess-precision=standard -Xclang -no-opaque-pointers 
-Wno-unused-command-line-argument -Wno-compound-token-split-by-macro -O2
configure: using BITCODE_CXXFLAGS= -fno-strict-aliasing -fwrapv 
-fexcess-precision=standard -Xclang -no-opaque-pointers -O2
```

I changed the environments:
```bash
export LLVM_CONFIG=/usr/local/bin/llvm-config16
export CC=/usr/local/bin/clang16
export CXX=/usr/local/bin/clang++16
export CLANG=/usr/local/bin/clang16
```

configure out put:
```text
configure: using compiler=clang version 16.0.6
configure: using CFLAGS=-Wall -Wmissing-prototypes -Wpointer-arith 
-Wdeclaration-after-statement -Werror=vla 
-Werror=unguarded-availability-new -Wendif-labels 
-Wmissing-format-attribute -Wcast-function-type -Wformat-security 
-fno-strict-aliasing -fwrapv -fexcess-precision=standard 
-Wno-unused-command-line-argument -Wno-compound-token-split-by-macro 
-Wno-cast-function-type-strict -I/usr/local/include/python3.11/
configure: using CPPFLAGS= -I/usr/local/include
configure: using LDFLAGS= -L/usr/local/llvm16/lib -L/usr/local/lib  
-Wl,--as-needed
configure: using CXX=/usr/local/bin/clang++16
configure: using CXXFLAGS=-Wall -Wpointer-arith 
-Werror=unguarded-availability-new -Wendif-labels 
-Wmissing-format-attribute -Wcast-function-type -Wformat-security 
-fno-strict-aliasing -fwrapv -fexcess-precision=standard -O2
configure: using CLANG=/usr/local/bin/clang16
configure: using BITCODE_CFLAGS= -fno-strict-aliasing -fwrapv 
-fexcess-precision=standard -Wno-unused-command-line-argument 
-Wno-compound-token-split-by-macro -O2
configure: using BITCODE_CXXFLAGS= -fno-strict-aliasing -fwrapv 
-fexcess-precision=standard -O2
  ```

This issue may be reason with the system path clang++ pair of `pkg` 
version llvm libraries.
On the FreeBSD system, if with the `--with-llvm` configure argument, 
should build with the llvm's clang and clang++. I guess the system path 
`/usr/bin/clang++` has some difference with `pkg` version 
`/usr/local/bin/clang++16`, or `LD_LIBRARY_PATH` not contained the real 
`/usr/local/llvm16/lib` path.

My new build version, it's work well.
```text
...
Planning Time: 2.444 ms
JIT:
     Functions: 75
     Options: Inlining true, Optimization true, Expressions true, 
Deforming true
     Timing: Generation 3.608 ms, Inlining 248.625 ms, Optimization 
208.667 ms, Emission 167.912 ms, Total 628.812 ms
Execution Time: 10882.537 ms
```

On 2023/12/21 05:02, Thomas Munro wrote:
> On Thu, Dec 21, 2023 at 9:31 AM PG Bug reporting form
> <noreply@postgresql.org> wrote:
>>    ERROR: could not load library "/usr/local/lib/postgresql/llvmjit.so":
>> /usr/local/lib/postgresql/llvmjit.so: Undefined symbol
>> "_ZN4llvm12MemoryBuffer7getFileERKNS_5TwineEbbbSt8optionalINS_5AlignEE"
>> Demangle the symbol
>> `_ZN4llvm12MemoryBuffer7getFileERKNS_5TwineEbbbSt8optionalINS_5AlignEE` is
>> `llvm::MemoryBuffer::getFile(llvm::Twine const&, bool, bool, bool,
>> std::optional<llvm::Align>)`
> My OS and LLVM (installed with pkg) are the same as yours,
> though I'm building the master branch of PostgreSQL... hmm, I see a
> slightly different name here:
>
> tmunro@build1:~/projects/postgresql $ nm -DC
> ~/install/lib/postgresql/llvmjit.so | grep
> 'llvm::MemoryBuffer::getFile'
>                   U llvm::MemoryBuffer::getFile(llvm::Twine const&,
> bool, bool, bool, std::__1::optional<llvm::Align>)@LLVM_16
>
> tmunro@build1:~/projects/postgresql $ nm -DC
> /usr/local/llvm16/lib/libLLVM.so | grep
> 'llvm::MemoryBuffer::getFile(llvm::Twine'
> 00000000038ba2d0 T llvm::MemoryBuffer::getFile(llvm::Twine const&,
> bool, bool, bool, std::__1::optional<llvm::Align>)@@LLVM_16
>
> Note "std::__1::optional".  Could this be a clue about C++ standard
> library mismatch, or something like that?  Google is telling me that
> stdlib=libc++ (LLVM's standard library) has the __1 namespace, but
> stdlib=libstdc++ (GNU's standard library) lacks it, but I didn't look
> too hard...