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: