Обсуждение: BUG #17733: ERROR: could not load library "/Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so": dl

The following bug has been logged on the website:

Bug reference:      17733
Logged by:          Frank Reppin
Email address:      frankreppin@gmail.com
PostgreSQL version: 13.9
Operating system:   macOS Catalina 10.15.7
Description:       

Dear all,
... this is maybe related to an older issue #16460 - and it currently only
fails on 13.x - tested with postgresql-13.9-1-osx-binaries.zip ( from EDB
).

Outcome with 13.9 is (simple testcase) in an otherwise empty database
testdb:

testdb=> create table t1 (id serial);
CREATE TABLE
testdb=> insert INTO t1 (id) select * from generate_series(1, 10000000);
ERROR:  could not load library
"/Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so":
dlopen(/Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so, 10):
Library not loaded: @loader_path/../..//opt/local/lib/libncurses.6.dylib
  Referenced from:
/Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so
  Reason: no suitable image found.  Did find:
    file system relative paths not allowed in hardened programs
testdb=> \q

frank@imac postgres % otool -L
/Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so
/Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so:
        @loader_path/../../lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.13)
        @loader_path/../..//opt/local/lib/libncurses.6.dylib (compatibility version
6.0.0, current version 6.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1292.100.5)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
905.6.0)

I ran the very same test with postgresql-12.13 and postgresql-14.6 - both
succeeded there.

Please advise! :)
TY!

Hi,

On 2022-12-28 16:15:27 +0000, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference:      17733
> Logged by:          Frank Reppin
> Email address:      frankreppin@gmail.com
> PostgreSQL version: 13.9
> Operating system:   macOS Catalina 10.15.7
> Description:       
>
> Dear all,
> ... this is maybe related to an older issue #16460 - and it currently only
> fails on 13.x - tested with postgresql-13.9-1-osx-binaries.zip ( from EDB
> ).
>
> Outcome with 13.9 is (simple testcase) in an otherwise empty database
> testdb:
>
> testdb=> create table t1 (id serial);
> CREATE TABLE
> testdb=> insert INTO t1 (id) select * from generate_series(1, 10000000);
> ERROR:  could not load library
> "/Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so":
> dlopen(/Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so, 10):
> Library not loaded: @loader_path/../..//opt/local/lib/libncurses.6.dylib
>   Referenced from:
> /Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so
>   Reason: no suitable image found.  Did find:
>     file system relative paths not allowed in hardened programs
> testdb=> \q

That looks like an issue with the specific build - you're going to have to
take that up with EDB.


> frank@imac postgres % otool -L
> /Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so
> /Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so:
>       @loader_path/../../lib/libz.1.dylib (compatibility version 1.0.0, current
> version 1.2.13)
>       @loader_path/../..//opt/local/lib/libncurses.6.dylib (compatibility version
> 6.0.0, current version 6.0.0)
>       /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1292.100.5)
>       /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
> 905.6.0)

It's pretty odd that llvmjit.so is linking to ncurses. Looks like some
compiler flags might have been injected in a too broad way.

Are other libraries, e.g. plpgsql.so and libpq.dylib also referencing ncurses?

Greetings,

Andres Freund

Hi,

Thanks for reporting the bug. This certainly looks like a linking issue. I'll fix and provide the updates for PostgreSQL 13 at the earliest. 

On Fri, Dec 30, 2022 at 3:39 AM Frank Reppin <frankreppin@gmail.com> wrote:

Dear Andres, dear list,

it's just only llvmjit.so which (weirdly) links to libncurses.6.dylib here in EDBs postgresql-13.9 build - nothing else.

Neither plpgsql.so nor libpq.dylib reference libncurses.6.dylib - to answer your specific question about them.

Since I agree that this is no classic pgsql bug at all - I too wonder how to lure someone at EDB on this matter.

There  seems no community support mail - just options for users owning a 'plan' ( I at least couldn't figure one out ).

But it too seems that EDB staff lurks in here on a regular basis - so my hope was to have them pick it up from here ;)

FWIW - I'll CC Sandeep Thakkar (from former issue #16460) in good hope to get things sorted.

Thankyou!

cheers,

Frank Reppin

Am Do., 29. Dez. 2022 um 21:36 Uhr schrieb Andres Freund <andres@anarazel.de>:

Hi,

