Re: pltcl crash on recent macOS - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: pltcl crash on recent macOS
Date
Msg-id 360e3d9b-a335-bced-840c-a185e213fe15@enterprisedb.com
Whole thread Raw
In response to Re: pltcl crash on recent macOS  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: pltcl crash on recent macOS
Re: pltcl crash on recent macOS
List pgsql-hackers
On 13.06.22 13:27, Thomas Munro wrote:
> On Mon, Jun 13, 2022 at 6:53 PM Peter Eisentraut
> <peter.eisentraut@enterprisedb.com> wrote:
>>       frame #1: 0x00007ff803a28751 libsystem_c.dylib`hash_search + 215
>>       frame #2: 0x0000000110357700
>> pltcl.so`compile_pltcl_function(fn_oid=16418, tgreloid=0,
> 
> Hmm, I can’t reproduce that….  although that symbol is present in my
> libSystem.B.dylib according to dlsym() and callable from a simple
> program not linked to anything else, pltcl.so is apparently reaching
> postgres’s hash_search for me, based on the fact that make -C
> src/pl/tcl check succeeds and nm -m on pltcl.so shows it as "from
> executable".  It would be interesting to see what nm -m shows for you.

...
          (undefined) external _get_call_result_type (from executable)
          (undefined) external _getmissingattr (from executable)
          (undefined) external _hash_create (from libSystem)
          (undefined) external _hash_search (from libSystem)
...

> I’m using tcl 8.6.12 installed by MacPorts on macOS 12.4, though, hmm,
> SDK 12.3.  I see the explicit -lc when building pltcl.so, and I see
> that libSystem.B.dylib is explicitly mentioned here, whether or not I
> have -lc:
> 
> % otool -L ./tmp_install/Users/tmunro/install/lib/postgresql/pltcl.so
> ./tmp_install/Users/tmunro/install/lib/postgresql/pltcl.so:
> /opt/local/lib/libtcl8.6.dylib (compatibility version 8.6.0, current
> version 8.6.12)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1311.100.3)

Looks the same here:

pltcl.so:
    /usr/local/opt/tcl-tk/lib/libtcl8.6.dylib (compatibility version 8.6.0, 
current version 8.6.12)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1311.100.3)

> Here’s the complete link line:
> 
> ccache cc -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 -Wno-unused-command-line-argument
> -Wno-compound-token-split-by-macro -g -O0  -bundle -multiply_defined
> suppress -o pltcl.so  pltcl.o -L../../../src/port
> -L../../../src/common  -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX12.3.sdk
> -Wl,-dead_strip_dylibs   -L/opt/local/lib -ltcl8.6 -lz -lpthread
> -framework CoreFoundation  -lc -bundle_loader
> ../../../src/backend/postgres

The difference is that I use CC=gcc-11.  I have change to CC=cc, then it 
works (nm output shows "from executable").  So it's gcc that gets thrown 
off by the -lc.



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Checking for missing heap/index files
Next
From: Tom Lane
Date:
Subject: Re: Finer grain log timestamps