On 2022-12-28 16:15:27 +0000, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference:      17733
> Logged by:          Frank Reppin
> Email address:      frankreppin@gmail.com
> PostgreSQL version: 13.9
> Operating system:   macOS Catalina 10.15.7
> Description:       
>
> Dear all,
> ... this is maybe related to an older issue #16460 - and it currently only
> fails on 13.x - tested with postgresql-13.9-1-osx-binaries.zip ( from EDB
> ).
>
> Outcome with 13.9 is (simple testcase) in an otherwise empty database
> testdb:
>
> testdb=> create table t1 (id serial);
> CREATE TABLE
> testdb=> insert INTO t1 (id) select * from generate_series(1, 10000000);
> ERROR:  could not load library
> "/Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so":
> dlopen(/Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so, 10):
> Library not loaded: @loader_path/../..//opt/local/lib/libncurses.6.dylib
>   Referenced from:
> /Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so
>   Reason: no suitable image found.  Did find:
>     file system relative paths not allowed in hardened programs
> testdb=> \q

That looks like an issue with the specific build - you're going to have to
take that up with EDB.


> frank@imac postgres % otool -L
> /Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so
> /Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so:
>       @loader_path/../../lib/libz.1.dylib (compatibility version 1.0.0, current
> version 1.2.13)
>       @loader_path/../..//opt/local/lib/libncurses.6.dylib (compatibility version
> 6.0.0, current version 6.0.0)
>       /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1292.100.5)
>       /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
> 905.6.0)

It's pretty odd that llvmjit.so is linking to ncurses. Looks like some
compiler flags might have been injected in a too broad way.

Are other libraries, e.g. plpgsql.so and libpq.dylib also referencing ncurses?

Greetings,

Andres Freund

--

Sandeep Thakkar

Hi,

The issue is fixed and the website and the StackBuilder links are updated. Thanks again for reporting the issue.

On Mon, Jan 2, 2023 at 10:16 AM Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> wrote:

Hi,

Thanks for reporting the bug. This certainly looks like a linking issue. I'll fix and provide the updates for PostgreSQL 13 at the earliest. 

On Fri, Dec 30, 2022 at 3:39 AM Frank Reppin <frankreppin@gmail.com> wrote:

Dear Andres, dear list,

it's just only llvmjit.so which (weirdly) links to libncurses.6.dylib here in EDBs postgresql-13.9 build - nothing else.

Neither plpgsql.so nor libpq.dylib reference libncurses.6.dylib - to answer your specific question about them.

Since I agree that this is no classic pgsql bug at all - I too wonder how to lure someone at EDB on this matter.

There  seems no community support mail - just options for users owning a 'plan' ( I at least couldn't figure one out ).

But it too seems that EDB staff lurks in here on a regular basis - so my hope was to have them pick it up from here ;)

FWIW - I'll CC Sandeep Thakkar (from former issue #16460) in good hope to get things sorted.

Thankyou!

cheers,

Frank Reppin

Am Do., 29. Dez. 2022 um 21:36 Uhr schrieb Andres Freund <andres@anarazel.de>:

Hi,

On 2022-12-28 16:15:27 +0000, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference:      17733
> Logged by:          Frank Reppin
> Email address:      frankreppin@gmail.com
> PostgreSQL version: 13.9
> Operating system:   macOS Catalina 10.15.7
> Description:       
>
> Dear all,
> ... this is maybe related to an older issue #16460 - and it currently only
> fails on 13.x - tested with postgresql-13.9-1-osx-binaries.zip ( from EDB
> ).
>
> Outcome with 13.9 is (simple testcase) in an otherwise empty database
> testdb:
>
> testdb=> create table t1 (id serial);
> CREATE TABLE
> testdb=> insert INTO t1 (id) select * from generate_series(1, 10000000);
> ERROR:  could not load library
> "/Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so":
> dlopen(/Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so, 10):
> Library not loaded: @loader_path/../..//opt/local/lib/libncurses.6.dylib
>   Referenced from:
> /Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so
>   Reason: no suitable image found.  Did find:
>     file system relative paths not allowed in hardened programs
> testdb=> \q

That looks like an issue with the specific build - you're going to have to
take that up with EDB.


> frank@imac postgres % otool -L
> /Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so
> /Users/frank/postgres/postgresql-13.9/lib/postgresql/llvmjit.so:
>       @loader_path/../../lib/libz.1.dylib (compatibility version 1.0.0, current
> version 1.2.13)
>       @loader_path/../..//opt/local/lib/libncurses.6.dylib (compatibility version
> 6.0.0, current version 6.0.0)
>       /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1292.100.5)
>       /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
> 905.6.0)

It's pretty odd that llvmjit.so is linking to ncurses. Looks like some
compiler flags might have been injected in a too broad way.

Are other libraries, e.g. plpgsql.so and libpq.dylib also referencing ncurses?

Greetings,

Andres Freund

--

Sandeep Thakkar

--

Sandeep Thakkar